Tag Archives: native

Native apps vs HTML 5: no consensus over how to choose

Wondering whether to invest in native apps or HTML5 web apps (maybe wrapped as native) for your next mobile development project? Welcome to plenty of confusion about which is the best path to take. Here are a few pieces of evidence from this month:

A Compuware survey of 3,500 consumers showed a preference for mobile apps over mobile websites:

When consumers were asked about the benefits of using a mobile app versus a mobile website (a website that is specifically designed to be viewed on a mobile device), the majority (85 percent) said they preferred mobile apps primarily because apps are more convenient, faster and easier to browse.

Just 1% expressed a preference for mobile websites over apps. Note that consumers cannot be expected to know whether or not a native app is actually written in HTML5 or not; but here is an intriguing report from Xero, which makes accounting software:

Very early on we chose to build Xero Touch using HTML5 technologies. That choice showed that we care about the future of the open web and its continued success as an application delivery platform and we firmly believe that HTML5 is the future of development across any and all platforms. We do not regret this choice – but we’ve found that building a complicated mobile application in HTML5 has been hard. Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex.

… the lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go … Maintaining and iterating a web app was becoming a big impediment – so the next release of Xero Touch will be built with native technologies and we’ve already made a lot of progress. It does feel better.

If a company is so unhappy with its development platform that it is willing to endure the pain and expense of switching, that is evidence of deep dissatisfaction.

On the other hand, here is the UK’s Government Digital Service:

Our position is that native apps are rarely justified. Since November 2012, central government departments and agencies have to get approval from Cabinet Office before starting work on apps. For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs, especially if the underlying service design is sub-optimal. Departments should focus on improving the quality of the core web service.

Is this because the Government Digital Service is spending public money and therefore apps are an unnecessary luxury? That is arguable, though it has not stopped the BBC (also publicly funded) from delivering a ton of apps, to predictable complaints from owners of less favoured platforms like Windows Phone.

This one will run and run. HTML5 will get better, but so also will native platforms, so I doubt this difficult choice will get easier any time soon.

It may be a matter of whether your particular app is a good fit for HTML5 or not. However, I am not aware of any consensus over what characteristics make an app a good or bad fit for an HTML5 solution, except that for broad reach HTML5 cannot be beaten, and for full access to device and OS features there is no substitute for native.

Is Appcelerator Titanium native? And what does native mean anyway?

Of course we all know that Microsoft’s IE9 and the forthcoming IE10 are native – VP Dean Hachamovitch said so many times during his keynote at the Mix 2011 conference earlier this week. That has sparked a debate about what native means – so here is another interesting case.

Appcelerator’s Titanium cross-platform tool for mobile development is native, or at least that is what it claims:

image

Now, I am not sure that native has a precise definition, but to me it suggests a compiled application, rather than one interpreted at runtime. So this description of how Titanium executes JavaScript – its main language – is surprising:

In a Titanium Mobile application, your source code is packaged into a binary file and then interpreted at runtime by a JavaScript engine bundled in by the Titanium build process. In this guide, you will learn more about the JavaScript runtime environment that your code runs in. Titanium runs your application’s JavaScript using one of two JavaScript interpreters – JavaScriptCore on iOS (the interpreter used by Webkit) and Mozilla Rhino on Android and BlackBerry.

So a Titanium application is actually interpreted.

Native is a vague enough term that Appcelerator can no doubt justify its use here. “Native UI” is fair enough, so is “Native capabilities.” Native performance? That seems to me a stretch, though JavaScript performance is good and constantly improving. Appcelerator even has a web page devoted to what it means by native.

Titanium is also open source. Anyone doubtful about how it works need only consult the code.

In the light of Microsoft’s statements, it is interesting that what Appcelerator really means by native is “not a web page”:

Build Native Apps … Everything else is basically a web page.

So can an application be both native and interpreted? What about Silverlight apps on Windows Phone 7, are they native? Adobe AIR apps, surely they are not native? Google Android has a Native Development Kit which is introduced thus:

The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code.

The implication is that byte code executed by the Dalvik virtual machine, which is the normal route for an Android app, is in some sense not native code. Which also implies that Appcelerator’s claims for Titanium are at least open to misunderstanding.