iPhone SDK Limitation: Only One User-Made App Running Concurrently, No Background Processes

Illustration for article titled iPhone SDK Limitation: Only One User-Made App Running Concurrently, No Background Processes

The enthusiastic high-fives of future iPhone instant messaging users yesterday might be quite a bit less enthusiastic today when they find out that Apple is not going to allow user-made SDK applications to run in the background. This means every application, from IM to VoIP to GPS mapping, will have to terminate entirely when the user switches out to take a call or change a song. How does this affect you? It means you won't be a be able to receive IMs unless you're currently inside the IM app, forcing you to disconnect when you take a call. There's an upside and a downside to this decision.


First, we already know that apps running in the background as a process is possible on the iPhone. The iPod app, SMS app, and various other apps all run in the background now and continue running no matter where you go in the phone. Also, user-made Installer.app apps like Apollo (an IM client) already run in the background just fine. So why did Apple make this limitation that all apps have to quit whenever the user switches out? Memory management. From Apple's Human Interface Guidelines for the iPhone:

Illustration for article titled iPhone SDK Limitation: Only One User-Made App Running Concurrently, No Background Processes

Apple has no idea what combination of applications you could possibly install on your phone, and they can't control it. If you were to install two apps that took up loads of the iPhone's memory (we're talking RAM), and they both ran in the background, it would slow down the phone's other, more important tasks such as calling or iPodding. If this were the case, Apple would be blamed for making a slow or non-responsive phone even when it's not actually Apple's fault. This is exactly the thing that goes on in Windows Mobile devices. It's fine when you're just running normal, natively-installed apps, but when you get to multi-tasking with your own installed programs, the phone becomes sluggish and everyone curses Microsoft. Apple wants none of this.

So the implication to you, the end-user, is that you can't have apps running in the background, constantly checking the internet. This means no RSS reader that's always up-to-date and no IM apps that always sit in the background, listening for messages. If you're wondering Exchange's push email and calendars are going to work in this scheme, it'll be integrated into Apple's first-party Mail system, which can be allowed to run in the background.

But in the end, it's only a small portion of apps that are really affected by this rule. Games or utilities can save their app status to disk often so that you can resume where you left off when you start it back up. But until the iPhone allows SDK-applications to run in the background, you're probably better off using a web-based chat application in Safari (which already has permission to). [Tech Crunch]



Palm PDAs use a similar model - only one app runs but exiting an app and returning are seamless - the app will reopen exactly where you left off so such a model is managable and fairly usable.

However, these days it's pretty inexcusable. My N95 runs several native apps and Java apps at once and is still perfectly usable - it just kills apps as memory runs out. Even my sister's Sony Ericsson feature-phone can run a few Java apps at the same time.

If they are claiming it's to stop calling and such from being affected then just reserve memory solely for that. Since this thing is supposed to be running OS X this sounds like a pretty pathetic limitation.

How much do you want to bet that big development companies with flagship products will be allowed to get around this?