2015-03-02

Preface

During the past 4-5 years, the mobile app development industry has been thriving and being continuously evolving. The industry itself is now not only about smartphones and tablets, but also cross the boundary reaching to wearable devices and Internet of Things (IoT).

In 2014, the top two mobile platforms, iOS and Android, both released their wearable solutions (Android Wear and Apple Watch). And at the same time, more and more home appliances were coming based on the ‘Internet of things’ projects.

Coming in 2015, one of the biggest challenges to our mobile app developers is:

How to shorten the the development lifecycle and support multiple mobile platforms quickly and easily?

Apparently, the philosophy of Cross-Platform Mobile Development perfectly fits to this question – one development, multi-platform deployment.

In this post, I will discuss about several general trends about “Cross-Platform Mobile Development” from a developer’s perspective. And hopefully it can give you a better picture of “what is the current status of it and how can I choose to do the development”.

Mobile Development

Before we stepping into “Cross-Platform Mobile Development“, let’s firstly take a quick look at the “current status of Mobile Development”.

In general, nowadays when a developer coming into the arena of “Mobile Development”, two criteria needs to be considered:

  • Platform (OS): The platform / device to be targeted.
  • Programming Language: The coding languages that the platform supports “by default“.

When talking about “default” languages, it usually means “better tools” (like SDK, IDE, Simulator and Testing Kit, etc.) as well as “better support” (like Documentation, FAQ, Community, etc.)

Platforms and Programming Languages

Nowadays the developers can actually have too many mobile platforms to choose, including the “sunset” ones (like Symbian, BlackBerry, Palm, etc.), some “big-player” ones (like iOS, Android, Windows Phone), and some “new-emerging” ones (like Firefox OS, Ubuntu Touch, Tizen, Sailfish OS, etc.)

You can check this wikipedia page for more mobile OSes.

And about the programming languages, for our developers, it is always the best case if you can pickup the “default” ones of the platforms you select because of the “better tools” as well as the “better support”.

Here is the matrix of several “major platforms and their default languages”.

PlatformsDefault” Programming LanguagesAnnotations
AndroidJava, C, C++76.60% in World-wide distribution
iOSObjective-C, Swift19.70% in World-wide distribution
Windows PhoneC#, Visual Basic, C, C++ or HTML5+CSS+JavaScript2.80% in World-wide distribution
BlackBerry OSJava
FireFox OSHTML5+CSS+JavaScript
TizenC, C++
Ubuntu TouchQML, C, C++

The data of “World-wide distribution” are from 2014 Q4. For more platforms, you can check this wikipedia page.

Apparently, targeting on both “both” Android and iOS should be the first choice because of their almost 100% coverage in the current market. However, this choice would also bring too much difficulty into development lifecycle since developer cannot use the same programming language to cover both platforms.

And this is why we bring the concept of “doing Cross-Platform Mobile Development”.

Cross-Platform Mobile Development

Correspondingly, the introduction of Cross-Platform Mobile Development is aiming to solve two sets of problems:

  • Platform Coverage: Do “one development” to cover multiple platforms.
  • Language Selection: Free developers in choosing programming languages.

Nowadays, there are two “general” approaches when adapting Cross-Platform Mobile Development:

  • Hybrid App: Mainly based on HTML5 App rendering by a WebView within Native Shell like Apache Cordova (formerly PhoneGap).
  • Compiled Native App: Compiled to the Native App before deployment.

HTML5 App: App that runs within Browsers, more like a website. It uses standard web technologies, like HTML5, CSS and JavaScript.

Native App: App packaged by using the “default” development tools as well as the language supported by the respective platform, like Xcode and Objective-C/Swift with iOS, Eclipse/Android Studio and Java with Android, Visual Studio and C# with Windows Phone.

Hybrid App

Hybrid App uses a web view (UIWebView / WKWebview on iOS and WebView on Android and Windows Phone) to present the HTML5 app in a full-screen format. Since the app itself is still rendered by the native browser rendering engine, it cannot get access to some native device capabilities, like camera, calendar, geolocation, etc.

In order to open this access, it leverages a abstraction layer provided by the native Shell (like PhoneGap). This layer exposes a JavaScript API so that the HTML5 app running inside can easily call.

Compiled Native App

Compiled Native App, on the other hand, is still a “Native app” when it is shipped and being represented in front of end users. The major difference from a “Normal Native App” is the way of “How it is developed”.

The magic behind this approach is “the tool will compile the code into the platform-specific byte-code (native byte-code) which can be run natively in the respective platform. In other words, developers can pick whatever programming languages they are familiar and write the code. And all the other work will be handled by “the tool“.

