A continuing complaint about the iPhone OS has been that Apple doesn't allow multitasking, a staple of the Mac OS since System 5 first added MultiFinder in 1988. Apple's stance is that allowing apps to run in the background would significantly hurt performance and battery life, but in iPhone OS 3.0, Apple added push notification, which addressed some - but by no means all - of the desires of those who were asking for multitasking.

For the most part, requests for multitasking capabilities had died down to a dull roar since the release of iPhone OS 3.0 and its push notifications. It wasn't that the desire had disappeared, but more that the debate was at a standstill.

The announcement of the iPad changes everything, because it includes a faster CPU (though how much faster is as yet unknown), 10-hour battery life in comparison with the iPhone's 5-to-9-hour battery life rating, and a screen with 1024-by-768 resolution that's far more spacious than the 480-by-320 resolution of the iPhone and iPod touch. The longer battery life could reduce Apple's concern that multiple apps running simultaneously would hurt battery life, and the larger screen raises the possibility of running apps side-by-side.

More generally, whereas the iPhone is aimed at short, focused tasks, the iPad is more likely to lend itself to longer, more general tasks that involve using multiple apps, just as we're used to on the Mac. It's easy to imagine wanting to use an iPad to read text in Mobile Safari, copy some text to a Pages document, and send that document to a colleague via Mail. That specific example may turn out to be possible with the current iPhone OS, but it points toward needing more ways for iPad apps to work together in the future.

Plus, if I'm on the right track with my suggestion that Apple's long-term plans involve even larger iPhone OS-based devices (see "iPhone Developer License Points to New Devices?," 28 January 2010), multitasking will be key - it's hard even to imagine what using a large-screen Mac would be like if you could run only one application at a time.

But what do we mean when we say that the iPhone OS should support multitasking? If we define what we're looking for more carefully, it might be easier to lobby Apple for support in iPhone OS 4.0 and beyond.

Push Notification -- The simplest form of multitasking is the one that Apple has already made available to developers, push notifications. In essence, applications register with a push notification service that runs at the system level, such that when a notification arrives, the iPhone OS presents the notification as though it had come from the app.

Notifications are one of the primary things that people want from multitasking - for one program to be able to notify the user of an event even when the notifying app isn't in active use. On the Mac, think about iCal - you want event alerts to pop up no matter what application you're using, and that can happen only if another process is paying attention in the background and can interrupt the frontmost application.

The problem with push notifications with regard to multitasking is that they are all responses to some external change in a cloud-based service like AIM or Twitter, not an example of a background app notifying you of some change. That is possible in the iPhone OS, of course, such as with calendar or timer alarms that presumably schedule internal notifications for specific times, but Apple hasn't opened that capability up to developers in any way that I'm aware of. It would be nice, though, and wouldn't seem difficult to add.

Background State Updates -- Another way we think about multitasking comes down to updating remote state in the background. This too is possible in the iPhone OS now, but only for Apple's apps. If you have Fetch New Data in the Mail, Contacts, Calendars settings screen set to Push, new email messages and changes to your contacts and calendars appear automatically. That's why you don't have to refresh Contacts or Calendar to make sure you have the latest changes; with Mail, you still need to check for new messages (or wait for the timer to trigger another mail check) for accounts without push. (You can of course make calendar and contact updating a manual process by syncing only via iTunes.)

While Apple's apps can make sure their state is always up to date by bringing data in while in the background, Apple hasn't opened that capability up to developers. Twitter apps, for instance, and RSS news readers, could benefit from being able to update state in the background.

