The business case is simple: “If you want to build a device oriented application then you’re better off building a HTML5 web application as you can build once and satisfy all devices. This saves you huge amounts of money by not needing to build and maintain a separate native application for every platform.”
Sadly, whilst in theory the above statement is true, the practicalities are that this is a much less black and white decision. There are many limiting factors within the above assertion that don’t quite add up to such a convincing argument. We’re just not quite there… yet.
In this post we’re exploring some of the limiting factors and points to consider when deciding whether or not to focus on a HTML5 web app strategy, provide a native application for each platform or a combination of the two.
The device landscape is a very rapidly evolving minefield. Not only do we have many device manufacturers: Apple, RIM, Samsung, HTC, Nokia, LG, Motorola etc. We also have different operating systems iOS, Android, Blackberry OS, Windows Mobile, Symbian etc. It’s no wonder a “build once reach everywhere” approach is desirable! It is possible too, one thing the majority of devices have in common is some form of web enablement allowing them to render web content. This makes HTML an ideal content delivery mechanism, applying appropriate responsive web design (tailoring the content for the screen size) you can reach a near ubiquitous audience.
This is all well and good for pure content delivery, specifically document content. Things get a little more interesting when your content becomes rich (audio/video), interactive and engaging. From here on in the device and browser capabilities need consideration. This means in addition to the manufacturers and operating systems mentioned above, we also need to consider device model, browser, version numbers and even carrier capabilities when planning an application.
Chances are your application isn’t aimed at every single person on the planet and so there are more factors to consider than simply “how many eyeballs can I reach?”. Identifying your audience can help significantly in identifying the ideal delivery mechanism. Trends in device usage vary significantly geographically and demographically so it’s worth finding out as much about your users as possible and finding out device preferences and usage habits through research. Even better, do your own analysis if possible. If you have an existing customer/user base find out first hand their choice of platform. User habits are also a key consideration, just because users have a web enabled device does not mean they actually do browse the web. Likewise access to an app store facility does not necessarily entail the purchasing and downloading of apps.
As devices continue to evolve so do the features they offer and the fierce competition between manufacturers ensures devices are offering more and more capabilities. The latest browsers running on some devices do offer access to some of these device dependant facilities but are always behind the native implementations. By sticking to the agreed standards process there is an inherent delay in offering access to these new features, a sacrifce made in place of a common implementation. Even with features that are supported, at this point in time there can be differences in implementation until the standards are finalised.
The more mature features are somewhat well supported across the major platforms such as camera, location services and connectivity detection but there are still several important features for a more complex “application experience” that are not so well supported or even available at all:
- Background processing – the ability to perform long running tasks outside the scope of user interaction or even when the application doesn’t have focus. A commonly available facility on native apps that is not currently possible in browser.
- Intents / cross app integration – the ability to leverage other applications within your application e.g. an image editor or file uploader. “Web Intents” is in draft specification and Google and Mozilla are working together on a framework to support it but this is a long way of from broad support, particularly on devices.
- Local storage – There are viable approaches to data storage and file access in most of the latest browsers. However this can not yet be relied upon for broad adoption but the future does look promising.
In time all of the above will likely form a part of web application capabilities but right now they can not be relied upon for all users if essential to your application.
The development frameworks offered when creating a native application have an inherent “feel” to them provided by the standard components and development processes for that platform. Users will have expectations for how the application will behave in line with other application experiences they have. Web applications offer no such common approach. Users conditioned to the way applications look, feel and behave on their chosen device might not be as comfortable with an application that crosses platform paradigms. However it is certainly possible to create a poor native experience, just as you can create an excellent web experience. Due consideration to the users expectations for applications on their device should be paid.
App stores are built with a monetization model already catered for. If you intend to sell your application then the transaction process is predetermined with a native application. For web applications this is less clear. Subscription models and pay for access are viable approaches which have the advantage of not having to pay commissions to the app store owner. Bear in mind however, app store users are already conditioned to the payment process and may not be as comfortable with a break from the standard.
One thing we are sure of with regards to the future is that the web is going to continue to play a big part in it. HTML5 looks set to be responsive to evolution (hence why it is and will continue to be an evolving specification). A well structured web application can be open to extension and enhancement as new capabilities become standardised and commonplace. Choosing an app store has somewhat less certainty associated although it is certainly hard to see the powerhouses like Apple and Google losing traction any time soon.
As usual the answer comes down to “It depends” but we’ve explored a few of the key considerations when choosing your app strategy. There are also hybrid approaches such as PhoneGap that mix the benefits / drawbacks of each approach offering closer parity to device capabilities but with a dependency on a third party framework and similar issues with regards to user expectations.