A proposed solution (There be dæmons)

So, I’ve stated my case for why traditional (from an end-user perspective) multitasking on the iPhone is a bad idea; but criticism without constructive input is pissing in a sea of piss…or something. Before I begin, please note, my understanding of the iPhone’s system architecture is not crystal clear, so this idea might not be tenable, but given the behavior of some Apple-written iPhone apps it seems possible.


The crux of my argument against background tasks is that management of app state outside of the established “touch icon for app, touch home for no app” paradigm is a Bad Thing™. So, given that, how do we allow for background processes?

Hide them. Make them dæmon-style tasks that have no (or, very limited) user interaction. Allow them to be paired with a full app, but make the distinction between apps and dæmons clear (at least for developers; end-users shouldn’t even need to know the word dæmon). The iPhone has a very narrow use spectrum compared to a full-blown desktop or laptop, so (my theory goes) if we take a few extra precautions with these tasks we can ensure that the overall iPhone experience remains satisfactory.

“Uh…what?” OK, lets start at the top. Say you have a brilliant idea for an iPhone app, but it needs background functionality to make sense. For the sake of argument say it’s an app that reminds you when to pick up your kids. First, you write the main app: the interface that sets your data and, to make use of background functionality, registers the dæmon for system-provided notifications of time events. Then, you write the dæmon, which pops up a push notification-style alert view when it receives the notification. Finally, you submit your app to Apple where—since you requested background functionality—it goes through an extended approval process, shows up in the app store and makes you millions of dollars.


Simple right? More legwork for the developer, but the desired effect for the end user. Now let’s dig beneath the gloss and look at the rules.

You’ll notice in the first step you register for specific notifications. That’s it. That’s all you can do. Your dæmon doesn’t get to run at all unless you ask for a specific, temporally singular (i.e. non-continuous, but possibly repeatable in the future) event in the iPhone’s catalog of event types. This catalog would be directly related to the already-present background tasks on the phone, such as status changes in the iPod app (play, pause, song change, etc.) or time events (Calendar alerts, alarms, countdown timers…). Similarly, the only interface element that dæmons have access to is the UIAlert view (in the style of push notifications or text messages) with an optional button to launch your app. (e.g. In the example above, there might also be a “Where?” button that opens your app to a maps tab with a pin at the soccer field.)

There’s more: the dæmon must also idle at 0% CPU time, have a max RAM usage cap and finish execution within X seconds of the notification being posted.

(Note, though, that any code you can make run within these constraints is fair game. Data manipulation, network connections, whatever; but make sure it fails gracefully if it gets cut off.)

These rules may seem arbitrary and draconian, but I assure you they are only draconian—which is what the iPhone needs. They would prevent an app from eating resources until the phone dies, limit an app’s avenues of “attack” to already established iPhone alert paths (how would you feel if your screen slid over to an AIM chat, away from your in-progress Tap Tap Revenge game, because AIM “needed” your attention?) and provide enough leeway to perform any task that is absolutely necessary in the background. (Which, from my experience, tends to be maybe a small amount of calculation and user notification.)

This type of background process, combined with push notifications and properly written iPhone apps (that maintain state between launches), should cover almost all [1] use cases where multitasking is desired. If you need any more, you’re doing it wrong. Write a desktop application.

1. One major use case where this model fails is downloading extra content, especially now with in-app purchases. To handle this there might be a global download manager that an app would pass a request to, and the associated dæmon would listen for a download finished/failed notification. Mail already keeps its downloads running after exit. Since calling the download manager theoretically wouldn’t be too expensive (and therefore fair game for use in dæmons) apps like Pandora could chain downloads to create a play queue and interface with the iPod app for audio playback.

← back