iPhone SDK Limitations: Multitasking, Java, Emulators
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.
Top Rated Comments
(View all)I feel it's always better to set high standards, and say "we'll make an exception for you", rather than set lower standards and deal with apps that toe the line even then.
I think, for a consumer device, that may be the best path. Yes, it IS constricting---but that applies for the tech savvy, which is a more limited market. If Apple's aim is to bring the power of the smartphone feature set to a wider audience, then the needs of the general consumer market will drive the development, not the needs of the more tech savvy.
Which is how Apple has ALWAYS been.
[ Read All Comments ]

Vonage has introduced yet another app to its growing mobile arsenal. The latest, called Vonage Mobile (not to be confused with another app called Vonage Mobile, introduced in 2009) adds a Skype-esque...
As Intuit's Quicken options for Mac users continue to falter in the wake of a stripped-down Quicken Essentials release and the company's ongoing efforts to make the more fully-functional...
Apple's vice president for iPhone and iPod engineering David Tupman has left the company, according to 9to5Mac. While not a member of the senior executive team, Tupman spent a decade at Apple...