Thursday, January 8, 2015

The mobile dream: write once, run everywhere

It's come up before. Someone has a cross-platform mobile app written in HTML5 (HTML version 5 with CSS and JavaScript) and they're thinking of porting it to native to improve performance. But native can be very costly and HTML is a ubiquitous, cross-platform technology already baked into most (all?) smart devices (not to mention the web itself). HTML is also arguably one of the more productive user interface development technologies around, having had time to evolve since the inception of the web. And yet those pesky performance issues with HTML5 crop up on mobile devices. Hesitant button toggles. Flickering transitions. Noticeable screen redraws. Neither costly development or poor performance are very satisfying choices.

There are a variety of alternatives, each with benefits and drawbacks. In this post I'll attempt to survey the major options and end up coming virtually full circle to a practical approach I recommend considering: keep as much in HTML5 as possible and then optimize by pulling just the problems into native. The trick here is pulling exactly the problems into native: unless your problem areas exactly match what commercial native shells happen to provide (i.e. Phonegap, Trigger.io, etc.) it's probably easiest to provide the native shell yourself through some native coding.

But first, what are the major alternatives?

HTML5 packaged in native shell


Phonegap / Cordova

 

With this technology, an app is primarily written in HTML5 then bundled into a wide variety of native packages. Hardware services are provided through plugins and offered to the bundled HTML5 through a bridging API. App developers can add new plugins, which are developed separately in native code for each platform. Basic Phonegap is free and supports all major mobile platforms.

Phonegap apps are known as having performance challenges, some from the hosted HTML5 and others from the communication between HTML5 and native code. While it should be possible for Phonegap to improve HTML5 performance by using Apple's WKWebView in iOS 8, and it has been possible for Phonegap to improve its bridging communication for quite some time, it's mandate to serve the 'widest possible audience' means these potential improvements are still not available. It's tough trying to be everything to everyone without becoming barely average to everybody.

Trigger.io

 

Similar to Phonegap, much of a trigger.io app is written in HTML5 and bundled into native deployment packages, with native device capabilities like the camera extended to HTML5 though a bridge. Trigger.io also, however, exposes native UI components to the bundled HTML5 code through their bridge enabling hybrid user interfaces. Trigger.io claims their native to HTML bridge technology is up to 5x faster than Phonegap on Android. Trigger.io also supports writing custom native plugins, similar to Phonegap, which it calls modules. Trigger.io is offered through a monthly subscription and appears to only support iOS and Android. Trigger.io clearly aims to fill in where Phonegap falls short.

As with Phonegap, its value probably comes down to whether your performance issues happen to match what it can provide natively -- and how uncomfortable you are taking on a little native development.

RhoMobile Suite

 

RhoMobile apps are written in a combination of HTML5 and Ruby. Most views are written in HTML5 and rendered with the embedded browser component as with Phonegap, with the addition of controllers written in Ruby that can provide native functionality including native tab bars, navigation bars, map views, date pickers, and others. On BlackBerry, RhoMobile apps are converted to and run as Java bytecode. On iOS, Android, and Windows Phone, apps are compiled down to and run as Ruby 1.9 bytecode. RhoMobile has a free option on up to monthly per developer subscription price.

 

Interpreted

 

Appaccelerator Titanium

 

Unlike those described thus far, Titanium apps do not use an internal browser component. Titanium instead uses JavaScript, run in a JavaScript interpreter, to control native user interface elements through platform-independent JavaScript APIs. Since it can be a little hard to figure out how this works, here and here are two articles I found particularly informative. Titanium is open source and can build apps for iOS, Android, Blackberry, Tizen, and Windows Phone.

As with any fairly large body of technology (probably all included here!), issues have been noted with Titanium. It may be most suitable for prototyping as performance issues, difficulties in debugging, and memory issues have been noted.

Corona

 

Corona seems to be focused on the development of mobile games, although it can also build other types of apps. Apps in Corona are written in LUA and are probably interpreted by a proprietary interpreter written in C. Corona can produce apps for iOS, Android, Kindle, and Windows Phone and is priced on a per-developer, subscription basis.

