Ten Myths of Apple’s iPad: 9. It can’t multitask
February 17th, 2010
Daniel Eran Dilger
Here’s segment nine in my series taking on iPad myths: no the iPad isn’t incapable of multitasking.
Ten Myth of Apple’s iPad: 1. It’s just a big iPod touch
Ten Myth of Apple’s iPad: 2. iPad needs Adobe Flash
Ten Myths of Apple’s iPad: 3. It’s ad-evil
Ten Myths of Apple’s iPad: 4. It was over-hyped and under-delivered
Ten Myths of Apple’s iPad: 5. It’s just a Tablet PC or Kindle
Ten Myths of Apple’s iPad: 6. It needs HDMI for HD video output
Ten Myths of Apple’s iPad: 7. It needs cameras
Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers
Ten Myths of Apple’s iPad: 9. It can’t multitask
Ten Myths of Apple’s iPad: 10. It needs Mac OS X
.
Okay, so this gets a bit tiring, but Apple didn’t design the iPhone OS “without multitasking capabilities.” The simple truth is that the iPhone OS inside the iPhone, iPod touch and the iPad explicitly multitasks all the time, using the same preemptively multitasking Mach/BSD kernel as the desktop version of Mac OS X.
The iPhone is constantly running processes that listen to the mobile network for incoming calls and texts, it runs an iPod process for playing back music all the time, it watches for background notifications being sent to idle apps, and there’s a variety of other things always going on. This is the definition of multitasking.
Understanding multitasking
A preemptively multitasking operating system appears to run multiple processes at once by very quickly switching between processes, a task managed by the OS kernel itself. This happens so quickly that several processes appear to be running at once, something like frames of a movie creating the impression of motion.
In many cases, the iPhone and its sibling devices are actually multiprocessing as well by running concurrent tasks on different processor cores. For example, when playing back video, the iPhone can spin off the heavy lifting involved with decoding H.264 to a specialized processor core while the main processor core continues to handle other tasks, such as listening for updates or maintaining the user interface.
A cooperatively multitasking system expects apps themselves to relinquish CPU control and share communal system resources in order to allow the user to work with several apps at once. The Classic Mac OS appeared to offer multitasking in this way, but if an individual app ever stopped responding, the illusion of multitasking immediately collapsed because the system might likely never recover.
With a preemptively multitasking kernel like the iPhone OS’s Mach/BSD, the kernel will simply take control back from a bad app and terminate it, or the user can kill an app that isn’t responding. In any case, the system continues to multitask without apps needing to cooperate; the kernel enforces this behavior.
When less is more
A single-tasking operating system would be one that can only ever run one app at once, like the classic Palm OS or the original 1984 Macintosh. In both systems, everything was designed to only allow one app to run at once. The reason for this in both examples was to provide the foreground app with full control of all system resources at a time when there wasn’t much RAM or CPU available.
For similar “finite resources” reasons, the iPhone, while it is completely capable of preemptive multitasking, is artificially and arbitrarily limited from running multiple third party apps concurrently.
The iPhone OS does not launch a bunch of foreground apps at once because there’s no room for a windowing environment and insufficient resources to support multiple concurrent applications all trying to hog the processor behind the foreground interface that the user sees.
The iPhone is not a server and it doesn’t present multiple concurrent app windowing, but it does multitask.
Multitasking in a mobile environment
Most of the people talking about “multitasking” in the iPhone OS do not seem to understand what they are talking about. Using a single word to broadly cover up many nuanced details is simply not useful. What they usually mean to say is that the iPhone does not run any third party apps as background tasks, at least without first breaking its security model (via a “jailbreak”).
How well does this aspect of “multitasking” — actually “app concurrency” — work in a mobile environment? Well, the implementation is important. All multitasking models are not the same, so speaking of “multitasking” as a simplistic bullet feature is very misleading.
Microsoft proved what a dumb idea multiple app windowing would be in Windows CE / Windows Mobile. It launches multiple apps at once, each in full screen, overlapping windows. When you close a window however, it doesn’t necessarily shut down the process. And windows may be hidden behind other windows. It’s a mess, it robs the battery, it makes no sense to the user, and it does not allow any clever interaction between apps. It’s “multitasking” in name only, not in the sense of being useful.
In many ways, Palm’s original single-tasking Palm OS was better; the battery lasted much longer and it was more understandable to users. There was minimal need for users to have multiple apps running at once at the time anyway.
Google’s Android proved that copying Microsoft results in the same degree of success as Microsoft, at least in mobile devices. Sure you can “concurrently multitask,” as long as you want to trade usable battery life for the freedom to manage processes yourself and if you don’t mind gaining the ability to install spyware and spread viruses without even knowing it.
A top Android app is a tool to kill out-of-control multitasking. However, there’s no app for Android that can protect users from installing malicious background spyware and viruses. Apple built in a security system that makes those things virtually impossible to install under the iPhone OS.
So anyone who complains that the iPhone or iPad “doesn’t multitask” is simply signaling that they don’t understand what this means. Or, perhaps, that they want to muddy the waters to ensure that their readers not really understand what it means.
Inside Google’s Android and Apple’s iPhone OS as software markets
Mobile Multitasking
When Palm created its original operating system for the Palm Pilot 15 years ago, it licensed a third party embedded OS kernel in a single-tasking configuration. In other words, the Palm OS simply could not run multiple processes at once due to licensing limitations imposed on its kernel.
In contrast, Apple started with its own preemptively multitasking kernel and implemented a variety of background services to provide its iPod, phone, SMS, notifications, clock, and other background features all the time, regardless of the foreground app. But Apple also took the novel step of making the iPhone simple enough to work in an understandable fashion.
Rather than allowing users enough rope to hang themselves with a mess of background applications that aren’t obvious to the user, Apple designed the iPhone OS to launch apps in a sandboxed environment where apps can only see their own data. They can’t access the private files of other apps or reserved system information.
When the user hits the Home button or accepts an incoming call, iPhone apps must immediately quit. This prioritizes the needs of the user over the convenience of the developer, and forces programmers to build apps that remain ready to terminate at any time. Apps simply can’t ignore the user or the OS kernel and remain running in the background, whether they have good intentions or malicious ones.
iPhone 2.0 SDK: The No Multitasking Myth
Multitasking and security models
The only way apps can be run concurrently on the iPhone is by breaking its kernel-level security, which enables both the idea of running multiple apps in the background and also opens up the device to spyware and other malicious threats. You can’t have one without the other. That’s why the desktop Mac OS X and Windows XP/Vista/7 both expose users to a certain risk of malware that the iPhone does not.
The Mac is largely protected from malware problems by virtue of its authentication mechanisms; users can’t install background apps without presenting their admin credentials, and can easily scrub away any malware after it gets installed. On Windows, it’s much easier to get infected without even knowing it, and it’s far more complex to clean up a problem afterward thanks to the convoluted Windows Registry.
Forcing users to manage their own security in a mobile environment is even more complex, and the risks are more intense because pervasively networked mobile devices can do more damage. Without a vigilant security model like the iPhone OS presents, a mobile device gone rogue could send spam in your name at your own expense, it could report your position to some malicious follower, and it could expose your personal contacts, calendar, and messages in ways that never really become a significant problem on the Mac desktop.
Google’s Android Market Guarantees Problems for Users
Thinking about security for users
In developing the iPhone and iPad, Apple actually thought about what users needed to do and what they didn’t want to do, and used that information to create an experience tailored to the mobile, networked environment.
In contrast, both Microsoft and Google have essentially worked to bring the PC desktop to mobile devices without really rethinking anything, which presents the illusion of greater functionality while secretly delivering a massive dose of insecurity, risk, and complication.
Most users are not only unaware of this, but also lack the expert security credentials to adequately manage this extra complexity on their own. And they shouldn’t need to. Even on the desktop, mainstream users have been forced to deal with and suffer through security issues that they needn’t have.
In the new frontier of mobile devices, thinking about security is critically important, particularly given the multibillion dollar mess that everyone witnessed blossoming around the naive PC desktop.
It’s too late to grieve about PC viruses, but it’s not too late to act to prevent a similar crisis from becoming pandemic on our mobile devices as well. Apple seems to get this, while Microsoft and Google either don’t or don’t care.
Three exceptions to the iPhone app model
While Apple’s mobile-optimized iPhone app model makes more sense for most users than the Windows PC desktop mess that Microsoft simply dumped on its own mobile devices (or the hybrid model Google used for Android which opens up some benefits along with its can of worms related to security, manageability and usability), there are several exceptions that the iPhone did not accommodate.
The first and most prominent is that many apps want to stay active in the background just to listen for updates: news, incoming calls, status updates and so on. Following the initial release of the iPhone SDK, Apple introduced a cloud notification service to address this side effect of its restriction on third party concurrency.
Apple’s notification server allows the mobile device’s operating system to accept incoming requests for its non-running apps, and either badge them or pop up an alert so that users can launch the app and take action based on the update. This allows apps to respond to external events without requiring that they be running in the background all the time.
Apart from listening for notifications, there are at least two other reasons apps might want to multitask: one is to provide a background local user service (such as replacing the features of Apple’s bundled iPod app for music playback while another app is running) and the other is to serve external data while the app isn’t in the foreground (such as reporting the phone’s location to Loopt or Google’s Latitude server).
iPhone Push Notification Server tied to Snow Leopard Server
Addressing exceptions in Apple’s iPhone OS app model
It’s widely expected that iPhone 4.0 will introduce a new mechanism for enabling specific third party apps to run in the background, either to provide an always on local service or to act as background external server of some sort.
Either option would rob the system of CPU power and memory, resulting in problems that most users would blame on the iPhone itself, rather than their own use of it. Which is, of course, why Apple restricts the way third party apps run.
The most prominent of requests for app concurrency relates to Pandora Internet radio and Latitude-style updates, both of which Apple could add to its own set of bundled apps and simply allow third parties to access as a system wide service.
For example, adding radio feed support to the background iPod process could enable third party apps to tap into it to provide a unique user interface that can play music that continues even when their app is quit.
Latitude or Loopt could similarly use a central OS service that reports the user’s location at a given interval. Those third party services could also send notifications to their app when other users send a messaging request, allowing the services to work even when the third party app isn’t actually running.
Most other needs for third party background tasks could similarly be rolled into the core OS, enabling the kernel to manage how much time to devote to those tasks itself rather than according background apps all the resources they demand as they run in the background, irrespective to what the user is trying to do in the foreground.
Engineering vs. marketing
As it is, Apple’s existing single app model (with notification exceptions) makes a lot of sense as a way to keep things secure and easy to understand for users. That’s especially the case right now because the iPhone and its generation of smartphones isn’t really capable of unlimited app concurrency or acting as a full-time server.
What about the blazing fast iPad? Well it certainly didn’t beg for multiple apps to be running in the background when I tried it, but anyone who wants to install a background process will probably get the opportunity within weeks of its release thanks to iPhone 4.0.
And again, there are a variety of ways Apple could roll out general background services that all third party apps could access without actually opening the floodgates and creating the potential for apps to do things that users must manage themselves.
Apple’s multitasking model for the iPhone and iPad really represent a triumph of engineering (making tough decisions to provide the best overall experience) over marketing (communicating to users that you’ve done a great job). After all, if Apple had made easy, populist decisions to satisfy the pundits first, the iPhone and iPad would face the same problems as Android.
Sure, the company would be getting less grief from sloppy incompetent journalists, but it would have also delivered a much less functional product that was harder to use and easier to exploit. As it is, users have their choice whether they want Apple’s product or Androids’s, and choice is a good thing.
Pingback: Ten Myths of Apple’s iPad: 6. It needs HDMI for HD video output — RoughlyDrafted Magazine()