The following is a chart that shows the popularity of programming languages changes during the past 15 years.

Popularity of Programming Languages Changes from 2001 - 2015

The data are from TIOBE Index.

From this list, let’s try to check one by one to see if our developers can pick to do “Cross-Platform Mobile Development”.

Programming LanguagesToolsAnnotations
CCoronaCorona’s programming language is Lua, which is written in C, making it a cross-platform language.
JavaCodename One, Tabris, J2ObjC, RoboVMJ2ObjC and RobotVM are only Java language compiler for iOS.
C++Qt, Cocos2D-XCocos2D is used to build games, apps and other cross platform GUI based interactive programs.
Objective-CCocos2d-Swift
C#Xamarin, Cocos2dXNAXamarin provides standalone IDE.
JavaScriptAppcelerator Titanium, tabris.js, Cocos2d-JSTitanium provides standalone IDE.
PHPAppscendAppscend uses IgniteMarkup and DolphinPHP.
PythonCocos2d(Python)
RubyRubyMotion

The list should have more!

Regarding to “Appcelerator Titanium“, people are still debating which architecture type it belongs to: Hybrid App (confirmed when it is prior to 1.0), Compiled Native App (see here and here), JavaScript Runtime App without Native Compiling (see here, here and here).

If you want to know the “pros and cons” for each of these tools, you can easily search in Google by “{tool} vs {tool}“.

Here is a post from Harry CheungMobile App Performance, discussing about the performance of Xamarin, J2ObjC, RoboVM and RubyMotion. It should cover most of the interests when we think about doing development of “Compiled Native App“.

Hybrid App vs Compiled Native App

There are “pros and cons” for both approaches.

ProsCons
Hybrid App
  • Benefit from the “easy and fast” “web development” techniques – HTML5+CSS+JavaScript
  • Need native development when accessing to the device capabilities.
  • Performance issue (UI layout).
Compiled Native App
  • Native shipment.
  • Performance (almost like the Native).
  • Learning curve (not for the language itself)

To Go Native, Or Not To Go Native, That Is The Question!

The Trends

Usually, the trends come from the “pros and cons” of the existing tools / frameworks. In “Cross-Platform Mobile Development“, the most interesting trends are all currently on the JavaScript side, such as:

Most of the tools / frameworks discussed in this section are still in the active development phases. Some of them have not even open sourced yet.
If you have interests, please watch closely to their updates.

AngularJS Related

AngularJS, the JavaScript framework from Google, is one of the top Javascript stacks which provides a complete framework (MVC or MVVM) for building web apps. Its core concept – “Angular Directive” (conceptually similar to Web Components but implemented without the use of the Web Components APIs) – brings simplicity and efficiency to build up custom elements and reuse them.

Ionic Framework and Famo.us+Angular would be the most famous ones.

You can also check Onsen UI.

Ionic Framework

Ionic Framework Logo

Relying on AngularJS to do building-up of application structure, Ionic itself mainly focuses on the user interface end, providing a set of Angular directives (custom HTML elements), which helps easily and quickly construct an basic skeleton with lots of UI components and features. Besides, Ionic uses Angular’s touch recognizers, view animation logic, HTML sanitation, and asynchronous communication.

Ionic also provides Ionic Box (a Vagrant based VM solution) to help Windows users to do faster hybrid development with Ionic, Cordova, and Android.

One the other side, Ionic Creator is a kind of an IDE/GUI tool that Ionic Framework team are trying to offer for drag-and-drop creation of basic templates for Ionic applications.

Famo.us+Angular

Famo.us+Angular

Famo.us is a free, open source JavaScript framework that helps you create smooth, complex UIs for any screen. Basically, It uses its own JavaScript rendering engine that works with the GPU acceleration provided by CSS3 3D transformation functions to make animations as smooth as can be at 60 fps. Not like other frameworks in rendering DOM elements, Famo.us does not use the DOM at all — instead creates its own DOM rendering tree.

Famo.us+Angular is a library that lets you use Famo.us in Angular and Angular in Famo.us. Using F/A, you can:

  • Create Famo.us apps using familiar AngularJS tools like controllers, directives, and services.
  • Bring rich Famo.us animations to new or existing AngularJS apps.
  • Use HTML to declare Famo.us UIs, complete with Angular’s two-way data binding.
  • Easily integrate Famo.us and AngularJS apps.

Comparing to Ionic which starts from UI ends, Famo.us started from the performance, efficiency, physics and animations end.

ReactJS Related

Unlike AngularJS, ReactJS is not an MVC framework which can facilitate the building of overall application structure. Instead, it more focuses on building User Interfaces, by using a totally different (mostly more brilliant) way in dealing with the UI updates (more precisely DOM updates) – It renders only what’s changed.

