Native vs. Hybrid vs. HTML5: the enterprise perspective to mobile app deployment

Mobile apps are the hot topic of 2013. Lately I’ve participated in numerous seminars and taken the time to read articles and blog posts to gain a better understanding of the subject. There seems to be a war going on – companies in the business either toot for one truth (usually that native aps are best) or take a more liberal approach warning only about the risk of analysis paralysis (in other words, don’t over think).

Big companies like Google and Microsoft are investing millions to get developers to use their platform – Everyone is in for the  money. In the world of internal enterprise applications the emphasis is a bit different – it is all about the balance of cost and end user value.

So, when working on a internal solution you have two advantages on your side:

  • You can define what platform the users should use and even provide them the hardware. A decent smartphone costs around 200€ per unit. So e,g, for a sales team with 10 members, it most likely costs less to update their phones than to try to support 2-3 different operating systems – and who would say no to a brand new device?
  • For the external users we have no control over HTML is the only standard that will work on all imaginable devices now and in the future without extra effort. It is surprising how much device functionality is accessible through JavaScript.

In the table below, I’m comparing the 3 different options for app deployment from the enterprise perspective:

Feature Native Hybrid Mobile Notes
Deployment cost across multiple platforms Single OS support, depending on case multiple versions (e.g. Android 4.x) or a single (e.g. Windows Phone vs. Windows 8 Phone) is supported. Code sharing possible. Multiple OS and versions, depending on product support. Some OS dependent rework (e.g. UI) usually required. Works on all platforms, including desktop and mobile devices. Support for HTML5 features varies by browser.
Updating and control over distribution App stored based deployment requires strict compliance with OS vendor specifications resulting in delayed updates. Possible workarounds for internal apps (e.g. company HUB for Windows) requiring usually MDM system for deployment. Usually some sort of paid phone developer account required. App store distribution possible. Updating without resubmission. No explicit distribution required, always most recent version online. Own or leased infrastructure required (web server).
Development and building The vendor of the OS usually defines the tools and platform you have to invest in. Often a mixture of common and proprietary tools. Deployment to e.g. iOS requires often a Mac even if you can develop on a PC. Any text editor will do.
Monetary benefits   Not applicable for internal tools
High performance Best Adequate
User experience and native look and feel Pixel perfect  Not often so pixel perfect. Usually UI must be (re)design per supported platform. Responsive design adapting to screen dimensions. Frameworks available to give native look and feel.
Availability of developers and level of experience Available skills depend on popularity of platform. Chance of finding someone who knows multiple platforms well is small. Same tooling might apply as for rich client development. Experts usually more costly. Often requires some specialized product dependent skills. Easy to find skilled web developers. Wide open source communities.
Platform stability Changes often with every new OS release (1-2/year). Changes require recompilation. Availability of support for latest OS releases and features dependent on product. HTML standard is updated once in 5 years with backward compatibility. Support for features intorudced by standard increase by time.
Graphic support Full support Product dependent WebGL for 3D
Access to device services and functions Full support Product dependent, usually possible to map to OS specific libraries. Support for most functions (etc. Camera and Geolocation, phone state), isolated from the native ecosystem.
Support for touch screen devices Full support Some gestures supported
Protection of application and data security Source code closed in the same way as with desktop applications. Common methods of data protection and isolation available, therefore considered often more “secure”. Application code can be obfuscated. Data more difficult to explicitly protect, but a secure connection, browser and the OS provide already a decent level of protection In general local data should not be trusted
Support for offline use Yes Yes Yes (local storage, events, file system). Support is browser dependent.

Hard to choose?

A good rule of thumb is to go native if you are building and mobile client for a rich client application and go HTML5 if your system is already web based.


The evolution of web development

Now over 13 years back I worked as a professional web developer. In those times JavaSscript was just something used to validate forms and anything else (e.g. toggling the visibility of a element) was considered fancy and labeled as DHTML. Few weeks ago I got a email from a co-worker having problems with including inline JavaScript in a ASP.NET razor page – this got me on memory lane.

Back in the days the code to open a popup window could look like this

<p><a href="'','mypopup')">Open google!</a></p>

This not only displayes as a scary link in the browsers status bar but also is useless in browsers not running JavaScript. So quite quickly the developers shape up and started putting the code in a separate JS file and using the events available:

function popitup(url) {,'mypopup'); }
<a href="" onclick="popitup(this.href);return false;">Open google!</a>

This was fine for many years. But then it became modern to write nonobtrusive code (keeping the scripting and visuals separate). Even if this in practice requires a lot more code frameworks like jQuery make it easy.

window.onload = function() {
var myPopupLink = document.getElementById('myPopupLink');
if(~myPopupLink) myPopupLink.onclick = function() { popitup(myPopupLink.href); return false; }
<a id="myPopupLink" href="">Open google!</a>

What next?