Way back in the dark ages before the App Store, the only way to add functionality to an iPhone was through Safari. In iPhone OS update 1.1.3, Apple added webclips, an easy way to launch into a web app from the iPhone’s homepage. While these were not full-featured apps, it wasn’t a bad compromise. While they didn’t offer much in terms of integration [1. If you’re feeling nostalgic, go read Erica Sadun’s great look at how webclips were implemented under 1.1.3. Pretty cool.] with the rest of the OS, they did allow users to more easily pop in and out of websites designed specifically for iPhone use. Twitter clients abounded, as did to-do apps and news apps.
With the opening of the App Store, web apps for the iPhone were pushed to the back burner by developers. With an SDK, developers could create far richer, native applications that looked and acted like Apple-built programs. They could be paid for their work, all from a store built-in to every device. [2. Be sure to check out this great essay by Peter-Paul Koch about developers, web apps and the App Store.]
The web app was nearly forgotten.
If we fast forward to today, Android is a powerful rival to Apple’s iPhone. With numerous handsets on every major carrier, the number of people using Google’s mobile OS is growing. With more users, Android developers are struggling to create the apps people want to Android’s poor SDK and multiple hardware and skins. Without a doubt, the quality (and quantity) of Android apps is holding the platform back.
On the flip side of things, iOS developers who want to build an app for Android have to double their efforts.
Web apps seem like an obvious solution to this multi-platform problem. Eric Anderson at 37signals:
Lately, we’ve been exploring ways to offer web apps that perform like native apps on mobile devices. For this short sprint we targeted mobile WebKit browsers—especially the default browsers on iOS and Android—because of their widespread use and excellent support for HTML5 and CSS3.
However, 37signals has been running into issues rendering web apps across platforms which Anderson outlines in his post. But even with some differences in how different platforms render things within WebKit, these problems are not nearly as troubling as building separate, native applications. Design issues are much easier to overcome than interoperability issues.
Despite these issues, Anderson and 37signals are moving forward:
Despite opinions to the contrary, mobile web apps still feel like an excellent opportunity to offer native-like performance without having to specialize in a particular platform, or be subject to the whims of an overlord.
Browser-based mobile apps clearly have the potential to offer user experience that is on-par with native apps. Of course designing that kind of experience is going to require more than emerging mark-up and style techniques—it’s not going to be enough to just serve a mobile stylesheet for your app. Offering a native-worthy mobile experience requires you to rethink the UI of your app and deliver it within an environment where touch is the rule.
The main problem with web apps today is that they aren’t granted the same rights as native apps, including integration with calendar, contact and photo information. Web apps continue to be islands. Even with off-line data, they just aren’t the same as SDK-built apps. Until Apple, Google and other mobile OS makers resolve this issue, web apps will always be second-class citizens in this app-driven world.