In an article I wrote last year, I described a number of different mobile application architectures including Native, Hybrid, and Web apps.  An architecture that was not discussed in-depth was cross-platform native apps.  For some time, it seemed that HTML5 and Hybrid apps were the only way to go for writing cross-platform applications – but sometimes you need to build a native app, and in many cases the performance, offline capabilities, and device hardware access of a native app simply can’t be beat. But, how can you build a native app without completely re-developing the app for each mobile platform?

Enter Cross-Platform Native Apps. Cross-Platform Native apps work similarly to standard native apps, as they are built using the platform’s operating system APIs and SDKs, have full access to the device hardware and sensors, and have a user experience that is native to the platform.  Unlike native apps however, cross-platform native apps are generally not built using the default development tools of the platform (e.g. Objective-C/Xcode for Apple, Java/Android Studio for Android, C#/Visual Studio for Windows Phone) – but rather are built by using a 3rd party product or framework and the code is then compiled on different platforms to produce completely native apps that share code between them.

The key difference for cross-platform native apps is that they are able to share some amount of code across platforms. Usually these apps share code for business logic, algorithms, domain models, or data storage, which can help ensure consistency between multiple versions of an app on different platforms.  For example, an app performing complex financial calculations will likely want to ensure users obtain the same results across all platforms. While it’s certainly possible to get the same results from the same logic written in multiple programming languages, most developers would rather embrace a core tenet of object-oriented programming: code reusability. Code reuse enables much higher quality, maintainability, and consistency of behavior within a given application.

Due to the differences in the UI (user interface) paradigms of each platform, UI-related code is usually not shared between the apps. The business logic is shared between the apps, while the UI is rebuilt specifically for each platform.  This allows the cross-platform apps to take full advantage of the native UX (user experience) while maintaining consistency of business logic between platforms.  Usually, the UI-related code accounts for about 20-40% of most mobile apps – depending upon the complexity of the UI.

cross_platform_apps_architecture2

Cross-Platform Code Sharing Architecture

To note, while Hybrid apps can achieve cross-platform code sharing by re-using JavaScript across multiple operating systems, they do not provide a completely native user experience and this approach has its own benefits and disadvantages. For the purposes of this article, “cross platform native apps” will refer to completely native apps that don’t make use of web technologies to share code across platforms. However, it is possible to build hybrid apps using cross-platform technologies for the native portion of the app – though there would usually be little reason to do this, as the native wrapper in a hybrid app usually doesn’t contain a significant amount of code.

Tools and Frameworks

There are a number of products and open source frameworks available that allow developers to build cross-platform native apps.  These tools include Xamarin, CodeNameOne, and Appcelerator Titanium as well as more gaming-focused tools such as Corona SDK, MonoGame, and Unity 3D. The Xamarin tools, as well as MonoGame and Unity 3D use C# as the language of choice, whereas CodeNameOne uses Java, Titanium uses JavaScript, and Corona uses the Lua scripting language. Unity 3D also supports JavaScript as well as the Boo programming language. Each tool claims full support for the most popular mobile platforms – including iOS, Android, and Windows Phone. All of these tools work in a similar way (except for Titanium), by translating and compiling the code written in the language of choice into a native binary executable app. Titanium works a little bit differently – the JavaScript source code is included within the application, and is interpreted at runtime rather than being compiled into a native executable.

These tools also have some differences in the UI department.  The Xamarin tools allow developers to write a cross-platform “core” for an app that includes business logic and other re-useable code and then the UI code is re-written on each platform to match the native UI paradigms.  This allows developers to take full advantage of the native UI of each platform, while still sharing a core codebase between platforms.

While it is possible to write a business app in Corona, MonoGame, or Unity 3D – these tools are mostly focused on 2D and 3D drawing in order to create games, and usually have little to no “standard UI” components beyond what is necessary for creating in-game menus. These platforms usually don’t make use of the standard native UI components on each platform, but rather draw their own custom UI elements using the graphics API of each platform (i.e. OpenGL on iOS & Android, DirectX on Windows Phone).  Though the UI work is much more difficult and time-consuming in the gaming tools, one key benefit is that it is possible to re-use the same user interface across all mobile platforms. This can be a good option if an app truly needs a unique, game-like interface.

Titanium and CodeNameOne work similarly for UI development, but use a very different paradigm than Xamarin by attempting to be 100% portable between platforms – a single generic UI is created, which the tool then attempts to translate across platforms – substituting native, platform-specific UI elements where appropriate.  The downside of this approach is that given the differences between the UX on each platform with regards to navigation, layout, and UI components – developers are left with the lowest common denominator of the user interface between each supported platform.

Each of these tools has their own benefits and disadvantages, and each has specific development scenarios where they excel.  To recap:

Xamarin:

  • Use existing C# code and Microsoft development skills
  • Re-build UI on each platform
  • Take full advantage of native UX on each platform

CodeNameOne:

  • Use existing Java code and development skills
  • UI code is shared between platforms, but translated to match native look and feel

Appcelerator Titanium:

  • Use existing JavaScript code and development skills
  • UI code is shared between platforms, but translated to match native look and feel

Corona, MonoGame, Unity 3D:

  • Best options for building cross-platform games
  • Single, common UI is shared across all platforms

In the next part of this article, I’ll discuss how to build cross-platform native apps with Xamarin and an emerging open source library called MVVMCross that allows you to share significant amounts of code between applications.

West Monroe Partners is a Xamarin Premier Consulting Partner, and our team has extensive experience in creating native, hybrid, and web-based cross platform mobile apps. Contact us to find out more about our mobile application solutions.