Maybe it’s brain surgery after all

Craig Hockenberry is a smart guy. He’s been around for a while, and has an impressive track record in the Mac software world. I don’t, but that’s not going to stop me from arguing with him about background apps on the iPhone. His argument has two parts.

Part 1 (here) essentially says that gackground apps will kill the battery life and usability of the iPhone by allowing application developers to willy-nilly make network connections, thus keeping the device radios on more than needed (or wanted).

Part 2 (here) says that even if we could magically solve the problems he describes in part 1, the user experience on the device would quickly get out of hand.

Why don’t I agree with part 1? I have experienced just the opposite with Windows Mobile. There’s a great deal of institutional knowledge around exactly these two problems in the Windows Mobile world. I get better battery life with my Treo 750 running Windows Mobile 6 than I do with my iPhone, despite the fact that the Treo has an HSDPA radio. This is despite the fact that I run a number of always-on apps on my Treo, including Communicator Mobile and Outlook Mobile with Direct Push enabled. If you take a look at the Direct Push protocol, you’ll see that it’s designed to keep a connection alive while still allowing the radio to go dormant when there’s not actually any information to transfer. The same thing is true of the UC AJAX protocol that Communicator Mobile uses. This is not a new idea, and Microsoft’s not the first to implement it. Craig’s argument– that ill-behaved or poorly written applications will kill your battery faster than Eliot Spitzer’s political career– is true. However, that’s not necessarily an argument in favor of blocking background applications. Let people ship background applications, then let the market decide which ones should survive based on their performance. (Note to Craig and others: remember, when we get that Exchange ActiveSync support we’ve all been jonesing for… it’s a persistent network connection!)

I give Craig’s arguments in part 2 a little more credence. The iPhone offers a lovely UI, as pleasant to look at and touch as any other well-designed, well-engineered artifact (whether a Glock, an engine block, or a summer frock.) It is a bit painful to think of having all sorts of buzzing, boinging, and screen flashing horning in on SJ’s Zen-like user experience. However, Apple has already solved this problem, at least in part: look at the way that the SMS, phone, and e-mail applications notify users of available data by using a number superimposed on the application icon. This paradigm works well for some sorts of applications. For others, the solution isn’t to ban applications from posting notifications– Craig rightly points out that several different notification-brokering APIs exist on the desktop Mac platform. So where’s the API for the iPhone? Where’s the mobile equivalent of Growl, or (better yet) a supported framework from Apple? That’s essentially what WM has, and it allows application developers to post notifications that the user can control. My Treo makes one distinct sound for a new SMS, one for a new e-mail (well, actually, two: for high-priority e-mails, Voice Command reads me the subject line), and one for a device or calendar alarm. Simple, powerful, and easy to customize. Given how good a job Apple has done with almost every other aspect of the iPhone UI, it sure seems like a problem they could solve if they wanted to.

I’m personally very disappointed by Apple’s decision not to allow background apps. I was planning on using UC AJAX to build an OCS client for the iPhone, but I probably won’t bother if there’s no way to background applications; a foreground-only IM client would be pretty worthless. I do have a few other projects in mind, though…