In the mobile application space, the question of whether HTML5-based or native apps will prevail is a rather open one, the resolution of which will either “never” come (note that never hardly ever means never, though, right?), or at least accompany us for years. I believe it will not come in the foreseeable future, and I’d like to argue by comparing the “mobile” to the “desktop” world, or the “small screen” to the “big screen”. I will also list several factors I see as critical for deciding for one over the other approach.
Consider the “big” screen first. We today have 3 major OS competing: Windows, Mac OS, and Linux distributions. I’d say these systems base their success on the ecosystem of software built for them – the very same criterion for the success of a mobile OS, if you think about it. Windows, e.g., has been drawing its success from the Office suite for a long time – and still does in the enterprise. On the Mac, a lot of software commonly used under Windows did not exist for quite some time, which made Mac more of a special-purpose environment, something from which Apple has emancipated by now. Users today can achieve pretty much the same on a Mac as they can on a PC, with less and less compatibility issues. Linux is not relevant in the consumer space. (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems).
Developers choose which OS they implement their software based on the Reach (marketshare) of the OS, which constitutes my first decisive factor.
Detour: While we have been happily using the terms “software”,”programs”, or “applications” in the past, for some reason the term “app” has been established for software running on “mobile” devices (smartphones and tablets; laptops are also “mobile” to a lesser extent, but you wouldn’t call software running on them “apps”). The term “app” also involves a convenient distribution system, which is completely Web-based: the idea of “app stores”. These didn’t exist before with “traditional” software. You didn’t have one place to go to download software for your OS from, instead you either downloaded software from the vendor’s website with their own payment system, or you bought it physically as a CD or DVD. (Apple started to establish the online App Store idea with their “big screen” OS two years ago this month, with some success but also some skepticism attached to it, as described here: http://www.macstories.net/stories/mac-app-store-year-two/).
There is a difference in the type of software that you use through a browser and that has been built specifically for an OS. Typically, the Web-based software is used for “simpler” tasks. It usually lacks features, functionality and speed (in terms of execution) as compared to desktop software. I will call these the factors Complexity and Speed (usability).
Why is the Web-based version of software usually a little restricted in comparison to native? Mainly because it requires an intermediate interpreter, the browser, which is native software that has to be developed and maintained for the OS of choice. New features and functionality of a device/computer is first made available to the developer of the browser, only then for the developer of browser-based software that runs in the browser. Native software, however, is written directly for the OS. By skipping this intermediate software layer, native software is, by definition, always one step ahead and quicker to provide enhancements, which (should) result in usability improvements for the user.
You don’t have to “install” Web-based software on your OS – you only download its front-end, which happens automatically in your browser. It therefore has less of a Footprint on your machine. (However, on a desktop or laptop computer with big hard drives, this is less of an issue).
As an example, consider Office. If your job is to write whitepapers, you will have no issue to install proper software for doing so. Whitepapers often embed complex graphics, page layout, tables, etc.; you will not be able to do that properly in a Web-based system such as Google Docs (now available via Google Drive). This version of a text processing software simply is too restricted in terms of functionality for your job. However, if all you want to do is maintain a simple spreadsheet for travel expenses with your buddy you went on vacation with (where the collaboration feature of online systems comes into play, too), or write an essay like this blog post, then you’ll be fine with a Web-based version.
The factor of how often you will use the software (and thus how “relevant” it is to you), I like to call Relevance:
Consider software for managing your insurance policies and claims. This is something you don’t need to do that often, and it usually only involves looking at some numbers and text and changing a few values here and there. Would you want to buy software for that, install it, have it sit on your system permanently? Probably not. It is just not that relevant to your daily life. If you need to file a claim, you would probably prefer going to your insurer’s website once, provide your input in your browser, and be done with it, not leaving anything behind on your machine.
Depending on the factors Reach, Speed, Relevance, Footprint, and Complexity. one approach or the other will make sense for you as a developer, or a business. The mobile world introduces one more factor: Maintenance, or release requirements, which I will describe in the next section.
The factor of Footprint is a much more important one in mobile: you have rather limited capacity on your mobile devices, compared to hard-drives of your desktop or laptop computer. Footprint therefore is, in my opinion, quite a decisive factor for Web vs native. It is closely coupled to Relevance: if you want to check your car insurance policy or review health claims, do you really want to download an app for that, which uses space on both your device’s memory and on your home screen? I, personally, do not. I’d prefer a Web app that I can browse to when I need it. (I have, however, noticed that I like to have a “proper app” for services that are important to me, even if I don’t use them often. Loyalty apps for retailers I use often fall under this. But do not forget that even those could technically be a Web app, while still living on your home screen: as a simple bookmark, as opposed to software stored locally on the device. The online/offline argument does not apply here, as I always need an update anyway; I would not know what to do with my Starbucks app, e.g., while being offline. I can neither search for stores, nor see my current balance…)
Mark Zuckerberg made this infamous statement in September 2012 that choosing HTML5 over native for the Facebook mobile app was the biggest mistake they have made to date. Concluding that therefore native apps will prevail is, while tempting, very wrong though. Facebook is for many the app most frequently used on their smartphones. UI speed or usability is, above anything else, therefore the most decisive factor. Nothing is more annoying than having to wait for the app to respond if you quickly want to check for an update or look at a picture someone has posted. Even fractions of seconds matter here. And which approach do you take if speed is so important? Native. Does that mean that HTML5 is the worse choice for all mobile apps? Definitely not. Again, it depends on Reach, Speed, Relevance, Footprint, and Complexity.
One final factor exists only in the mobile world today: that of Maintenance. Native mobile apps can today only be released through the app stores of the respective OS’s. Desktop software does not have that restriction today, even though Apple introduced the same mechanism 2 years ago with their Mac App Store – maybe we will see this to be the predominant, if not only, way to install new software on any OS in a few years time.
Web apps, whether they run on desktop computers or mobile devices, do not have this restriction either. You can update a Web app/site live, without having to involve the maker of the end device’s OS. If frequent and timely deployment of changes to your apps is important for your business, native might not be the best choice. The following post describes the drawbacks of native deployment well, with the most annoying being delays: http://blog.mightbuy.it/2012/12/26/table-applications-for-businesses/.
So, to come to a conclusion here: I have tried to argue that mobile software pretty much follows the same rules as desktop software, albeit with a few obvious differences. The desktop world has seen the battle of Web vs native for much longer than the mobile world (the latter only really having come into being since the 2nd generation iPhone in 2008, which introduced the App Store). With the desktop, the battle is not over yet; or you could maybe even say: there is no battle. Both approaches coexist peacefully. Much like fish and human beings do. I believe the same is true for mobile apps. There will always be use cases for Web apps vs native apps. It totally depends on the six factors: Maintenance, Reach, Speed, Relevance, Footprint, Complexity. If anything, the number of OS and their marketshare will determine which approach is used more often. If we end up having 5 or more OS and ecosystems competing, companies will have to think twice whether they want to (or can) afford developing the same application that many times.
To finish up, here’s a decision graph helping to determine which approach is best for you, depending on the following factor hierarchy:
(The last factor, complexity, stands out a little, as you might have cases where a Web app simply cannot implement a feature you need. You will then have no choice but to go native.)