iPhone SDK: UIKit vs WebKit

Earlier, I wrote that I don’t have much comment on Gruber’s post on iPhone web apps. It turns out I was wrong.

It took me a while, but I realized after making that post that I needed to reconsider what I was doing for iPhone development ((Like Gruber, I’m just going to use iPhone as the generic term for iPhone or iPod touch.)). See, I have an application in mind for the iPhone. I originally planned to develop it for the web, but I need to reconsider that.

There’s a bunch of advantages to sticking with the web SDK:

  • Centralized data authority. Users will never need to worry about whether their desktop computer or their iPhone has the latest version of their data.
  • No data management for users:They never need to worry about backups, because I can backup everything automatically.
  • Fully cross-platform ((In the sense of the software being able to run on all modern web browsers, I mean.)): All other things being equal, a bigger market is better, right? Sure, I’d want to do some customization for the “desktop version” later, to take advantage of the larger screen, but it wouldn’t be a rewrite by any means.
  • SDK available today: A chicken in the hand is worth at least a dozen unknown birds squawking in a tree.
  • Automatic updates for all! Hooray! This is especially relevant to me, because I can see tweaking some of the algorithms behind the scenes for many years.

For my application, I can see these advantages to a UIKit SDK application:

  • Better performance: web page downloads over AT&T are going to take a while regardless of what else I do.
  • Richer interface: despite WebKit being pretty darned capable ((See PopCap’s Bejeweled, for instance.)), I probably wouldn’t be able to do some of the more complicated animations or graphical manipulation that I wanted to do.
  • Offline use: except some of the things I want to do would likely require a connection anyway ((This raises the question of what exactly the iPhone SDK can and can not do. Will it have full network connectivity?)).
  • More interaction methods: This is the only one that really bothers me. Being able to flick between pages and respond to rotates easily is important for an iPhone application. I hope Apple has something up their sleeve on this front.

How does it all stack up? I think I’ll be doing the development using the web. Nothing’s really changed, but now I’ve thought it through and feel comfortable with the choice.

Given that decision, I’m done. If I decided on UIKit, I’d now be wrestling with whether to unlock my iPod touch ((I’m not really breaking my rule here. My device is, specifically, an iPod touch.)) and start looking into third party documentation on the SDK to get an early start. I’m not sure this would really be a head start, as there’s probably quite a few others who will decide (or have already decided) to take this route.

This entry was posted in Technology and tagged , , . Bookmark the permalink.

Comments are closed.