ReactJS

In order to achieve it, it uses “virtual DOM” to represent the “current” state of the DOM as well as the “to-be” state of the DOM, calculates the difference between these two states and then apply the minimal diffs on to the real DOM.

DOM Updates – A Traditional Way:

DOM Updates - A Traditional Way

DOM Updates – React’s Virtual DOM:

DOM Updates - React's Virtual DOM

Check this post for more technical details about ReactJS – React Demystified.

With the help of Flux, React+Flux can become a very powerful framework to build client-side web applications (still not MVC).

TouchstoneJS is a ReactJS powered UI framework for developing hybrid mobile apps.

JavsScript Runtime

As we mentioned earlier, Hybrid App always bears performance penalty because of its running nature – “container“. In other words, it does not only depends on the platform it runs on, but also depends on the “container” it runs in — the web view.

Especially on iOS platform, the performance of a web app running inside a web view is usually about 4 times slower then it running inside the normal native browser – Safari. In iOS 8, the SDK introduces a new set of APIs for WKWebView in order to provide a web view container which has performance equivalent to Safari (see this post for more details).

Sunspider Tests - javaScript Benchmarks under iOS 7 & 8

Source: http://www.sencha.com/blog/apple-shows-love-for-html5-with-ios-8

However, no matter how the web view being evolved, the way of using “extra container” always brings extra performance penalty to Hybrid App. Then, how about bypassing the using of “web view container” but still leveraging the power of “web technologies“?

Using JavaScript Runtime can actually meet this goal, which is the biggest trend of Cross-Platform Mobile Development recently.

Here are several most interesting tools/frameworks that use JavaScript Runtime:

The JavaScript Runtime enables to use JavaScript code to call APIs in the native frameworks on different platforms. When using it,

  • The UI and business logic is written by JavaScript, plus HTML and CSS (or similar technologies, like XML).
  • The code does not need to be “compiled” into native byte-code before running. Instead, a part inside (called JavaScript Virtual Machine or any equivalent) will be used to interpret and execute the code and then TRANSLATE the calls to the underlying platform-specific APIs.

Appcelerator Titanium Architecture

Appcelerator Titanium Architecture

Telerik NativeScript Architecture

Telerik NativeScript Architecture, source

Among these three, React Native is the youngest one, but almost the most appealing one since it is based on the revolutionary JavaScript framework – ReactJS.

React Native is just introduced in React.js Conf 2015 in January, and will be open sourced later this year.

React Native

Although Facebook has not revealed too much technical details about “React Native“, from Tom Occhino’s keynote in React.js Conf 2015 and the posts of other conference participants, we can still catch several uniques of it.

  • Leverage ReactJS’s unique web UI rendering techniques.
    • It uses Virtual DOM to handle the “expensive” DOM updates.
    • It uses JSX (a HTML-like declarative markup) inside JavaScript to help represent Virtual DOM.
  • Leverage ReactJS’s unique “one-way” data flow
  • Asynchronous communication protocol
    • JavaScript Runtime as a separate, background thread.
    • Never block the native thread (main thread).

Here is an example of “JSX“:

<View style={{marginTop: 20}}>
    <Text>Checklist</Text>
    <TextInput
        style={styles.input}
        autoFocus={true}
        onSubmitEditing={this.handleSubmit}
    />
    <View style={styles.list}>
        {this.renderItems()}
    </View>
</View>

The rendered UI is like the following. In the markup, View and Text are all React Components, and they will be translated into Native UI elements, like View will become UIView in iOS and View in Android.

React Native UI Example

Here is the general demonstration of Asynchronous Communication.

React Native - Asynchronous Communication

Learn once, write anywhere! — React Native

Conclusion

Along with the rapid evolution of Cross-Platform Mobile Development, the difference between platforms as well as programming languages will never become the obstacles for developers to join the party.

For web developers, doing “Hybrid development” will not be the only choice. By using the approach of building native apps using Web technologies, they can build up a JavaScript Runtime native app running on any mobile device.

Although the performance of Hybrid app has been improved dramatically by new releases of platform OSes, it will never be on par with native app. However, as improved, hybrid app becomes “good enough” for an increasing number of apps. In the near future, doing Hybrid app will be still the main stream.

Furthermore, some apps are using completely custom mixes of HTML and native code, like iTunes Store app on iOS. It uses native code for its header and navigation, but Web-based code to build the content.

iTunes Store Mixed UI

Image from The State of Hybrid Mobile Development

Try React Native!

The last, if you would like to try Hybrid app but also like to keep track with the native app development, I would recommand React Native!!

References






Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>