In the wake of Apple's announcement last week of an iPhone software development kit (SDK), I wrote that the company had "hit a proverbial home run." (writing in Network World, Scott Bradner expressed approval also)But after discovering some details about the way third-party programs will run on the iPhone, it may be time to temper my opinions and say that Apple's made solid contact, but hasn't knocked it out of the park.
Take a look at Apple's iPhone Human Interface Guidelines (free account and login required to view). This document is the guide for iPhone programmers, letting them know how the iPhone works, what's expected of an iPhone program's user interface, and how to work with the various technologies in the SDK. On Daring Fireball last week, blogger John Gruber pointed out one fairly major limitation of the SDK: Only one iPhone application can be running at a time. (I asked Apple to clarify exactly how this "one at time" restriction would apply to applications that require background updating. As of now, I haven't received an answer.)
The iPhone is an amazing little always-connected Internet device... and yet if it can only run one third-party program, those apps won't be able to really take advantage of that always-there connectivity.
Remember that slick AIM demo during last week's presentation? Based on the interface guidelines, every single time you click out of AIM to do something else - check your calendar, send an email, look at Google Maps - AIM will stop running. Technically, you'll be logged off of AIM, and any messages sent your way won't arrive. Twitter and IRC clients would be similarly affected.
When you're using one of these programs, you don't want or need them to be frontmost all the time. When something happens that needs your attention - a new message arrives, an invitation to a chat requires an answer - you're informed by the application, and you can then bring it to the foreground. But if these programs quit when you switch out of them, they really lose their effectiveness. Imagine if the only time you could ever be logged into an instant-message service was if you sat there patiently, with your IM program open, waiting for someone to see you and chat with you.
Beyond these obvious targets, though, there are other programs - or program opportunities - that will be hurt by the inability to run in the background. Consider a professional stock-tracking application, one that updates every couple of minutes with the latest quotes, along with links to research, your broker, etc. Ideally, such a program would include an alerts feature, notifying you when a given stock exceeded a high or low price point that you had set for that stock. On the iPhone, such a program wouldn't be able to receive updates while running in the background, and hence, wouldn't be able to alert you when a tracked stock reaches its assigned target. What good are real-time stock quotes if you can't take real-time action?
Currently, some Apple programs on the iPhone can run in the background, popping up an alert or modifying their icons if action is required: the SMS program and Mail, to name two. And it appears that it's possible for third-party developers to make their iPhone programs run in the background, too - but only if they violate their development agreements with Apple.
Of course, one reason Apple may have chosen to prohibit this feature has to do with security and stability: if each program can only run when it's frontmost, then there's no way it can cause another program to crash, or do bad things like capture key presses from another program, or drain the battery in a very short period of time.
But whatever the reason, it's vital that Apple consider allowing developers to take advantage of this feature, at least on a case-by-case basis. If Apple doesn't want to allow everyone's programs to run in the background, perhaps developers could submit their background-savvy programs for extra approvals. Or perhaps Apple could open up additional features, including the ability for programs to run in the background, for developers who pay to become registered iPhone developers at some higher tier than the current US$99 barrier.
As we're still very early in the iPhone SDK beta process, it will take some time before we know if this is going to be a serious issue. Hopefully Apple can come up with some solution so that all third party applications aren't hobbled by the "one at a time" rule.