Archgrove

The big tech news today is that Apple’s iPhone OS is getting multitasking. I thought I’d briefly discuss what that means, and the implementation choices that Apple have made. This information will be based off the presentation, rather than the (current NDAed) SDK.

Multitasking is really an end user experience – that of doing multiple things on a device at the same time. There are many ways to implement this within an operating system, especially one where the UI is so constrained as to make displaying more than one application at a time virtually impossible. Based upon our definition, and despite what some people will claim, iPhone OS 1.0 through 3.2 have had multi-tasking built in, in 3 distinct ways.

• True pre-emptive, multi-process multitasking: This was reserved for Apple’s first party applications. Here, each application is a true process, and runs continuously no matter what you’re doing. Mail is one example, iPod another (You still hear new mail notifications, and music keeps playing, even when you’re not in Mail or iPod).
• Push notifications: For any long running task. This is really a cheat – you have to write a server side application, running on a machine away from the phone, that carried on doing “stuff”. When stuff was done, or something interesting happened, you send Apple a notice. Apple then tells the user iPhone, which can launch your application which picks up on the notice.
• Suspend and resume multi-tasking: All App Store applications currently follow this model, which you might call “system modal multi-tasking”. Applications are loaded, run until you press “Home”, then quit. To make it seem like multi-tasking, the rules of good development stated that, when quit, applications should save their state (the last page being viewed, half finished emails and so forth). The next time you load it, the application restores the data and UI so it looks like you never left.

For a lot of applications, this is enough. Aside from the occasionally annoying reload times, any decent application implemented a state persistence that makes it look like you are just switching from app to app whilst they sit in the background, waiting. For those that must know right now that Bob has announced his Wedding on Facebook, you’ve got Push notifications. Unfortunately, these solutions have not been enough for a large class of applications – Those that must run on the iPhone, yet remain useful even without visual attention. Some common classes that have emerged are

• The “I’ll keep playing audio” applications (Pandora, Spotify etc.)
• The “I’ll wait for something to happen, then spring into action” applications (Skype, TomTom etc.).
• “I’ve things to do whilst you wait” applications (FTP apps, WordPress etc).

So why not allow “true” multitasking for all applications? Apple have always said, and I personally agree, that unrestricted, pre-emptive, process based is a bad idea on mobile devices – badly written applications drain battery life and degrade the end user experience. By taking memory they don’t need, failing to suspend unneeded computation when not frontmost, any application can drag down the end user experience of the entire phone. Note that I say phone – the majority of users will not link their lag when typing SMSs to the poor performance of StupidDev HyperFart HD, and will complain about their new iPhone being slow and useless.

Rather than open full multitasking, iPhone OS 4.0 gives targeted solutions for the classes of problems listed above.

• Fast application switching: This solution just makes the previous “Save state” solution more palettable, solving the “Long reload” times between switching applications. Rather than terminating an application, then reloading it from scratch, the operating system “freezes” it, and when you switch back, it can be “unfrozen” far more rapidly than it could be reloaded.
  Background listening: This solution allows applications to stay running in the background, performing simple audio streaming tasks – playing music or sound, and using the network to fetch it. I’d imagine much more than this is forbidden, but it’s enough to allow Pandora and Spotify to run without issues.
• Local notifications, VOIP Services and Location notifications: This will be a combination of solutions. Local notifications will no doubt be push style, but scheduled via a timer. Location services will be similar – a callback into a frozen application that fires when the location changes. VOIP, I’m not sure – some kind of limited network usage so you can poll the server seems likely.
• Background tasks: I expect that, upon being “frozen”, your application will be allowed to perform some computational tasks under strict supervision (time or resource limited). This mode will not be the “catch all” true multitasking, whereby you can sneakily do any computation you want in the background – it will be restricted to cleanup, or long running task completion. I expect this to interact with local notifications to allow, e.g. FTP uploads.

The interesting thing about this approach is that it’s extendable, as and when needed. The implementation of these “multi-tasking classes” is no doubt just true preemptive multitasking, with a more aggressive scheduler that will kill off applications that don’t conform. If another class of applications turns out to be both needed, and not too draining on the hardware.

What does this all mean for end users of iPhone apps? Well, practically, not a whole lot for most applications. They’ll load faster (because they never quit), and those that fail to be good, state saving, citizens will behave as people actually want. The real changes will be seen in music players and location aware services – Spotify will become more useful, and Tom Tom will co-exist happily with making phone calls. Realistically, much like copy and paste, I suspect this will be something people have ranted about for years, will find some nice usages for, but that will not be a huge deal for 99% of iPhone users.