Application delivery on mobile devices: App Store/Native vs. Browser/HTML5

by john on February 3, 2011

I was noting to an entrepreneur friend Facebook’s recent decision to deliver their mobile apps via HTML5 (

“Mobile is the primary focus for our platform this year,” [CTO Bret Taylor] said, noting that 200 million people are currently accessing Facebook on mobile devices. Not only is that group twice as active as their desktop counterparts, that user segment is growing faster than any other, he said.

That growth, combined with what Taylor called the “inherent engineering challenge” of mobile today, represents a major headache for him and the tech team he leads at Facebook.

Namely, whenever they update a feature on the site, they have to do seven versions, so it can run on the iPhone, Android and other platforms now in use.

“HTML5 is the future platform,” he said. “That’s where we’re putting a huge amount of our resources.”

By developing for the browser, they don’t have to create separate versions for iOS, Android, Symbian, Blackberry, etc.

My friend said: But the user experience is unpleasant where you have to bookmark a link and save it to the desktop (so that it will look like a “normal” app). And he noted that since connectivity is so spotty in North America (and, I would add, in certain buildings and on the subway, etc.), web delivery is problematic. Finally, he said: “Yes, it takes more work to make an app, and to maintain it. But wouldn’t you rather have more usage?”

To which I said:

I think most of your points have solid rebuttals. I should probably go through them, because I have been asked by a number of developers and entrepreneurs whether they should be developing native or HTML5 apps . . .

  1. Delivering an app — any app — on these mobile devices already requires connectivity. So whether it’s the app store or via HTTP, you still need a connection. Indeed, the Apple App Store requires a wifi connection (same for Android? I can’t remember; I sure hope not). You can’t install or update an app on iOS via 3G. A web-based app can be delivered by 3G or wifi. So I think connectivity as a differentiator for delivery per se is a red herring.
  2. The whole “bookmark to desktop” mechanism is something that could be overcome (by Apple). It’s a detail that is probably there just to make the experience harder so developers and consumers will favor the app store which makes Apple more money. Plus, if Facebook goes HTML5, that may teach everyone how to do it anyway. Meanwhile, my experience with the Apple App Store has been that it’s buggy and peculiar. Just today I was asked to sign off on the latest licensing/terms and it was a bizarre back-asswards experience.
  3. You can cache an HTML5 app so that successive runs don’t require the network to start up. I don’t do it (yet) for a product I’m working on for a lot of reasons. HTML5 provides for on-board databases, etc., so access to the network while running can be mitigated (i.e., data can be downloaded for later offline use). There are HTML5 apps that people think are native apps — the best are probably the ones Google has created.
  4. What are these apps we’re using that don’t require connectivity? I was looking over my apps and I could find only one that doesn’t require connectivity while it is running (a game). It could probably be implemented in HTML5. I know this particular company has a web-based version of the game already; I’m sure they did it as an app so as to sell it through the app store and make some money that way.
  5. I was just using the new much-ballyhooed “Daily” app, and was shocked at how terrible its performance is. Why? Because it tries to use a lot of UI gewgaws that it would probably skip were it delivered in HTML5. It’s appalling. It has a rotating kiosk for news that is just plain slow and jumpy. Another really interesting user experience case is the iPad NY Times app. Have you used it? There isn’t as much news as the web site! I was kind of shocked. It’s somewhat “curated,” which is a weird approach to take for the paper of record. Why? I wish I knew.

    Just speaking for myself, the browser experience of the NY Times on the iPad is much better than the app. And the Times has browser-based apps that are awesome (example: — not sure why the Times hasn’t flogged this more), but don’t yet work very well on the iPad. If they did . . .

    A really interesting case is the New Yorker. This is currently being delivered whereby each separate issue comes down as a separate app. I would bet that the motivation is connectivity (besides greed — each issue is $5), so the whole content of each issue is downloaded. But no one’s buying it, either economically or conceptually.

  6. If I can get more usage by writing one app that can be delivered to Apple, Android, Blackberry, Symbian, etc., etc., don’t I get more users that way?
  7. Then there’s the question of getting access to the “bare metal” for speed or services. Android apps are written in Java, so you don’t get that anyway (well, it’s awesome, but it’s still not right down there at the metal). There are apps on the Apple mobile infrastructure that are hard to imagine without being written in Objective C, so I’ll grant that there’s a class of applications that would be hard to do in HTML5.
  8. What am I missing? I think mainly, and obviously, the economic model of the app store. It’s great to sell your product via Apple or Android’s marketplace. But if your app is free, as is Facebook’s, I’m just not seeing it. Games, audio and video apps: These I can see the need for native delivery and the money mechanism of the app store. Indeed, the top-downloaded and top-grossing paid apps on the app store are all games or audio:


    But for business-oriented apps . . . I’m just not seeing much of a downside to HTML5.


  • Jeff Bacon

    While I don’t disagree with all of your points on the benefits HTML5, you have few factual errors in your arguments or HTML5:

    1. “You can’t install or update an app on iOS via 3G.” — that’s not true. There’s a limit to the size of the app you can update/install over 3G but if you are hitting that limit, your app is probably not a good candidate for HTML5 anyway as the amount of data you are needing to transmit to run the app must be pretty huge (e.g. a game).

    2. “The whole ‘bookmark to desktop’ mechanism is something that could be overcome (by Apple). It’s a detail that is probably there just to make the experience harder so developers and consumers will favor the app store which makes Apple more money.” — right, so what you’re saying is that you should ignore the “best practices” advocated by a platform and work against the path that the platform holder has set out for app development. Since it behooves Apple to give preferential treatment to naive apps, I don’t think you can dismiss this concern as a “Apple could fix it” since in reality it’s more likely Apple won’t fix it or will make it worse.

    6. BlackBerry didn’t support HTML5 until OS 6 (currently ~10% of the BlackBerry market), Symbian doesn’t support HTML5 (even the most recent ‘Anna’ browser sucks at it), “etc., etc.” don’t have good HTML5 support. So really you’re getting iOS, Android, a small slice of BlackBerry and maybe Windows Phone 7 — but not with one app. Even web apps need to accommodate differences in device input styles, screen sizes, capabilities, etc. In the 90′s and early 2000′s, just because you wrote a fancy website didn’t mean it worked in IE and Netscape — the same is true for mobile browsers when it comes to apps today.

    Anyway, and interesting article and definitely gets you thinking but if you’re only going to advocate for one side of the debate, better get all the details right =). I wrote about this on my blog as well:

  • Ben Marshall

    I just wanted to respond to one of Jeff’s comments: HTML 5, while not fully supported on all browsers, will be eventually. Chrome, Firefox and Safari have very good HTML5 support. Microsoft will get there eventually, too. As for differences in screen sizes, capabilities, etc. – Yes, there will be differences. But that’s why we use CSS to deliver the presentation layer. It is simple to modify an app (or site) to accommodate these differences. As far as capabilities, most mobile devices will have a large set of capabilities that are common (e.g., GPS, camera, etc.) and they will have an open API for making use of them. Eventually, HTML5 will incorporate a layer to handle working with differences in hardware.

    The basic premise of “write one app that can be used across all devices” may be slightly exaggerated, but the efficiency of writing a web app rather than seven native apps can’t be argued away. For any software shop working on non-gaming apps (e.g., enterprise apps, media consumption apps, etc.) to ignore HTML5 will spell doom. The competition will eat your lunch, especially with the new Javascript engines in modern mobile browsers on the latest 4G phones. The future is VERY bright for web apps.

  • john

    Ben – With the HTML5 app I mentioned in the post, I’m currently targeting the iPod Touch, the iPad, and a bunch of Android tablets, and, as you say, I just switch the CSS. I had to dumb down the JavaScript a bit for Android, but otherwise it works. Looking back on the process, the most interesting thing has been the shoddiness of the Android tablets (very generally, across many dimensions). I have 4 sitting on the floor by my desk, gathering dust.

  • Jeff Bacon


    I don’t disagree that there is a bright future for HTML5 for many applications (especially those that don’t need real-time response rates like games) but for now it’s the “future” part that is the problem. It takes a long time for older mobile devices to flow out of the ecosystems so even if all smartphones sold starting in Fall 2011 supported HTML5 very well in the browser, there’s still hundreds of millions of smartphones in the market that will not — not all devices get the newest OS upgrades. And by “a while” I’m talking at least a year. That means 18-24 months from now before HTML5 is well supported, and performs well (even the iPhone chokes on a a lot of HTML5 apps right now) across the majority of smartphones. 2 years is an eternity in the mobile space and it’s not prudent to ignore the current devices and users and only look to the future.

    Also, since HTML5 is really only well supported across iOS and Android right now, it’s not “seven native apps” that one HTML5 app is replacing, it’s 2 (or 4 if you want to say iPhone, iPad, Android 2.x and Android 3.x — though you can write apps that work on iPhone+iPad and Android 2.x+3.x). For a LOT of apps, the HTML5 experience is much worse than naive apps — right now — so the actual current benefits of doing HTML5 are not that strong right now for anything other than fairly simple apps or enhanced website interfaces (which I support HTML5 for by the way).

  • john

    Jeff, It might be worth it to talk about specific applications, platforms, and markets.

    E.g., Facebook. Do you consider it to be a “fairly simple app” or an “enhanced website interface,” and therefore suitable for HTML5 on those grounds?

    What about the NetFlix iPad app (which is apparently HTML5 wrapped by PhoneGap or something like that — that it is HTML5 was news to me until I read the developer’s slides about implementation)?

    I.e., I’m trying to understand the tipping point for native when you’re looking at a non-game application. You say “fairly simple.” But once I’m using a platform that can deliver to multiple native apps, aren’t I think giving up complexity to support the lowest common denominator?

    Another model would be: Support iOS and Android first with HTML5. If there’s some success, then pay someone else to do the native app that supports the other mobile devices.

  • Pingback: What have been the main technological advances of 2011? - Quora

Previous post:

Next post: