As people delve into the details of Apple's iPhone SDK, a few interesting issues are emerging. One developer guideline that is generating some concern is from Apple's Human Interface Guidelines for iPhone:
Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits. Its important to make sure that users do not experience any negative effects because of this reality. In other words, users should not feel that leaving your iPhone application and returning to it later is any more difficult than switching among applications on a computer.
To be fair, for most applications, this would be preferred behavior. There is no reason for Super Monkey Ball (for example) to continue running in the background, using up CPU cycles and Memory. Instead, as Apple suggests, the current state should be saved and returned when the application is relaunched.
However, this has raised concerns about the feasibility of an application such as AOL's AIM client, which typically does run in the background to alert the user of incoming messages. Based on one comment, however, this only appears to be a design guideline and not an absolute technical limitation:
I'm a programmer and I just tried it [using the iPhone SDK] and you can keep your app running in the background in the normal way ApolloIM and iFob do it. I.e. overriding applicationSuspend.
Another possibility could involve individual applications launching smaller background-tasks (daemons) short of full applications, but the feasibility of this is unknown at this time.
What this brings us back to is Apple's SDK license limitations and their editorial discretion with the iTunes App Store. From Apple's license agreement, this multitasking workaround is forbidden:
Applications must comply with the Human Interface Guidelines and other Documentation provided by Apple.
Even Sun's plan to bring Java to the iPhone is not technically allowed, despite their claims:
An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.
This could also restrict announced plans for a PC emulator for the iPhone.
It's still too early to say how strictly Apple will enforce these restrictions when approving applications for the iTunes App Store. By serving as the sole distributor for iPhone applications, Apple understandably wants to restrict malicious applications, but whether these limitations begin to encroach upon genuinely useful applications remains a concern. Apple's iTunes App Store launches in June 2008 alongside the new iPhone 2.0 firmware.
