wraggster
March 7th, 2008, 22:41
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:
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).
http://gizmodo.com/365327/iphone-sdk-limitation-only-one-user+made-app-running-concurrently-no-background-processes
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:
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).
http://gizmodo.com/365327/iphone-sdk-limitation-only-one-user+made-app-running-concurrently-no-background-processes