What follows is a first-look at the just-announced multitasking features in the next iPhone OS. It is solely my opinion.
As I predicted in my previous post on the iPad & iPhone and multitasking, Apple is adding multitasking-like support to iPhone OS 4. And as I wildly speculated, that support is largely (although not completely) in the form of background services. Let's take an initial look.
First, as I wrote in my previous post, both the iPad and iPhone support multitasking today. At the system level, many processes run concurrently, and Apple-provided applications are allowed to multitask. What we are discussing here when we say "multitasking" is specifically the ability for third-party applications to multitask.
Second, this is a very early look at what Apple announced at today's event, which is still going on as I type this. Thus, cut me some slack. Developers should consult more detailed documents, which ought to crop up over the next few days and weeks.
What did Apple announce? A lot of spin, actually, but also two simple features. These features do not allow third-party applications to multitask. That is, on iPhone OS 4, as with now, only one applications runs at a time. What these new features do enable is functionality that fulfills many of the same use cases as multitasking. Let's look at them:
Services. Apple is adding a set of service APIs that allow background processes access to a subset of the device's functionality. Such services have access to, at least, notifications, geolocation, deferred computation, VoIP, and media playback. Having a service API limits the ability of background applications to run errant and destroy battery, but that is not a primary concern. As I stated in my previous post, the real concern with multitasking on an embedded, swapless device is memory consumption. Battery life is a straw man. So how do services solve the memory consumption problem? Alone, as described in the event, they don't. But iPhone OS will continue to kill applications that leave the foreground. Thus, applications will need to be refactored to provide a background component that only uses the new Service APIs. Without the risk of unbounded multitasking, memory pressure is greatly relieved.
Serialization. This was tacked onto the end of the discussion of the new services API, as if it was another service. But it is not. Described as "fast app switching" during the event, this is essentially a serialization API. When apps exit, they may choose to save their state to the backing store. When they restart, they reload this state. iPhone OS provides a simple object serializer today, called NSCoder. It is unclear if Apple is just pushing for better use of this class, or if they are adding additional APIs to make serialization both easier and more powerful. Either way, this will make it appear as if applications are actually multitasking—even though they are not—by allowing them to recover their exact state on restart.
So what about these solutions is "gonna be the best?" Nothing. In fact, what was announced is not even multitasking. Moreover, the new functionality isn't anything that other platforms don't offer today. Android, for example, provides excellent support for both of these features via Services and Bundles, respectively. The new iPhone APIs are not novel. But, despite the spin, that isn't what matters. All that matters is the user. If these APIs are sufficiently robust, they will benefit the user by enabling developers to make better apps.
One difference between Android and iPad & iPhone is that Android does not kill applications on task switch. The iPad & iPhone will continue to do so. Thus, in some sense, Android has a third solution to application multitasking: We allow apps to actually multitask until the system experiences memory pressure, at which point our OOM killer is able to kill applications in least-recently-used order. Then, our serialization solution kicks in, making their reload transparent to the user.
