Blog Post

Going native: Why a veteran web developer finally turned to OS-native apps

Stay on Top of Emerging Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

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.

Michael Mahemoff previously worked at Google and is founder of cloud podcasting service 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.

27 Responses to “Going native: Why a veteran web developer finally turned to OS-native apps”

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

    What do you mean by UX? If you’re referring to visual appeal, well first – that’s subjective. Second, try taking a look at what serious designers can do with CSS3.

    The ideal UX is being able to accomplish a task efficiently and effectively. Both web and native can have good and bad user experiences, depending on what the user is trying to do. You should have said something like this: ..if you want me to think your user experience excels, native is king.

  2. Vlad Weber

    Many people want mobile apps but think it is too hard to create them. Fortunately now there are quite a lot of useful online services which allow building apps without programming skills and in hours. I am using SnAPPii at the moment and really glad I can feel like a mobile app developer and make apps on my own. Both native and HTML5 apps can be created.

  3. The move has nothing to do with HTML5…..I like HTML, its nice……except it came with all the baggage HTML 1-4 had.

    They never got rid of the old garbage.

    You completely rewrite HTML for modern development and maybe the “web pwns all” argument might sit…..

    But as of now? Creating an app on android to cross multiple versions is as simple as telling the Eclipse SDK which versions to target…and it’ll let me know what I can and can’t use….

    Opposed to spending hours of cleanup and querk fixes or unreadable generated code.

    I’d rather develop on 4 mobile platforms then deal with cross browser issues that have been around for over a decade.

  4. Blackworld

    From a layman’s business perspective , Native apps are like high end glossy Magazines. They are generally beautiful to look at and play with, but they really don’t scale in marketing and usage terms. I really pity those who say native first! The whole native arena reminds me of app developers getting so excited about new toys to play with! There are so many walled garden issues around native, plus all the stats show most apps have a very limited shelf life. Once downloaded, the frequency drops like almost 99 percent! By all means, have an app but you’re making a big mistake by putting all your eggs into a walled basket.

  5. madmaw

    I do a lot of freelance app development, and I’ve come to the conclusion that the technology you choose really depends on the kind of app you are writing and who you’re writing it for.

    If your customer wants the best possible user experience, has a tonne of money, and a big team of developers, go native, you’re never going to be unpleasantly surprised (well, you will be less unpleasantly surprised) by the results of a native app.

    Unfortunately these customers are reasonably rare. Most have budget constraints, which is where decisions need to be made. If it’s a form-based app, HTML5 is a good option. I’m amazed that you managed to make a functional audio app in HTML5 on the mobile, what an achievement! If it’s a game, so long as they don’t want a native look, they’re in luck because there’s heaps of cross-platform game engines out there. If it’s anything else…well, I’m probably going to recommend they target a single platform.

  6. Martin Focazio

    Thank you for writing this. I’m something of a heretic at work in that I’ve remained an advocate for App vs. Native while all around me folks are telling me that I’ve got the wrong perspective on the whole issue. I keep reminding people that mobile devices are not just another web platform – and I think your statement that “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.” is one of the most compelling truths of the whole debate.

  7. Johan

    The dynamic and rapidly evolving world of web apps (browser tech, JavaScript, HTML5, CSS3, Polymer, AngularJS… ) etc is far more interesting than learning to wrangle Objective C or Java for native.

  8. Colin Eberhardt

    Not a bad article, but as others have mentioned, hybrid-apps using technologies such as PhoneGap overcome some of the limitations cited in this article. In order to gain a better understanding of the compromises you make by going with HTML5 I would recommend PropertyCross:

    This is an open source project that compares a whole range of cross-platform technologies, giving real examples.

  9. Bryan Post-kablammo Potts

    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.

  10. Asim Jalis

    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.

    • 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.

  11. Steven L

    >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?

    • playerfm

      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!)

  12. Henry Skoglund

    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.

    • 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.

  13. guest

    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.

    • 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.

  14. 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.

  15. tim peterson

    “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.

    • Martin Focazio

      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 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.

  16. 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.