Phone Apps as the Badge of FAIL

I'll give you an easy out: you can write off this rant as a case of iPhone envy. You can do that, but you'll be wrong.

Phone apps are, for the most part, a bad idea. Once upon a time, a long time ago, online services lived in little walled gardens, with names such as Compuserve and AOL. Then it was discovered that open, common standards, namely the Internet and the Web, were far superior. The walls crumbled and openness prevailed.

Phone apps are an attempt to recreate the walled garden. That's bad and wrong. When developing for a phone, a platform specific app should be the last choice. The first choice should be a standard web application, optimized for mobile use (which means smaller screen and limited input capability).

There are four reasons to develop a phone app instead of a mobile web app. Two of them are good. Two of them are bad -- but are the predominant reason why phone apps proliferate.

Good reason number one is that your app needs to use some proprietary API on the device, such as access to GPS information. There is no open standard for this. There should be a standard for this, but it would be tricky. You wouldn't want to provide device information, such as your current location, to any web site that wants it. Until that happens, I'll prefer to access sites such as through a platform-specific app.

Good reason number two is that your application does not need access to cloud-based data or services, and should operate even when a data connection is not available. There are very few applications that fit into this category. Media readers and games are examples. Unfortunately, a lot of stupid apps do things that should be done on the web, such read a newspaper or get sports scores.

Bad reason number one is because the browser experience is inferior to an app. This is the primary complaint I hear from iPhone users. If that's the case, then people should be leaning on their phone manufacturer to improve the browser, not reward them by buying proprietary apps. There are things that can be done to improve the mobile browsing experience. The Palm Pre, for instance, will zoom on a control such as a select widget, to make it easier to manipulate.

Bad reason number two is because the locked-in proprietary development platform provides a revenue model. This might be the most compelling reason why apps are so popular. Phone manufacturers can take a cut of app store sales, but not web service subscriptions. So they have every reason to make their web browser inferior (c.f. bad reason number one), and direct people to paid apps.

In many cases, a well designed mobile site will work as well as a mobile app. For instance, the New York Times, Best Buy and Amazon all have highly usable mobile sites.

As far as web applications, I use Ziplist and Remember the Milk through their mobile web interfaces. Their mobile web interfaces are not as good as I'd like, but that's because of the lack of attention, not technical deficiency. The RTM site, for instance, would be completely usable if not for its botched style sheet. The limitations of these sites illustrate why proprietary phone apps are bad for the world. With all the hype and focus on platform apps, mobile web design is getting short shrift.

The future will reward those who design for open mobile platform, and penalize those who develop proprietary apps. If you develop iPhone apps, you may be developing for a declining market share, thanks to the increasing popularity of other smart phone platforms. If you develop for open mobile platforms, your apps can be used on every platform, from Blackberry to Droid.


Comments have been closed for this entry.


I disagree. I also wonder why you are singling out smartphones for the "everything should live in the browser" argument and not desktop computers.

This argument seems predicated on the idea that smartphone apps are fairly simple data-driven apps. Even leaving games out of the picture entirely, this is not true.

Inferior browser experience is actually a good reason. Despite all the work being done on Javascript interpreters, JS simply isn't going to be anywhere near as fast as compiled code. There is a stark contrast between using the iPhones built-in Maps app vs using Google Maps on the iPhone: the former is snappy. The latter is slow to the point of being useless. This may not be an issue on the Pre that I know you use, because everything is implemented in JS, but it is on the iPhone. Also, as far as I can tell, there would be no way for a web app to trap multitouch gestures. And there's no built-in way to deal with single-touch swipes, accelerometer inputs, and other gestures. PPK wrote about this issue recently (1, 2), but he seems to be coming at it from the perspective of someone who is already using the browser of the future. Gruber has been writing lately about this issue, and in particular has been nosing around in Apple's own JS framework for the iPhone, PastryKit.

Having everything live in the cloud puts you at the mercy of both your cellular carrier and the cloud servers, so that's two potential points of failure every time you want to look up a friend's phone number. Admittedly, with HTML5, it is possible to locally cache all that data (and indeed, the whole web app), but you've still got the performance issue.

One relatively popular category of app comes immediately to mind that would be wholly unsuitable for web-appification is media manipulation. There are photo editors, sound editors, and even video editors on the iPhone. The volumes of data involved are simply not practical to run over 3G.

Let's look at the filthy lucre side. There are three ways a publisher can monetize an app, whether running locally or on the web: upfront payment, ongoing subscription, or advertising. Those little Admob ads on phone-optimized websites and in some apps bother me disproportionately, so I don't mind spending a buck here or there to avoid it. Web publishers have had a hard time getting people to buy subscriptions for content, and applying that model to webapps could be just as hard.

I just looked through the apps I've got installed on my phone. I've got a total of 50, including one game and the browser itself. Giving maximum benefit of the doubt to the web app side, I think that maybe 25 could be implemented reasonably effectively as web apps, although I still don't think they could be as good.