Why don’t the iPad and iPhone support multitasking? The answer isn’t what you think.
Note: This article was written for versions before IPhone4, because new generation Apple Phones already support multitasking right now, Thanks Steve.. :)
There is a lot of misconception around support for multitasking in the iPhone and its giant cousin, the iPad. What follows is my analysis of the situation. I am not privy to any insider Apple information. Moreover, while my knowledge is certainly colored by my work on Android, I’m not drawing a comparison or using any Google-specific knowledge.
First, obviously the iPhone and the iPad do support multitasking. This is 2010 and both are built on modern, powerful operating systems that provide support for preemptive multitasking. Indeed, at the system level, there are many processes running concurrently. And some Apple-provided applications, such as the music player, clearly multitask.
So let’s redefine the complaint. What in actuality is not supported is the ability for third-party applications to multitask. That is, the system enforces a policy whereby once an application leaves the foreground, it terminates. In some ways, this makes sense. The iPad and iPhone user interfaces are single window, single document. Not allowing for background applications probably works out for a whole lot of use cases.
Apple says they do not support multitasking because it is a hamper to stability and a drain on battery life. That clearly isn’t true—the iPad has plenty of processing power and battery capacity. Rumor is that Apple is going to add multitasking in a future OS release. This rumor likely is true. Is Apple somehow going to make background applications not consume any battery? Of course not. These excuses are straw men.
The real reason that the iPad and iPhone do not allow third-party applications to multitask is likely more complex, more technical. Bear with me here. Both the iPad and iPhone, as mobile devices, have limited memory (256MB in the current incarnations) and no hard drive. No hard drive means no swap file. Limited memory and no swap imply that applications have a small, fixed amount of memory at their disposal. They don’t have the luxury of seemingly-infinite memory, as a modern system with swap has. Memory consumption is thus a critical system constraint. Like most systems, the iPad and iPhone deal with this by killing applications that use too much memory via a mechanism called the out of memory (OOM) killer. Unlike most systems, applications designed for the iPad and iPhone know how much memory they have at their disposal, and are designed to operate within those constraints. This is classic memory management in embedded programming. No swap, fixed memory, you deal.
What would happen if third-party applications could multitask? Some number of applications would be in the background. But each application was written presuming it had access to some fixed amount of memory. Thus, if the background applications consumed too much memory, the operating system would have to kill them. But the user would expect that he or she could switch back to an old application, and it would still be running where it was left. He or she certainly doesn’t expect applications to just die every time a new application is run, losing state and even data.
Simply put, the reason the iPad and iPhone do not support multitasking is because it is hard to allow multitasking in a system with no swap and a limited amount of memory. Apple could enable multitasking—indeed, there is no reason that the devices couldn’t support it right now, with a one or two line code change—but your applications would constantly be killed. That isn’t a very useful feature.
So how is Apple going to enable support for multitasking? Likely similar to how Android allows it. The Android platform was designed from the ground up for use on phones and other embedded devices. Consequently, we built in a mechanism whereby applications can save their state, including their current view, with the system. In fact, through this state saving mechanism, which we call Bundles, Android applications can operate as if they are stateless.
Thus, allowing for multitasking on Android is easy. Like the iPad and iPhone, we have a powerful, modern operating system (in Android’s case, based on the Linux kernel). Unlike the iPad and iPhone, we also have Bundles, which allow apps to save their state. Android’s OOM killer is aware of background applications and is capable of killing them in least-recently-used order. If the user switches back to an application that has been killed, the Android platform reloads the application’s state via Bundles. The whole process is seamless. Because Android has this state-saving framework, multitasking is feasible even on a device with limited memory and no swap.
In summary, the iPad and iPhone don’t support multitasking not because it would hurt battery life, but because it is hard to do so on a swapless, embedded device without platform support for serialization, which the devices lack. It is likely that Apple will add the requisite functionality in a future OS release. Until then, enjoy your giant iPhone. Or rock a Nexus One, which multitasks.
Update: Folks have asked me how a serialization system such as Bundles enable support for persistent applications, such as music players or IM clients. You wouldn’t want these applications killed, even in low memory situations, and their state is ever changing so saving it isn’t productive. There are many ways Apple can provide this support. On Android, we do so via Services. Most applications use the Bundle framework to save their state and are thus easily interruptible. Applications that provide a service to other applications, are a server, or function as a long-running background task use the Service framework. These applications are managed by the system more like Unix daemons and are not killed in least-recently-used order when memory is low.
Ref: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html
Ref: http://android10.org/index.php/articleswhitepapers/164-multitasking-the-android-way
