An overview of cross-platform development frameworks

Published in

in-Tact

8 min readNov 2, 2018

Nowadays, there is a clear battle between native development frameworks and cross-platform development frameworks. It may seems that the latter lead the path into the future of mobile applications development since they allow us to target multiple platforms at half the costs. However, if you ever had to develop a mobile application using a cross-platform framework, you know this is not entirely true.

Unfortunately, there is no exhaustive comparison of all available frameworks to help us decide over one or another, so we need to base our decision on intuition or the team’s current knowledge. Furthermore, there is no exhaustive list of criteria to help us decide if we should go for a native or a cross-platform solution, and a such decision is often taken only over financial reasons.

This article is the first one of a series of articles that we are going to publish about cross-platform development. The main goal of this first article is to classify the existing cross-platform frameworks based on the technical details of their architecture. That is, how they enable us to go from a single code base to one application for each targeted platform. The remaining articles of this series will cover topics such as: performance comparison, what criteria should we use to choose between native or cross-platform development, native vs cross-platform development, the future of cross-platform frameworks and developing cross-platform applications with Flutter.

From Responsive to App

When we design a new product that we want to be consumed by our users from a wide range of devices (e.g. mobile phones, tablets, PCs, TVs, etc.), we need to think carefully about all the available options that we can use to serve content.

Responsive website: website whose content will adapt to the user device’s screen. The users will access the web site the same way for each device: through the browser installed on the device.
Native application: a specific application for each target platform (e.g Android and iOS). We will be able to leverage the full native experience for our users, but we need to develop one application from each target platform and if we have a website we will probably need to invest to make it responsive.
Cross-platform application: a single application that can be packaged and run on several target platforms. Maybe we will not be able to leverage the full native experience for our users, but we only need to develop a single application. Furthermore, if the application has been developed using web-based technologies, we may even be able to re-use some of its content for a responsive website.
Progressive Web Application (PWA): a new paradigm where users reach your “web app” through the browser installed on their device, but then they can decide to add the app to the home screen. After that, they will be able to interact with your web app as if it was just another app installed on their device. Nevertheless, at the time of writing this article PWAs are supported on Android devices having an updated version of Google Chrome installed and on iOS devices starting iOS 11.3.

While for the Responsive, Native and PWA categories above there is clear choice of which framework or SDK we should use in each case, this does not hold true for the Cross-platform category. The available options in such category skyrocket and they all present different low-level technical details.

Classification of cross-platform frameworks

We can divide the spectrum of tools to build cross-platform mobile applications based on their “closeness” to web development or to native frameworks. As such, we can devise the following four categories ordered by the degree of inclusion of web-based technologies:

Hybrid frameworks
They embed the whole content of the application in a WebView inside the native package. These include: Adobe PhoneGap, Ionic, Framework7, Onsen UI, among others.
Hybrid/native frameworks
They use a combination of native UI components and transitions together with a WebView. These include: Astro and Project ACE.
Javascript Native frameworks
They use a Javascript library that provides access to native components through a bridge component. The UI is generated at runtime and is composed of native components. These include: Appcelerator Titanium, React Native, NativeScript, Tabris and Fuse.
Compile-to-native frameworks
They compile the cross-platform application code into native code which is then packed for each specific platform. These include: Xamarin, Flutter and RubyMotion.

The one thing all the above frameworks have in common is that they all generate a specific package or application binary for each target platform (e.g. an APK for Android devices and an IPA for iOS devices).

The following diagram summarizes all the above approaches and frameworks.

Internal architecture of cross-platform frameworks

The Hybrid approach

When we develop an application using a hybrid framework, we use mainly web-based technologies (HTML, CSS and Javascript) to develop both the UI and business logic of the application. Take for instance Ionic. It provides some specific UI components to make our application resemble a native application and these components are built together inside a .html file. Then, we use Angular to implement a UI controller and any other modules/services we might need (e.g. a network layer to retrieve content from a server).