Compiled to assembly 

 

Xamarin

 

Xamarin came out of work done on Mono, an open source .NET implementation. Xamarin apps are written in C# and can be deployed to iOS, Android, and Windows. For iOS, Xamarin produces a completely native app by compiling C# to ARM processor assembly. For Android, C# is compiled to .NET IL then packaged with the monoVM and JIT. Xamarin can produce apps for iOS, Android, and Windows Phone.

Not to pick on Xamarin but since I've heard it promoted heavily as a way to write once run everywhere I suggest reading this article if you're considering Xamarin for that reason.

Embarcadero Firemonkey

 

Firemonkey apps are written in Delphi or C++ and are compiled directly to processor assembly for both the iOS and Android mobile platforms, completely replacing native compilation. Firemonkey tools are priced in the $1000s per user range.

HTML5 (..and can be packaged in Cordova)

 

Another approach to improving HTML5 performance is to optimize HTML5 itself. This approach is, of course, limited in effectiveness by the performance of the browser running the HTML5.

HTML5 running in Safari or Chrome already benefits from improvements to both, and those benefits have been recently extended to the embedded browsers native iOS and Android code can host. HTML5 may not be able to fully compete performance-wise with native code yet, but clearly vendors are putting investment in this area and arguably the gap is closing.

A few HTML5 libraries of note, each of which can be natively packaged in Cordova, include:

Ionic

 

This mobile JavaScript library is focused on performance and features 'no jQuery'. Ionic JavaScript is structured MVC using AngularJS.

Sencha Touch

 

Sencha Touch is known for its good native look and feel and is also clearly sensitive about performance. It's also known to be a bit of a learning curve. It The challenge with Sencha, in my opinion, is that its focus on native look and feel suggests it may be a poor fit when using HTML5 as the cross-platform portion of an app.

jQuery Mobile

 

This library produces a native-independent look and feel, what you're usually looking for for the cross-platform potion of apps. It's fairly easy to pick up and work with in my opinion, but of course jQuery's focus on DOM manipulation doesn't result in well-structured code on its own. I found it performed adequately even in older Android browsers and agree performance issues others have complained about may be from some other cause.

Telerik Mobile

 

Frankly, I found it a real challenge to figure out what this thing is or does (can you figure out what all this marketing bling actually means?), but from what I can tell they provide the following mobile development technologies (in addition to other non-mobile ones):
  • A JavaScript library (with tools) to help produce HTML5 apps that adapt to each native look and feel 
  • Tools to package, manage, test, and analyze HTML5 apps packaged in a native Phonegap/Cordova shell.

 

Back to the beginning

 

Whew. A lot of different technologies to make the same code run on different devices, and there's even more than I mentioned. But do any of the alternatives really save on cost (time, money, headache) over what the mobile platforms themselves already provide?

I believe native will always have the most complete set of features, best debugging, best support, best compatibility -- you name it. It will be where you have to go in a pinch. And even the fiercest mobile competitors are taking HTML5 seriously so it's hard for me to recommend ignoring it.

In contrast, none of the alternatives have the same mind share, not even close, which adds to their long-term costs. How easy will it be to get bugs fixed when you run into them? How hard will it be to work around something when you need it done a little differently? How long will it take to learn? Frankly, how long will it continue to be a viable and supported product? A lot changes in a few years.

So, if you have a cross-platform mobile app written in HTML5 and need to improve performance, consider pulling the performance issues into native before you pull the plug and either go all native or with a completely different alternative. If the existing technologies that package HTML in a native shell don't let you move performance issues to native exactly where you need it, consider rolling your own. Doing so isn't hard if you're handy with a little native development -- certainly not harder than tackling a whole new development platform -- and it enables you to use both native and HTML's strengths when and where you need them.

Tell me what you think. It's a big topic and of course there aren't really any simple answers.