iPhone 2.0 SDK: The No Multitasking Myth
March 13th, 2008
Daniel Eran Dilger
Certain pundits have developed a rash of malignant concerns about iPhone 2.0′s SDK. The first issue they’re scratching at is the iPhone’s apparent inability to run multiple applications at once. The suggestion is that the iPhone is a multitasking impaired appliance just like the original Mac or the Palm Pilot, and unlike the supposed multitasking powerhouse that is Windows CE, which powers Windows Mobile devices. That’s wrong, here’s why.
Auf Deutsch: iPhone 2.0 SDK: Der „kann kein Multitasking“ Mythos
Übersetzung: digital express
The iPhone is Unix.
The first clue into discovering how the iPhone works is a look at its core OS. The iPhone runs Apple’s same kernel as Mac OS X: a hybrid of Mach and BSD that hosts a standard Unix subsystem. It supports multiple concurrent processes and multiple users.
At this point, it’s useful to point out that the Palm OS was also built on top of a multitasking kernel, but Palm only licensed it for use from Kadak as a single-tasking environment. That made the Palm OS very much like the classic Mac OS from the mid 80s: to launch a second application, the first had to be shutdown.
Apple doesn’t face the same problem with the iPhone; it owns the iPhone’s kernel and faces no other external technical limitations to prevent multitasking. The ability of the iPhone to answer a call, pull up the Maps app while the call is in progress, and then follow a link to a web page before ending the call was demonstrated in one of its first advertisements.
The iPhone rings when browsing the web, music plays in the background while performing other tasks, and can check emails periodically in the background. It can clearly multitask. So why does Apple state in the SDK docs that “only one iPhone application can run at a time?” For starters, it is useful to point out that the iPhone does not suffer the same architectural problems as the Classic Macs or Palm Pilot.
Multitasking Macs before Unix.
The original Mac didn’t have the resources to run multiple applications at once. The first Mac users quickly found that running one application at a time was indeed a serious limitation. In 1985, Andy Hertzfeld developed a utility called Switcher that allowed users to pause the running application and start a new one. By 1987, Apple released MultiFinder, which allowed Macs to display multiple concurrent applications and rapidly move between them.
However, the Classic Macs weren’t doing Unix-style preemptive multitasking, where the operating system strictly manages the processing resources given to each running application. Instead, the system relied upon applications cooperating to take turns on the processor; if an application fell into a loop, it could cause the whole machine to stall.
That doesn’t happen in Unix because processes aren’t trusted to cooperate; they are explicitly managed by the kernel. If they stop working, they are bypassed and can be purged from the system. The only process that can freeze the system is the kernel itself, which is why all software in the kernel has to be extremely stable. That’s also why Apple discourages developers from writing kernel extensions unless they are really necessary.
Just Because You Can, Doesn’t Mean You Should.
The iPhone has the same Unix ‘kernel in command’ architecture. However, just because the system can run multiple concurrent applications doesn’t mean it’s a good idea to allow developers to load up all the processes they care to run in the background
In Mac OS X, opening lots of concurrent applications isn’t usually a problem. If the system runs out of RAM, it can page inactive applications onto the hard drive using Virtual Memory, where they can hibernate until they are called to activity again.
The iPhone has the same virtual memory system, but doesn’t have gigabytes of RAM or a hard drive to use as a Virtual Memory swap space. Instead, it has 128MB of RAM, of which something like 11MB appears to be used for VRAM and 19MB looks to be used by system overhead, leaving around 76MB reported by sysctl as user memory.
By limiting the amount of background processes running, the iPhone’s OS X can offer more of that available RAM to the foreground application, along with a less distracted processor. The iPhone is not a general purpose computer; it is primarily a phone, browser, and iPod. Due to the restrictions imposed by the SDK, it will also be a credible gaming platform and pack the power to run significant productivity applications, all without giving up the ability to be a responsive phone, browser, and iPod. Other devices can’t make that claim.
The Problem With Background Processes.
While the iPhone has around twice as much RAM as the typical smartphone, 76MB is easy to eat up if you have lots of background processes running. In addition to RAM, those processes will also consume the processor power available for media playback, WebKit rendering, telephone audio and radio signal processing, VoIP data encryption, and processes listening for push email, incoming calls, SMS messages, or configuration information, all of which are critical features that users won’t be happy about if they aren’t all working flawlessly.
In addition to taking up bandwidth important to the core operations of the phone, extra background processes will help keep the processor consumed, which means it will be running hotter and eating up more energy at all times, resulting in a shorter battery life and perhaps a shorter device life as well.
Apple has a responsibility to iPhone users to develop guidelines that ensure that the system continues to work as expected, doesn’t overheat, and doesn’t plunge in battery life as new applications are installed. Not allowing third party developers to install background processes is part of that plan. It would be irresponsible for Apple to kick open the floodgates for developers and then blame users for not understanding how to manage their own process allocation within the iPhone’s thermal envelope and resource constraints.
The Problem with Foreground Multiprocessing.
In addition to the processes running in the background, there’s also an issue of running multiple applications in the foreground. Of course, the iPhone does appear to run multiple foreground applications at once. While on the phone, you can return to the home screen and launch in and out of other apps. During the entire call, a green strip appears at the top of the screen to act as a quick hyperlink back to the call progress screen.
iTunes will also play audio while other apps are running (although this will anecdotally make it more likely for Safari to crash while it navigates between web pages). At any time, the Home button can be double clicked to bring up an iPod playback controller screen overlay.
In both examples, the shared, concurrent UI presented is rather limited. This is no accident. Not having any other applications running concurrently not only gives the active app and critical background processes more resources, as noted above, but also greatly simplifies the UI for the user.
The persistent phone call is unique in that the iPhone is primarily a phone; the iPod features are also a key element of the device. However, if every application could reserve a spot at the processor table, there frequently wouldn’t ever be anywhere to sit. Even worse, the iPhone’s display isn’t really big enough for apps to share. Of course it could, but thank Apple for knowing better than to crush applets into the same screen with an interface inappropriate to a handheld mobile device.
The idea that the iPhone should let apps decide what they’re going to do when asked to leave, rather than setting an enforced system policy, might sound good but isn’t well thought out. Apple’s decision is to do with third party apps exactly what it does to Safari: when the user hits the Home button, the system saves the currently running application’s data, quits the app, and presents the Springboard menu of apps. When the app is next launched again, it starts up from where it left off.
Because the launch time is so rapid, there’s really no difference for users between trying to leave an application running in virtual memory and simply quitting and then relaunching it again later when needed again instead. The technical difference is that quitting apps results in better use of resources, including better battery life. Users will notice that.
That’s why Apple decrees in its SDK: “Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.”
Invent, Suggest, Panic!
Non-engineering savvy blogs such as the ironically named BoyGenius Report have joined arms to sign up petitions demanding equal rights for third parties’ applications to run in the background and not have to quit when users switch between apps. Sounds good, but do they know what they’re talking about?
Zach Epstein spelled out his fears of the potential doom of “no true multitasking” on the iPhone by citing developer Robert Balousek as saying, “If you are running an application such as AOL Instant Messenger on your iPhone, every time you receive a call or browse away from the application you would be signed out, you would lose any unread messages, and your conversations would end.”
However as Christopher Cox noted, “the author of this article is exagerating big time [...] the app will be able to suspend and save current data when something interrupts it. When you go back, your old messages will still be there. [...] the AIM server doesn’t actually disconnect you unless your program sends a disconnect signal or you are not connected within a specific timeout. This means it can pick right back up where it left off when you come back to the application (and you don’t initiate a re-connect). The only disadvantage this brings from the norm are if you want to stay on AIM 24/7 in the background or other daemons. This will not be a show stopper for most people.”
What Would Happen If Apple Didn’t Know Any Better.
While it’s comforting to know that iPhone SDK panic related to multitasking is overblown and ill informed, is it still possible that the iPhone might be much better off without Apple’s engineered limitations? There’s no need to speculate. We already can get a clear picture of how disastrous things would be if the iPhone were engineered by a committee primarily interested in pleasant sounding buzzwords; that picture is delivered by Microsoft in WinCE.
Microsoft conceived of WinCE as offering a multitasking architecture like Unix, but despite giving it a paged virtual memory architecture, it still only supports 32 concurrent processes and each is limited to its own 32MB virtual address space. This is supposed to be addressed in WinCE 6.0, which should be available in a couple years. Until then, multitasking in WinCE is fundamentally flawed. Of course, it gets worse than that.
In addition to Microsoft’s architectural limitations that stymie developers from making efficient use of its multitasking features, WinCE proves that the general idea of having no limitations on third party background processes and concurrently running applications on a handheld device is a bad idea for a number of reasons. The first relates to the resource issues I already raised. In the words of WinCE Enthusiast Chris De Herrera:
“There are times when having multiple applications running at once causes the foreground application to slow down noticeably. This slowdown is due to the amount of time that the operating system is spending servicing background applications. In these instances, I recommend that users consider performing a soft reset.”
Like kill on the road,
Windows has failed to respond.
Control! Alt! Delete!
But there’s another reason why running multiple applications together on a mobile is stupid: there’s no room to see them at the same time. Without the screen real estate, there’s not enough pixels to support a desktop style arrangement of multiple overlapping windows as introduced by the Lisa, with close boxes and title bars to switch between the windows.
That reality hasn’t stopped Microsoft from trying to crush its clone of the Mac desktop UI into tiny screens since the late 90s, but it did result in making those efforts unsalable. WinCE devices are plagued with complexity to the point that it’s hard to get anything done with them. They crash frequently and have abysmal battery life. The iPhone is so plainly simple that it’s easy to pick it up and start using productively without any training. It just works. If Apple had tried to force in the same Dock and menu bar and Finder desktop and floating windows from Mac OS X, the iPhone would have been tragically unusable as well.
The Spectacular Failure of WinCE and Windows Mobile
Less is More; More with Less.
So while the iPhone has a better multitasking kernel than WinCE, its engineers knew better than to deliver a system like Microsoft’s, which could seemingly do everything on paper, but in reality could do nothing very well and subsequently couldn’t sell either. Instead, the engineered limitations of the iPhone 2.0 SDK will make the device more useful to users.
Even before the new software’s availability, the existing iPhone is already outselling Windows Mobile phones in the US with a 27% share of the market and a whopping 71% share of all mobile web traffic.
And just as with the desktop PC, Microsoft will find it impossible to back away from its legacy of complexity to offer anything remotely similar to Apple’s iPhone in WinCE, because existing Windows Mobile applications all assume the right to hog the processor in the background and keep Windows Smartphones running slow, inefficiently, and awkwardly complex enough to only appeal to the most devoted of Windows Enthusiasts.
When they complain that the iPhone doesn’t share the same problems, it should now be more clear why practical simplicity is such a difficult concept for them to understand.
More on the iPhone 2.0 SDK
iPhone 2.0 SDK: The No Multitasking Myth
iPhone 2.0 SDK: Java on the iPhone?
iPhone 2.0 SDK: How Signed Certificates Work
iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP
iPhone 2.0 SDK: Readers Write on Certificate Signing
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!