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?
In the table below, I’m comparing the 3 different options for app deployment from the enterprise perspective:
|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|
|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.