Mobile Web Apps will Beat Native Apps

Since upgrading my iPhone to the 2.0 software, I’ve dived into Apple’s app store and I’ve been making a point of trying out apps from across the store but focusing on content creation tools (such as the excellent WordPress app which I’m using to write this post). At the same time, I’ve continued to make use of all the great iphone webapps and mobile Web sites I’ve come to know and love. Increasingly, across many platforms (not just iPhone) application developers and content providers will  face this choice: to build a webapp or to build a native app. There are advantages to both approaches, and some work that’s just getting started that I believe will significantly change the face of mobile development over the next 2 years.

The rush of content and application developers to develop iPhone apps has been impressive and somewhat predictable. The app store is the next big thing. Google, Microsoft and others are now jumping on the bandwagon (probably much to the dismay of the folks at Handango who can rightly claim they’ve been doing an app store since before app stores were cool). Many of the apps in the Apple app store are really good and could not (currently) be written as web apps because they either take advantage of device capabilities (such a location) or because they need direct access to graphics or sound capabilities (3D gaming) not available to the browser engine. However – discounting this need to access the platform functions, there’s nothing about, say, the iPhone Facebook App that couldn’t be written as a webapp. Indeed, if you visit, you get a webapp version that gives you more features, has better usability (in my opinion) and benefits from more frequent updates (but does not, for instance, give you access to the camera so you can automatically take pictures and upload them to your profile, because the browser doesn’t have access to the camera API). Hahlo is another good example of a Webapp that currently beats out all the native application options as a Twitter client (except for its lack of access to the address book, camera, or location). This is the crux: it’s easier to build, update and maintain a webapp than an app (for cases such as the Facebook offering) but native apps give you access to platform features (and other capabilities such as local storage) that webapps can’t.

Enter a new class of webapp: a mobile browser based application. These applications are built using Web technologies (the so-called Ajax platform), can either be deployed as a standard Web application or as a “widget,” and can advantage of platform functions through some ingenous software layers currently being built. Google’s Gears Mobile, Nokia’s Web Runtime platform and upcoming versions of Opera Mobile all are making a start of it, but right now these efforts are all highly fragmented and incompatible. The OMTP, through its BONDI initiative, is attempging to bring some focus to this area, by coming up with a common set of industry requirements for enabling secure access to platform APIs and then driving some work forward in W3C’s Web Applications working group to help to make this an industry standard.

I was interested to read that in all the discussion of the iPhone app store, Apple has also quietly made it easier to write webapps and to surface these webapps to the user as if they were native apps. Essentially, the “web clipping” mechanism allows you to put an icon on your screen to represent a webapp, and with the release of the latest firmware, it is now possible to launch these webapps without the normally associated “browser chrome” (which mirrors the approach Apple has taken with it’s latest beta of Safari on desktop). This approach further blurs the lines between webapp and native app.

In the short term, it means more confusing choices for application developers. But in the long term, at least for an increasingly large class of application (for example, social applications or any app that doesn’t require direct access to platform features like 3D accelerated graphics), it’s clear that the Web will prevail.

Liked this post? Follow this blog to get more. 

