Web Apps on the iPhone

in a long forgotten past, the iPhone did not have apps. it had the apps it had (but nobody called those apps back in those days), and developers were supposed to write web apps. which did not work too well, on the one hand because the browser did not (and still does not) reasonably support basic web principles such as caching, and on the other hand because there was no flash and some web developers claimed that a web without flash was too primitive for their advanced menu animation needs. not too long after the initial launch, apple opened the iPhone for native apps and with that launched the app craze that still impacts the mobile landscape and the mobile web.

the following could be regarded as having a little bit of a conspiracy theory vibe, but that's ok, sometimes it's good to be a little bit paranoid... apps are mostly successful in one of three ways:

• games with their advanced graphics and interactions just don't work too well in a browser. only native apps can utilize the underlying platform well enough to deliver a good user experience.
• selling applications is something that the app model with its centralized store makes very easy, which is the reason why we saw the rise of the 99¢ app and apple reeling in additional dollars. smaller and independent software makers now have a platform they can sell on (for a hefty 30% fee).
• branding and findability for companies that now often just want to have an app, because other companies have apps, too. many of these apps are little more than some combination of dedicated feed readers and bookmarks to a company's mobile site, but just having an app is a statement in itself.

while games are special in this case (there are technical reasons why native apps work much better), a lot of the apps in the app store are there for the latter two reasons, and in many cases might as well have been implemented as web apps. but that doesn't seem to be a feature anybody is using, amazingly. the iPhone can locally store web apps and supports local data storage for these apps (both of these capabilities are based on HTML5 APIs), so why don't more developers just develop web apps, instead of going through the much more elaborate process of coding in objective-c, submitting the app to apple, and having to resubmit every update of the application?

part of the reason may be that mobile safari is not such a great browser. web apps critically depend on the back button, and mobile safari's laughable caching limitations mean that virtually nothing is ever cached, which means that navigation becomes a painful process where everything has to be reloaded for each navigational step. it would be almost trivial to improve the mobile safari user experience dramatically by setting aside let's say 500mb of the internal storage as disk cache. i think there are two main (and simple) changes that would make web apps on an iPhone much more attractive:

• caching support has to become much better so that caching works as well as it's supposed to work on the web. bandwidth is crucial for mobile scenarios, and breaking caching in the way mobile safari does it makes web apps behaving much more sluggish than necessary.
• fullscreen support should make sure that web apps can deliver the look and feel of native apps. F11 has become a very important shortcut on the desktop, and mobile browsers with their more constrained screen real estate should include simple ways for hiding the browser chrome. i am sure apple could figure out some good UI for this; one possibility would be to display the chrome while the page is loading, then zoom in to fullscreen mode, and allow users to zoom out (using pinching) to the regular view.

with those two simple changes, web apps on the iPhone could easily rival many of the apps in the app store today, and they would be usable across different platforms. of course, they would not be apps in the we can sell it and the we also have an app kind of way, but they would be much cheaper to develop and much easier to deploy and update.

the conspiracy theory in all of this is that apple has to make sure that there is a safe distance in user experience between native apps and web apps. if web apps suddenly work as smoothly as native apps, that might let more developers write web apps instead of web apps. it's not so much the loss of revenue for the app store, but the loss of lock-in for the apps that make this option undesirable from apple's point of view. web apps can be reused on any platform supporting HTML5, most notably android. which means that it is not in the interest of apple to drive developers to web apps, and as long as the user experience is less predictable (and probably worse than for native apps), many developers will prefer the more predictable native app.

since the whole apps craze started, web apps on mobile platforms have not received a lot of attention, and part of the reason for that is that the HTML5 model of how to support offline web apps is not all that great, and how it's then implemented is even less great on the current HTML5 platforms. this issue will be covered in a future post, coming soon!

Comments

[Justin Cormack]

You can have fullscreen web apps that look just like native apps. And there is fairly good offline support. One example is Pie Guy http://mrgan.tumblr.com/post/257187093/pie-guy which behaves just like an app including doing upgrades when online and so on.

They haven't caught on though....

[dret]

RTFM, i guess. thanks, justin, i wasn't aware of this (i thought all you can do is to hide the address bar), and http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html is the reference info for this. however, this seems to put the fullscreen mode entirely under the control of the page author and only works if the page author adds this proprietary apple code. i was more thinking of a fullscreen mode controlled and initiated by the browser, either on behalf of the user (like F11 on my computer), or implicitly through some context clues, such as when launching a page from a springboard bookmark.

[Dominique Guinard]

Nice post! Actually I'm totally with you, a ecosystem of mobile web apps would make a lot more sense.
One "patch" solution I quite like is http://www.phonegap.com which basically offers to embed a Webserver in an native app. This way you can develop your app using Web languages and tools (such as http://www.jqtouch.com/) and package it with the embedded Web server.
Of course it does not solve all the issues you mention (e.g. the approval process) but at least it lets people using the Web tools and languages they know and like...

[dret]

@dom, that's not my understanding of phonegap. it is my understanding that phonegap "bridges the gap" between HTML's limited access to device capabilities and the richer set of features available to native apps by providing an environment where you can use more APIs than provided in today's smartphone browsers. they do this by combining webkit and custom code that exposes additional platform features to scripts running in this ebkit environment. the side-effect of this approach is that you have to package your code with this enhanced webkit runtime and then deploy this package as an app. alternatively, you could imagine running phonegap just as an enhanced general-purpose browser with additional APIs, but that would violate the rule that app store apps are not allowed to dynamically load executable code. it seems that some phonegap apps that have been approved do load code from the web instead of having everything packaged into the installed app, but when submitting such an app, you never know whether apple is going to accept or reject it.