27 Comments

Summary:

Argue all you want about the relative merits of web vs native apps, but the market is the ultimate decider. And, according to one previously stalwart web proponent, for now that means going native.

goingnative

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.

Discoverability

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.

Michael Mahemoff previously worked at Google and is founder of cloud podcasting service player.fm. Follow him on Twitter @mahemoff.

Have an idea for a post you’d like to contribute to GigaOm? Click here for our guidelines and contact info.

You’re subscribed! If you like, you can update your settings

  1. sergiandreplace Saturday, June 1, 2013

    Last but not least, Android WebView component is a complete mess. Full of bugs, undocumented behaviour, inconsistency among versions, etc. As far as I know, other platforms (iOS and WP) are not much better.

    1. Yes, Android WebView is still basically stock browser, and there’s a popular issue to change this:
      https://code.google.com/p/chromium/issues/detail?id=113088

      The main problem is back-compatibility, given that many apps already rely on WebView, with all its quirks. So if introduced, it would probably need to be a config option with both supported for a few years.

  2. “web pwns native”

    hahaha, good joke. better joke is that you actually believed this.

    1. That made me laugh also!

  3. tim peterson Saturday, June 1, 2013

    “But if you want your user experience to really excel, native is still king – for now.”

    This is the key sentence. Apple perfected the UI for developers so of course it “feels” better – for now. The financial motivations haven’t been nearly as clear for those making browsers, so of course HTML’s gonna lag.

    Make no mistake though, you can’t beat HTML in the most critical areas: ease of learning, # of devices it’s installed on, its open-source nature. This 3rd aspect is “king” and means the fake argument of native apps “feeling” better will ultimately be obliterated by projects such as Twitter Bootstrap.

    HTML is like Christianity or the English language, its gonna win in the end. Obj-C will be Judaism and German or Latin, not clear which but it doesn’t matter.

    1. HTML is easier for developers. Apps are (usually not always) easier for consumers.

      Follow the money – always follow the money. Objective C / iOS – represents the vast majority of commercial (paid) activity in mobile space. Bar none. There are exceptions, we know all about ft.com and so on. But the publishing of “printed” (well, text and pictures) information is not the same as an app that does stuff for you (as the author stated) and that’s the crucial difference. For what it’s worth, game consoles have the same basic challenge.

  4. David Mytton Saturday, June 1, 2013

    The biggest reason we had for switching from web to native for our server monitoring mobile apps was performance. You can get access to almost every feature of the native OS through APIs and to things like push notifications or the app store by having a wrapper app which uses a web view. But you still get significantly poorer performance.

    This is important for use cases like having a long list of servers you want to search / scroll through (and it’s where good memory management comes in), or graphical rendering. But I’ve also found terrible performance on web view implemented apps that are just essentially browsing the version of a service.

    Some of this is down to feature disparity e.g. the web view in iOS isn’t as powerful as Mobile Safari. But much of it can never be matched because you get such low level access to the OS APIs to get that extra performance. It’s like virtualisation – there’s always that extra layer.

    1. (I had some issue replying here earlier – please see my reply to Steven’s post below.)

  5. I think you make a good argument. However, if you’re a one-person shop, it’s just not feasible to have to develop and maintain code bases for two platforms. Also, not every application needs to level of functionality you describe. For many applications, a web version is just fine.

    1. I’m glad you highlighted this point. Many people can get by with just a browser-based app or PhoneGap style app working across multiple platforms. Especially for people who already have a HTML5 programming background, which is probably the majority of programmers nowadays.

  6. Nearly all of the issues raised in this article are addressed by Cordova/PhoneGap.

    1. If you have any examples of PhoneGap apps doing the things mentioned here in pure HTML5, I’d love to hear about them. It can be hard to find great examples as apps don’t always identify as being PhoneGap based.

  7. Henry Skoglund Saturday, June 1, 2013

    I used to think that web apps had at least one advantage over native: any updates to the code is seen by the user directly. The other side of the coin is like when Sen. McCain complains about having to update his native iOS apps all the time. This is one of the few areas where Android truly shines, i.e. when auto-updating your apps.

    If we can get that auto-update paradigm on all platforms, that would really benefit native apps vs. web apps.

  8. >Chrome alone has jumped from background pages to background apps and now packaged apps – none of which are compatible with other browsers or OSs.

    Are you saying the apps that run in Chrome for Windows won’t run in Chrome for Mac?

    1. David, people report a mixed bag about web performance. This is one area where it seems the web is actually closing the gap as HTML5 runtimes used to be really atrocious on mobiles. Also, there’s much more knowledge now about how to build faster web apps. Remote debugging and performance analysis is much easier, and people understand much more about how to avoid reflow events, etc. All that said, native is still considerably faster for anything complex, especially gaming.

      Steven, I really meant “web OSs” there; I was thinking of Chrome and ChromeOS, whose background mechanism isn’t compatible with Firefox OS, Tizen, etc. (Basically you can just ignore the OS comment!)

  9. It is not necessarily either-or. You can go native and still use HTML and JavaScript extensively in your native iOS app. The immediately benefit of this is portability. For hooks into the OS you can use Objective-C for now. Then as HTML support improves you can migrate to HTML.

    HTML is the classic disruptive play in the mobile space. It is barely good enough, but it will keep getting better.

    1. Pocket’s a good example of this, having used a clean HTML5 component for their main view for quite some time. A developer there told me they’re now moving to native, mostly for performance reasons, so it also shows how HTML5 components might be used to get up and running quickly before fine-tuning with native-specific components.

      HTML5 is indeed likely to keep getting better, but so will the native apps. A couple years ago, it looked like HTML5 was closing the gap, but so far it hasn’t happened that way.

  10. Bryan Post-kablammo Potts Sunday, June 2, 2013

    Make no mistake though, you can’t beat The Internal Combustion Engine in the most critical areas: ease of feuling, # of dealerships selling it, its repairable nature. This 3rd aspect is “king” and means the fake argument of electric plug-in cars “charging” batteries will ultimately be obliterated by projects such as Natural Gas Fracking.

    The Internal Combustion Engine is like Christianity or the English language, its gonna win in the end. Elecitr Cars will be Judaism and German or Latin, not clear which but it doesn’t matter.

Comments have been disabled for this post