The Flip Side of the Multitasking Argument

Friday, 14 March 2008

Hank Williams argues the other side of the iPhone multitasking debate in a piece titled “Apple’s iPhone SDK Prohibits Real Mobile Innovation”. It’s the best argument I’ve seen against Apple’s “no third-party background processes” policy. Williams writes:

Prohibiting background processing is not just a question of one feature being left off a long list of otherwise very well executed features. The issue of background processing is the issue for a mobile device because it is key to two things:

• telling the world about your status in some ongoing way
• receiving notification of important events

These two things are the key to most new real innovations in the mobile space. To be clear, by innovation, I mean creating functionalities that have not been possible before.

I don’t disagree with Williams at all on this point. There’s no doubt that some very cool ideas would require background-capable iPhone apps. That’s the trade-off, though: Apple hasn’t designed the current SDK limitations to maximize potential coolness; they’ve designed it to maximize battery life and performance system-wide.

Williams does have a good point regarding AOL’s demo of a native iPhone AIM client during the SDK introductory event: an IM client is exactly the sort of app that’s potentially a lot more useful if it continues to keep you logged in even when the app isn’t frontmost. It’s unclear, though, whether Apple has granted AOL special dispensation from the standard no-background-processing rules, or whether the AIM client AOL is working on will indeed only work when it’s the frontmost app.

Williams closes with this remark regarding Google’s Android:

My company has been developing an application for Google’s Android phone operating system for the last several months. Our application would not be easily possible on any platform other than Android. In fact, important parts of the application are impossible without background processing. In short, Apple may be visually sexier, but I can actually innovate more effectively on Android.

This brings to mind Jeremy Horwitz’s story in iLounge a few weeks ago, which contained a strongly-worded complaint from an iPod peripheral developer arguing that the iPhone SDK was effectively no better than writing web apps because it offers no access to the dock connector port. Regarding this complaint, I wrote:

If what you really want to do is write iPhone software to provide an interface to a hardware peripheral, yes, a complete lack of access to the dock connector port puts the native SDK in the same boat as writing a web app: the S.S. Useless. But for pure-software developers, there are a ton of potential advantages to a native SDK.

The same applies here with Williams’s complaint regarding background processing. If the app you really want to write requires it, then yes, the current SDK is disappointing. But that doesn’t mean there aren’t plenty of other ideas that will work just fine.

As I wrote this morning, I don’t think the “no background” policy implies any spite or shortsightedness on Apple’s part. It’s simply the result of Apple’s decision to focus first and foremost on maximizing battery life and performance. Other mobile platforms, such as Android, may well have different priorities.