The iPhone and Web Apps

Friday, 19 October 2007

There’s some speculation that Apple’s plan to release a native iPhone SDK is bad news, in some way, for the iPhone as a platform for web apps. I disagree. I see it as no more bad news for iPhone web app development than Cocoa is bad news for regular web app development.

The weird thing about web apps vs. desktop apps is that they don’t really compete head-to-head. Most good ideas for apps only make sense one way or the other. It doesn’t make sense to think of, say, Basecamp as a desktop app. Because web apps are currently the only sanctioned way to develop for the iPhone, yes, there are some iPhone web apps that will be obviated by native apps eventually. (Games and IM clients, for example.)

But even after the iPhone SDK ships, there will be far more iPhone web app developers than native UIKit developers. I see MobileSafari-optimized web development as the Visual Basic for the iPhone as a platform. Easier, more approachable, and wide open to everyone. An existing web application written using best practices — standards-based markup, separation of style from content — can be optimized for display on MobileSafari in relatively short order by any competent web developer. Not so with native iPhone app development.

Apple, someday, is going to be all over “web apps” as first-class citizens for its computing platforms. Perhaps not in the form of HTML/CSS/JavaScript alone, or not only in that form, but in some way, in the future, first-class Apple software will be run over the network rather than being installed on the device. If you think of “The Web” as HTML rendered in a browser, “web apps” might be the wrong word to describe what I’m talking about; “net apps”, perhaps, might be more apt.

Imagine, for example, an Apple-designed next-generation competitor to Flash and Microsoft’s Silverlight — an embedded runtime for net-based apps that “kills” Flash not by replacing it or becoming more ubiquitous (which at this point probably isn’t possible), but by out-classing it, by enabling Mac OS X- and iPhone-quality user experiences in apps that reside on a server, not the client. Or maybe just give WebKit and Moore’s Law a few more years, and it really will be just HTML/CSS/JavaScript.

Net-based apps — in concept — suit Apple perfectly: they’re more convenient for users and afford tremendous control to the developer. (Adobe CEO Bruce Chizen is thinking along similar lines.) So, someday, yes. But that day isn’t today. It was never Apple’s intention for MobileSafari web apps, here and now, to be as good as native iPhone UIKit apps. If it were, instead of basing the iPhone environment around a mobile port of Cocoa, they could have simply based the UI environment around only the mobile port of WebKit. It just isn’t possible, today, to provide what we now know as the iPhone experience using WebKit alone.

That’s why Mac developers were so irritated by Jobs’s description of MobileSafari web app development back at WWDC as a “sweet” iPhone SDK — if it were so sweet, then why wasn’t Apple using it for the iPhone’s built-in apps?

But it really is sweet, in its own way, in that the iPhone is clearly the best handheld web client in the world. Let the web be the web and let native apps do what native apps do best — the iPhone does both better than any competing platform.

Finally, a nomenclatural note: When writing about the native iPhone SDK and web apps written for MobileSafari, it’s both easier to write and read to just say “iPhone” where I really mean “iPhone and iPod Touch”. Apple does the same thing.

Long-term, I think the “iPod” brand has a stronger future than the “iPhone” brand. “iPhone”, to me, means mobile OS X on a device tied to a mobile phone carrier network. At some point in the future when ubiquitous long-range wireless IP networking is available, OS X-based iPods will be able to do everything iPhones can, with the same (or close enough) mobility and range. At that point the iPhone will just fade away — or at least slip beneath the iPod as the top-of-the-line Apple handheld.