Monthly Archives: December 2012

How do we get to mobile web applications?

Posted by Mike Brittain on December 20, 2012
Mobile / Comments Off on How do we get to mobile web applications?

Anyone who has had a conversation with me for more that 3 minutes about mobile knows that I’ve been a big proponent for the mobile web for years. I believe that mobile web apps have been held back by the proliferation of native app marketplaces, which are highly attractive to developers due to:

– Solid SDKs, some standardized UI components
– Better UI performance, for now
– Marketplaces with integrated payment systems
– Ease of discovery, installation
– Heavy advertising and promotion by carriers and OS creators

After reading Fred Wilson’s post, The Mobile Web, yesterday I finally wrote up a response in the comments. And since it’s surely lost amongst 285+ responses, I’m reposting it here. For context, be sure to read the post.

I’ll preface this response, however, by mentioning that these are pretty big hurdles and it’s going to be a while before we get to the place where the decision to build a mobile web app over a native app is obvious and accepted. There’s technical progress being made, but there is still a vicious consumer awareness and advertising cycle built to prop up the native app marketplaces. That will take more time to unwind.

* Developer Tools and Frameworks. There are a lot of individual pieces, but no single, obvious, and popular framework for building what feels more like an “app” rather than a collection of pages on the web (an earlier comment use the term “card”). We’re competing against the very obvious native SDKs. It *is* possible to write “installable,” offline web applications for mobile browsers, but you still have to cobble together much of the application framework yourself — it’s not yet a well-understood pattern. The HTML5 app cache is not the most wonderful thing to work with, either.

Latency is brought up as an advantage of native over web, I think that’s a fallacy. The tools are just not here to help manage the perception of speed for users. An API call from a native app over HTTP is the same thing as requesting an HTML page — only the page refresh and (re-)loading of resources gives the perception that “the web” is a slow medium.

* Payments. Less a matter of payment at time of download (e.g. App Store) than it is having a single, trusted digital wallet that you can pay from. Tapping out a 16-digit card number, name, expiry, etc. on a handset is a huge barrier.

Try-before-you-buy would be far better to consumers than the proliferation of $0.99 and $1.99 apps that are so cheap that it doesn’t matter if you’ve wasted your money on junk a few times.

* Improved Platform (i.e. Browsers). You can argue that the browser is at a disadvantage from native apps because it is an abstraction from the OS. This is hampered further by lower CPU, memory, battery power — all of which will continue to improve over time. But while SDKs and native apps continue to rule and have an obvious, and working, payment model the innovation in mobile browsers will be slower.

Browsers will need API parity with native SDKs — i.e. access to cameras, audio, location, file storage, wallets/NFC, preferences, notifications, running in background, network detection, etc.. I would expect you’ll see more innovation here within Chrome OS than on the more mainstream mobile OSes.

* Discovery. There’s not a one-stop-shop for native and web apps. The Chrome Web Store is actually decent and provides ties to in-app payments via Google Wallet. Same with Mozilla’s new store, though I’m unaware of any payment service there.

Consumers have been well conditioned by handset makers and carriers that they will get their apps from the major native app stores. We have yet to see marketing like that for mobile web apps. And most consumers will use what is put right in front of them, and what they’re hearing in commercials.