Mobile 2.0 – Apps vs. Browser Based Web Services

TweetsS60 App Tweete Mobile Web App

There is tremendous buzz currently around native apps and app stores thanks to the iPhone App phenomenon. This was especially noticeable  during a panel at Mobile 2.0 titled “Developers, Mobile Ecosystem Development & Third Party Services & Applications” The panelists, from Qualcomm, GetJar, O2, Sun and the Symbian Foundation, were all involved with their respective company’s App Store efforts.  While one can hardly blame players in the App store space for touting their vision, I  think it got a little over the top at times with several of panelists  categorically saying the web on mobiles, even the iPhone,  provides an lousy user experience compared to apps.  I heard similar statements from and number of other presenters and Mobile 2.0 attendees. There seems to be a tendency today to see apps as the future of mobile and to dismiss all browser based mobile services as second rate.

I have to respectably disagree.  There definitely are services that work better as installable apps. For example, mapping applications need low level access to the screen for performance reasons and  navigation and IM clients need to do real time notifications.  But other types of applications like RSS readers, social networking clients and services that publish news, sports and weather information can deliver a user experience in the browser that is as good or a better than that provided by an installable app.

One shouldn’t overlook the extra costs associated with apps for vendors and users. The web is cross platform, apps are specific to one of a dozen or more different mobile OSs and runtimes, making cross platform app development quite costly. It is much easier to achieve portability across all platforms and devices with the web.

Users have to go to the trouble of finding and installing a different app for every service they want to use.  There are limits on how many apps can be installed on any phone. Not just physical memory constraints that typically limit a user to a few hundred apps tops, but issues organizing large numbers of apps and the pain of reinstalling them on a new phone or after a hard reset.  The Web, on the other hand, is expansive and discovery spontaneous.  All the world’s information is a few  hyperlinks away.  There’s nothing to install and good search engines aid discoverability.

The web on mobiles is changing. It seems to be evolving much faster than application development. There are a couple of reasons for this.  For one, there’s a browser war going on between Apple, Google, Palm, Opera, Mozilla and others that is constantly raising the bar as to what mobile browsers can do. Here are a few examples from Mobile 2.0; Opera’s Roy Satterthwaite spoke of future mobile browsers as good as the best on the desktop.  In another presentation Ulf Poelke from Opera hinted that Opera Unite, their “web server within the browser” concept was coming to mobiles to enable bidirectional information sharing in web apps.  Mozilla’s Chris Blizzard mentioned that the forthcoming Fennec mobile browser is based on the same engine as Firefox 3.6 and called that engine much more powerful than WebKit which the iPhone uses.  The W3C’s Matt Womer described how HTML5 is bringing mobile Web apps access to local storage and phone meta data like location. The web on mobiles a year or two from now will offer a much richer experience than it does today.

Another driver of  mobile web capabilities is Web Widgets and Palm’s WebOS which blur the line between app and Web. I see Widgets as a transitional step.  Widgets are apps and suffer from the same discoverability issues and deployment friction as other apps.  The good news is that Widgets are driving the development of faster and more capable mobile browser and JavaScript engines. These new engines will make AJAX based mobile web apps better and faster as well.

Widgets need access to device meta data (location contacts, calendar, battery and signal level) and local storage. These are  being exposed to Widget runtimes through JavaScript.  In most cases browser based apps are currently blocked by platform security from this new JavaScript access to the device. These limitations will gradually disappear under pressure from web developers and companies like Google who stand to benefit from a more powerful and portable web development environment.  Anything that can be done in a Widget should also be possible in the browser without the need to deploy a widget to the handset

Apps and their cousins, Web Widgets, are all the rage now but within five years at the most, I expect standalone mobile applications will largely be replaced by browser based mobile services  just as is happening on the desktop today.

6 thoughts on “Mobile 2.0 – Apps vs. Browser Based Web Services

  1. Pingback: Predicting Apps Evolution « Symbian Blog

  2. Pingback: Connected Advertising Blog » AdMob Mobile Handset usage report

  3. John,
    Thanks for the comment. I agree that mobile browsers still leave a lot to be desired. My point is that they are rapidly getting better and will continue to do so.

    The page reload issue in the Android browser is a known bug( ) that Google seems in no hurry to fix. Other mobile browsers don’t exhibit this behavior.

    Wep apps do need to be tweaked to support various mobile browsers but by coding to web standards and using a mobile JavaScript library with multi browser support makes it much more manageable than porting an app to dozens of mobile OSs and runtime environments

  4. Re:”…within five years at the most, I expect standalone mobile applications will largely be replaced by browser based mobile services just as is happening on the desktop today.”

    Spot on Dennis. I absolutely agree with you.

  5. The problem I have with browser based solutions, like Google Reader, is that on my G1 it has to reload every time I access it, blending out my read items each time I follow an embedded link to its original article. If I want to access Reader on my browser and switch to a different app I have to switch first to the browser, thereby often forcing an additional step which can hardly be afforded on a mobile device. I am not against mobile browsers, I just find that at they moment they are very slow and have a limited feature set. Inevitably, I don’t think customization can be avoided as the iPhone, the Pre and Android phones all have different features that need to be individually exploited.

Comments are closed.