I do want to distinguish between scheduled updates for something like Twitter or RSS, and continuous background execution, which I'll discuss later. You don't care if a Twitter client or RSS news reader checks every second, since each refresh can bring in old messages as well, whereas an instant messaging app might miss messages entirely if they arrived at the wrong time (and the server didn't maintain state with the client). That's why a chat app, or a GPS tracking app, might want to run all the time, since scheduled updates wouldn't be sufficiently fast or complete.

It would seem that updating background state on a schedule would be the sort of thing Apple could make available to developers, just as it's available for a few of Apple's own apps. Apps would have to register with the iPhone OS, which would mediate how often data was fetched, but that shouldn't be either terribly hard or excessively demanding on battery life.

Inter-application Communication -- On the Mac, we're accustomed to applications talking with one another in a wide variety of ways, such as Entourage sending a double-clicked URL to Firefox, Twitterrific asking Growl to display a notification, an iTunes controller displaying the current song, or even the Finder telling BBEdit to open a document.

A few of these behaviors are available on the iPhone, such as following a URL from an email message in Safari, creating an email message with a photo, and displaying an address in Maps. But for the most part, apps can only ask Apple's apps to do things; the main counter-example on my iPhone is Boxcar, which can open a variety of Twitter apps in response to a tweet notification. But Boxcar is extremely limited; it can open a Twitter app, but it can't reliably control that app in any useful way, such as to display the specific tweet in question, for instance.

The reason for this is that the main way apps can communicate with one another now is via URLs, and the width of that channel of communication depends on how robust the URL handler API of one app is, and how much of it is used by the developers of other apps. But this approach is limited, since the information must fit completely within a URL, and because it's unidirectional - the receiving app can't send any information back. Plus, in the current iPhone OS, files are private to each app, so one app cannot send a file reference to another app.

I could see a future version of the iPhone OS extend URL handling with the capability to send file references to documents in a shared space, and perhaps to return another URL to the sending app. Such communication without requiring both apps to be active wouldn't hurt battery life or performance much, and might be better than the user flipping between apps manually now. But it would still be a clumsy way for apps to communicate, unlike the Apple Event system built into the Mac OS that enables applications to communicate with one another.

Apple Events can work only if the destination app is running, however, so it's much harder to imagine a similar system in the iPhone OS, given its significantly more limited CPU and RAM resources. I wouldn't expect to see this in the near future.

Of course, the other way to transfer arbitrary data from app to app is via copy and paste, a recent addition to the iPhone OS. Copy and paste solves many problems, but is entirely user-driven, unlike the URL approach or Apple Events on the Mac.

Quick Task Switching with Saved State -- The first glimpse of multitasking in the Mac OS came with Andy Hertzfeld's Switcher (from 1985), an application that almost made it possible to run two applications simultaneously, although under the hood it merely enabled switching between applications without quitting one and launching the other. Switcher was supplanted by MultiFinder in System 5 before System 7 made it a standard part of the operating system.

We've gone backwards with the iPhone OS, which forces you to stop using one app (by pressing the Home button) before you can launch another (by tapping its icon on a home screen). It does so for two main reasons: consistency of user experience and to eliminate the RAM and CPU requirements necessary for keeping two apps active at the same time. Luckily, quitting and launching are generally quick, which is why Apple has been able to get away with it so far.

Still, it's frustrating to be forced back to the home screen constantly (especially for those of us who have lots of home screens to hold many apps), and Apple has even implicitly acknowledged that by providing a single shortcut action - a double press of the Home button - that you can set to display the first home screen, the search screen, the Phone Favorites screen, the Camera app, or the iPod app. And even the fact that Apple allows four apps to be docked and thus appear on all home screens shows that they recognize users want to move among some apps more fluidly than others.

I'd suggest that two changes are necessary to meet most of the needs of quick task switching. First, the iPhone OS needs a faster way to switch between user-selected or recently used apps - the display of a shortcut screen could even be tied to a double or triple press of the Home button. Second, both the iPhone OS and individual apps need to work harder at saving the user's state, so every launch doesn't involve starting from scratch. It's not impossible; our TidBITS News app does it, so if you're reading an article when you leave the app, the app puts you right back where you were when you next launch it. Perhaps the iPhone OS could "freeze" the state of apps automatically, if developers so wished, without having to do extra work.

Neither of these suggestions requires apps to be active simultaneously, and should thus be the sort of thing Apple would consider in a future version of the iPhone OS.

Simultaneous Execution -- Here we come to the real nut of the problem - true simultaneous execution. But even here there are two actual scenarios: apps like iPod that need to run in the background, but which don't need to take up any (or hardly any) visible space in the interface, and the future possibility of multiple apps running side-by-side on an iPad.

Obviously, this first scenario is possible with the iPhone OS because the iPod app does it, so it should be possible for other apps like the Pandora music app or a GPS tracker app to do so as well.

Here's where we come back to Apple's claims that allowing background apps would hurt performance and battery life. Let's say you're playing a game on your iPhone, and it's taking most of the available CPU cycles. Running another app at the same time, like iPod, isn't going to hurt battery life significantly because all the CPU cycles are already in use, so if the game would have drained the battery in an hour, the game plus iPod would do so only slightly more quickly.

However, let's assume you're not using a game, and whatever app is active is using relatively few CPU cycles. In that case, adding another process like iPod would increase overall CPU usage and would undoubtedly drain the battery more quickly. That's not ideal, but it seems like the sort of thing that should be a user decision - much as Apple warns that fetching new data more frequently drains the battery more quickly.

A more serious problem revolves around performance. Let's say you're a passenger in a car, and you want to play a game, listen to iPod in the background, and have a GPS app tracking your location and speed, all while new messages are pushed to Mail. Now the iPhone's CPU would have to share cycles among all the apps, and if it did so poorly, performance in the game might drop below acceptable levels. Tweaking how much CPU time to give to background tasks while keeping the foreground task responsive is a black art in all operating systems. And that assumes the iPhone's CPU is even up to the task at all - it may simply not have the power to keep the frontmost app responsive under the load of multiple apps. And that, I believe, is anathema to Apple - the magic of the iPhone OS's direct manipulation interface is that it's so responsive that it seems natural. Introduce lag or stuttering, and the illusion would fail.

Thus, the only way I can see Apple allowing background apps is if it could in some way limit the portion of CPU cycles an app was allowed to use in the background, and the app would have to accept only occasional cycles if other things were going on. It's not inconceivable, but it feels like a hard problem that Apple is unlikely to solve soon.

A more serious problem may revolve around RAM limitations. Apple stays very quiet about how much is in each iPhone OS device, and it's entirely possible that there isn't enough for multiple simultaneous apps whose RAM requirements Apple doesn't control. Tweaking how much CPU time to allot to background apps may be difficult, but it's doable. Relying heavily on virtual memory (particularly if it's backed by relatively slow flash memory) instead of physical RAM could drastically hurt performance.

The second simultaneous execution scenario is more speculative, put possibly more easily answered. The iPad screen is large enough to display two (or even four, for that matter) classic iPhone apps simultaneously. Even with iPad-savvy apps, it would seem likely that if they were made to be resolution independent or could switch down to an iPhone-sized display when sharing a portion of the screen, it would be reasonable to run two side-by-side, with both being active at the same time. And, if the iPad's A4 processor is sufficiently fast and there's sufficient RAM, perhaps there would be enough resources to do that.

Here's where we start to move into the world of the Mac, because it's entirely commonplace to have two applications visible at the same time (and it's nearly impossible to avoid for those of us who prefer to work on dual-display systems). I constantly refer to a Web page while I'm writing an email message in Mailplane or working on an article in BBEdit. And if someone sends me email asking to schedule a meeting at Macworld Expo, I can show my calendar in BusyCal without obscuring the message or its reply. That's huge, and makes me more productive than I would be if I had to switch between them with Command-Tab. And the equivalent task on an iPhone OS device would be even worse, requiring me to quit Mail, launch Calendar, figure out what times I have available, quit Calendar, launch Mail, find the right message again, reply to it, and then try to remember which times were available.

Although allowing multiple apps to run side-by-side on an iPad seems like a stretch for Apple (I can imagine an interface a little like iPhoto's photo comparison approach), it would be a boon for anyone trying to use the iPad instead of a Mac for a lot of tasks that require visual access to data in multiple apps.

The main advantage this scenario has over the previous one, where the secondary apps are executing but not taking up interface space, is that with side-by-side apps, it may not be necessary that one continue processing while the other is active. The calendar could become essentially frozen in place while I'm replying to my email message, and activate only when I tap on it to switch to the next month, at which point the email app would freeze until I tapped back on it. That approach could address the performance problem, since only one app would actually be using CPU cycles at a time.

Putting It All Together -- Let's see where we are, now that we've broken down "the iPhone should have multitasking" into its component parts. Some are here today in only Apple's apps, others are purely speculative.

• Push Notification: It's here today, and while it's possible Apple will tweak it slightly in the future, it does what it needs to do in terms of reporting external changes, and people generally like it. Notification of scheduled events from iPhone applications which aren't active is currently restricted to Apple's apps, but doesn't seem as though it would be hard to open up.
• Background State Updates: Apple currently reserves this form of multitasking for a few of its own apps, but I see no reason it couldn't be opened up to developers, assuming a few restrictions to avoid abuse that could impact performance or battery life.
• Inter-application Communication: Some forms of inter-application communication are possible on the iPhone OS now (sending URLs from app to app, and copy and paste), but they're quite limited. Apple could enhance URL-based communication quite significantly without too much difficulty, but I don't expect an Apple Events-like system to appear on the iPhone any time soon, and I doubt it's worth asking for.
• Quick Task Switching with Saved State: The iPhone OS would need some interface changes to enable this, but most of the responsibility lies with apps to save their state and restore it as quickly as possible. In the meantime, I think it's worth agitating with Apple for some app-switching shortcuts and perhaps OS-level support for freezing state.
• Simultaneous Execution, Background Apps: Although this is here today, at least with the iPod app and some of Apple's other apps, I don't expect Apple to provide this more generally soon, since ensuring that the frontmost app's responsiveness doesn't suffer is paramount to the iPhone user experience. You can ask all you want, but it's going to be a while (or a more-capable device) before we see it.
• Simultaneous Execution: Side-by-Side Apps: I doubt we'll see this in the initial release of the iPad, but if enough people start using the iPad for real work, where you need to see two apps at the same time, it could become a priority for Apple to add. It's worth requesting, but may appear only in a task-switching context until the hardware can handle it.

As always, the best (and only) way to submit feedback to Apple is via the Product Feedback page. The iPad isn't yet there, but I'd suggest making your wishes known for the iPhone or iPod touch, whichever you currently own.

And of course, tell us what you think in the comments!