When I told friends and colleagues that Player FM would soon have a native Android app alongside its browser-based web app, it took them a while to get their heads around it. For perspective, I was known not just as a “web versus native” guy, but pretty well as a “web pwns native” guy – in fact, that’s more or less what I argued at Google IO 2011, and so naturally people expected me to stick to my story. If not a pure mobile web app running the browser, at least an HTML5-powered native app.
We’ve seen more than triple the signups in a month of mobile than we did in almost a year of being web-only. While we don’t get to run controlled experiments in the real world, that’s a pretty telling statistic, and one I suspect could not have been achieved by doubling down on the web app. Below, I outline my other considerations and lessons learned in the past few years, and what finally made me go native.
The ability to act as agent, not just app
“App” is an understatement for many things running on smartphones today. Think about payment systems using geofencing so you can make digital purchases without even touching your phone. Fitness tools tracking location, snapping photos, and monitoring your heart rate without any user intervention. Aggregators preemptively downloading media in anticipation of the user’s needs. All of these are acting more like intelligent agents than traditional applications. They augment our senses and abilities, applying hardware, software and cloud services to provide us with personalized assistance, 24-7.
This class of application stems naturally from the paradigm of desktop-native apps, which have always used a combination of background processing, interrupt mechanisms and bare-metal hardware access. In contrast, the web paradigm is document-centric: The archetypal web app is fundamentally visual, sits in its own sandbox, and goes away when the user closes the tab. Making a web app into an intelligent agent means grafting these newer features onto the web’s document model, which is more open-ended than, say, introducing a new menu or canvas component.
Chrome alone has jumped from background pages to background apps and now packaged apps – none of which are compatible with other browsers or OSs. When it comes to these subcutaneous features, there are risks of fragmentation that will take years of hard work to neutralize.
Access to multiple “surfaces”
A further point about the web’s document-oriented heritage is that it specializes on the sovereign posture, meaning a single, full-screen app dominating the user’s attention. But smartphone users demand alternative surfaces such as widgets and notifications. While the latter is starting to get support in HTML5, it’s often difficult if not impossible to construct these UI surfaces from the browser, and even HTML5-powered native apps are limited in their means to provide rich, interactive interfaces outside of their primary arena.
Lack of ubiquitous internet access
An unfortunate reality: Even in 2013, mobile apps simply can’t assume they’ll be in range of a fast, always-on internet. This gives native apps a natural advantage, as they can be downloaded once and run offline. The modern web stack has offline technologies too, but they remain immature and heavily fragmented. For example, the application itself can be saved using the App Cache API, but Jake Archibald’s “App Cache is a Douchebag” is actually a fair treatment of its current state. It can certainly work — as Jake demonstrated with Lanyrd’s offline-friendly website — but remains sufficiently troublesome for the web community to be rethinking the whole concept.
As for data, there’s a whole menagerie of options and no clear-cut winner. Web storage is easy and portable but low-capacity and slow at times. Web SQL is familiar, but eschewed by Firefox and IE. Indexed DB is supported by more browsers (at least recent versions), but won’t work on two extremely important ones: Safari and the stock Android browser. That’s just structured data – now consider storage of large media files and you’re in for a world of propriterary APIs and even more fragmentation, with many browsers offering no support at all.
Background memory management
HTML5 now has video and audio, but many users want to listen to them while running other apps, or with the screen turned off altogether. Android stock browser has a critical bug which causes it to resume playback after a phone call or text message, even if it was paused before. Android Chrome had no support for background media altogether in its first year.
These issues aside, a fundamental problem remains across all browsers: memory management. Browsers will habitually shut down tabs even if they are in the middle of playback. There’s no way to declare, as native developers can, that this app has priority and is not to be toppled on a whim. This issue affects not just media but any interactive web apps. That’s a huge problem for long-lived applications.
Look and feel
The HTML5 “write-once, run-many” argument was more compelling when platforms lacked strong visual identity. A bespoke, run-anywhere, HTML5 UI could be just as good. These days, that’s just wishful thinking; Android, Windows, and BlackBerry have joined iOS as platforms with distinctive look-and-feel – and have discerning users who truly give a damn. So while HTML5 still aids reuse in some areas (subject to the fragmentation concerns mentioned above), user interfaces must be customised to build a great app. Even then, there are inevitably telltale signs and a lot of performance work that could be avoided in native platforms.
So much for technical issues. What matters to most app developers is discoverability and here it’s a dual-edged sword. In the web’s favor, search engines are about the greatest distribution channel ever invented , and that alone is a good argument for web presence. Sharing, too, is frictionless – just about anyone can open a URL on any device. However, until search engines get serious about indexing apps, stores really do make a difference and an app launch carries far more weight than a website that’s suddenly gone mobile. (In Player FM’s case, we were fortunate to receive reviews from LifeHacker, Tested, and others without even pitching them, but it’s hard to believe any amount of flag-waving would have led them to write about a random startup’s website going mobile.)
“Native versus web” is a non-question: Most services need native apps and a web presence. The real question (beyond which comes first) is how do you build those native apps? “HTML5-native” (PhoneGap style) versus “pure native.” If you have a unique service, e.g. a specialised enterprise app, HTML5 could be ideal, a convenient way to build quickly and portably. But if you want your user experience to really excel, native is still king – for now.
Have an idea for a post you’d like to contribute to GigaOm? Click here for our guidelines and contact info.