At build time, all our application code is loaded into a WebView which in turn, will be packaged into a native application binary. At run time, the hybrid framework will also be responsible of handling user events and forwarding them to our application code within the WebView.

If we need to access some native functionality that is not available to a typical browser, we need to use the cordova plugins, a set of “libraries” that we can plug into our Javascript code and which provide access to more advanced device capabilities (e.g. camera, bluetooth communication, file system, among others).

The above approach is graphically displayed in the next figure.

The main benefits of such approach is that it allows us to develop new applications from scratch in a very short period of time and without having to learn platform-specific languages or SDKs. If you already are a web developer you will find the transition to this kind of frameworks to be very smooth. On the down side, performance issues can cause a bad experience for our users, especially on low-range devices. Although this has significantly improved over the years, performance is still the main drawback of embedded WebViews.

The Hybrid/native approach

The hybrid/native approach was introduced rather early to mitigate some of the performance issues of the first versions of the hybrid frameworks. Nonetheless, many will argue that this is still a hybrid approach since this model also relies on cordova plugins to access the Native APIs. We only mention it here for the sake of completeness.

The advantage of such approach is that allows us to use native components where needed, while still having the majority of the application code inside a WebView.

However, the steep learning curve of these frameworks together with the improvements in performance of the hybrid frameworks made the use of this approach to be discontinued.

The Javascript Native approach

The Javascript Native approach clearly differentiates itself from the hybrid approaches provided that there is no WebView involved and the application’s UI is entirely native (i.e. generated at runtime from either markup language or Javascript). Nonetheless, the application code is still developed in Javascript, allowing for a single code base.

This approach bring into scene two new components or actors, namely a Javascript Virtual Machine and a Runtime Environment. The Javascript VM allows the application to run on any device that has an implementation of such VM (e.g. Google’s V8 or Apple’s JavaScriptCore). The Runtime Environment enables all calls of the Javascript framework to be translated into Native APIs calls. As such, the framework provides a bridge to allow communication from Javascript to the underlying Native API. Furthermore, developed modules using native code can be included along with the application code in a more “natural” way.

The differences among the frameworks that follow this approach arise around the implementation of the bridge component and they vary from monolithic (i.e. a single bridge that does all the translations) to micro-bridges architectures (i.e. separated bridges for each component accessible on the native layer).

A simplified diagram of the Javascript Native approach is presented below.

The Javascript Native approach has a clear advantage in terms of performance as the code which is run is entirely native. The translation performed by the bridge still introduces an overload, but any native component can now be accessed directly without having to rely on an external cordova plugin. On the down side, frameworks under this approach present a steeper learning curve and we need to be aware of the specifics of each target platform if we need to use native modules.

The Compile-to-native approach

Completely cross-platform or cross-compiled applications are applications developed in a particular language and then compiled into native code at build phase. Hence any translations to native code are performed before the application is run and the result is a compiled application for each target platform.

An overly simplified diagram of this approach is displayed below.

Such approach provides a native-like performance since the resulting application binary includes direct calls to the underlying native APIs and there is no intermediary at run time between our application’s code and the native layer. However, we are constrained by the capabilities of the chosen framework to compile into native code (i.e. functionalities that are not included in the compiler or longer delays to include new functionalities from the target platforms’ latest versions).

Conclusions

In summary, we have a wide range of options to develop cross-platform applications and they all differ on the manner in which they generate the final product for each target platform. These range from hybrid approaches (i.e. embedding a WebView with the application code) to cross-compile approaches (i.e. compile our code base into native code at build phase), going through a mixed approach taking advantage of the Javascript engine (i.e. develop using Javascript and translate into native code at runtime).

Each approach described in this article has advantages and disadvantages in terms of performance of the resulting product, learning curve or maturity of the frameworks among others. Nevertheless, during this article we pretended to bring some light over the technical aspects of each approach so that you can make an informed decision the next time you need to choose a framework to build your next killer app.

If you are interested in reading more about cross-platform development, we recommend the following online resources:

Stay tuned for the next article in this series and, in the meantime, we would appreciate your feedback.