Developers and the Apple faithful are still arguing about Apple decision to block third party apps from running in the background on the iPhone. I’m going to try to offer a bit of perspective on the issue by explaining how current smartphone platforms deal with background apps.

Going by the classic definition of smartphone, both Google Android and the Blackberry JDE are arguably not smartphone platforms and feature phones with J2ME are sure as hell not one. But I am going to include them for the sake of comparison.

Palm OS

Lacks background process. Anything running “in the background” is in fact an OS interrupt handler or some other hackery. Palm OS is simply obsolete in terms of operating system design, and has been for years.

Symbian

Symbian allows full GUI background processes. When the device runs low on memory the operating system will start shutting down background processes. Additionally many of its APIs have explicit error conditions related to low memory errors and resource sharing. The operating system notifies the application when it needs to close it for memory reasons by sending the EEikCmdExit message.

Windows Mobile

Windows Mobile is similar to Symbian w.r.t. background apps. It allows full GUI applications to run in the background and uses its standard message delivery system to notify the application before closing if it runs out of memory (messages WM_HIBERNATE and WM_CLOSE).

Feature phones with J2ME

Sony Ericsson first, and recently Nokia have added background running for J2ME applications. Midlets are by nature usually very frugal on memory consumption so it works fairly well. In addition J2ME also supports termination notifications issued by the OS, so applications can save their running state on low memory conditions. That said the majority of J2ME feature phones are not from Sony Ericsson or from the high end Nokia range, so in general background running midlets are not supported.

Blackberry JDE

I am not experienced on Blackberry development, but as a platform it has supported background applications since day 1 and they are explicitly supported in the API.

Android

Android probably features the best and most balanced background application support. It has memory warning callbacks, like Symbian, and the explicit guarantee that the operating system will try its best to keep the application around, like Windows Mobile. But its defining feature is the the concept of Services: UI-less processes that run in the background and can be spawned on request by applications or by URI schemes:

A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application’s process, depending on its needs. Other components “bind” to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player; even when the user quits the media-selection UI, she probably still intends for her music to keep playing. A Service keeps the music going even when the UI has completed.

iPhone OS

The iPhone OS is a full Unix-like operating system, with a full blown kernel with memory protection and demand paging, running on a powerful CPU that has full support for all these features. In terms of OS design and features it leaves everything else in the dust. Which only makes the way Apple has chosen to cripple third party applications more painful to accept. The iPhone OS has full support for background applications if you are Apple. If you are not then it will kill your application the moment the user jumps out of it.

How Apple could add backround apps on the iPhone

The official reason is that background apps would kill the iPhone battery in no time, so they are not supported. But there is another way. Instead of keeping the full blown GUI of the application have the OS support the Google Android concept of Services. UI-less processes with access to certain features like the sound and network system, working under CPU and I/O quotas so they play nice to each other. They would be still under a “can be killed anytime” policy, but since they don’t need to keep a GUI around they would be much easier on the RAM and CPU of the device.