10 Comments on “Mobile Web Apps will Beat Native Apps

  1. great post – 90% of mobile apps can be done on the mobile web – solves 90% of fragmentation problems and much cheaper. As you say there is a role for applications if you need specific functionality (qik could never work as a mobile web app) but developers should be focusing on mobile web. All the players that have been doing mobile for a while like flirtomatic, mippin have all come to this conclusion.

  2. I’m kinda undecided on this one.

    Can 90% of mobile apps really be done on the mobile web? 90% of the things you currently do on the fixed web can be moved down to mobile, and certainly James is right that it’s cheaper to build, modify and iterate mobile web sites than it is to do the same for applications (most of the time).

    But applications bring two things, I think: UI possibilities that go beyond the browser metaphor, and integration with the underlying capabilities of the device. Without the latter, the mobile web is stuck being a more limited fixed-web experience, differentiating itself by giving quick access to the most useful online content.

    I find it possible to believe that such a mobile web delivers massive value, even whilst holding the view that if you cut out location, camera, mobile sensors, NFC, identity, etc., you’re cutting out many of the things that make mobile unique.

    To use an analogy: delivering PDFs of an existing brochure over the web is a cheaper means of taking your brochure online than building a full e-commerce site with user reviews, ratings, etc. – but I wouldn’t say that this means it’s the right way to go.

    The point I’m making here weakens when (and, let’s face it, if) the BONDI effort and projects like PhoneGap see the light of day, of course. But even looking at some of the best networked desktop apps I use (/me shuffles slightly, looks at the floor, mumbles “iTunes store”)… there’s a mix of web and application in there which seems to offer more than yer straight web site does, and has me wondering whether mobile web alone is going to be enough.

    I still feel that it’s premature for us to state that we know what the mass market of mobile apps/sites/whatever will *be*. In the same way that the web didn’t (for me) really find its feet as a unique medium until blogging and all that social gubbins arrived, I think we’re yet to understand what mobile will really be about.

  3. It’s great to have OMTP participate in the W3C standardization process of widgets. The W3C’s Web Apps working group has been actively working on exactly this vision of Widgets for over two years. In fact, we’ve published seven drafts of the Widgets 1.0: Requirements, which attempt to capture precisely what needs to be standardized to make mobile browser based applications happen. We are also actively working on six specifications that together standardize widgets. We hope to have some of the specs at Last Call (technically complete) by the end of 2008.

  4. I agree. It’s been fascinating to watch the evolution of both the native versus webapp applications on the iPhone platform, and you can take that (I think) as a bellwether for what will happen elsewhere.

    As you say – the lines are blurring between native and web apps on that platform, and in many cases – the preference – both from a user *and* developer perspective may tip towwards webapp. *Especially* if I can get at the camera, the GPS, the Bluetooth and more from inside the browser, then why would I bother with native, apart maybe from certain game types or very, specialised applications?

    I’ve come round from being skeptical regarding the potential “reach” of webapps, to being a convert, and watching the iPhone is partly what took me there. As BONDI and other initiatives get there, I think we’ll see the same happen on the greater swathe of mobile phones, and it’ll be a “Good Thing”.

    Great post.

    Cheers, Sean

  5. Yeah, software development is now addicted to instant deployment. And once caching and other app-like features are available to webapps, there will be few reasons to be a native app.

    But it will be sad if these little computers in our pockets can’t also be servers, if they end up being nothing more than fancy green screens.

  6. I agree with the post and I´m wondering how is the bONDI initiative doing nowadays, since this was posted almost 5 months ago…. I would be really interested in testing it…

  7. Dan – old post, but still very relevant – popping up with Apple, Google & a host of other pubs and blogs. This one is near & dear to my hear, as our software is based upon this very premise – making it easy for companies to extend their Web services to mobile users.

    The problem is that the Web doesn’t know “me”. If the Web server/Web apps can know who the user is, what device they are on, and the user’s location, then delivering appropriate content to the user is simplified and increases the chance for a positive mobile user experience. The key is getting all that info without the user having to constantly type it in on the tiny mobile keyboards.

    Providing menu-based navigation (but in the browser) would free up the mobile screen for that more relevant content. Addressing this problem across platforms and respecting the W3C’s standards is the final piece to making it all work.

    If you are interested in learning more about this approach or want to try a free Web app developers version (that requires no mobile development) you can check us out at We’d love to hear your feedback.

  8. Why choose between native and web apps when you can easily have both? is a service that gives web apps a way to be sold in App Stores. It takes all the benefits of web apps (especially multi-platform) and adds many of the benefits of native apps (can be sold in App Stores, etc). All we need is the URL of the web app and we can put it in the iPhone App Store, Android Market, Palm Catalog (when it opens to general 3rd party apps) and desktop apps on Mac, Windows and Linux.

    Prices start at $149.

    Mobile web app authors maintain their own code and hosting – while being able to update their application without resubmitting the app to each store.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.