Inside iPhone OS 4.0: Multitasking vs Mac OS X, Android

In order to actually do things in the background, Android apps must supply a "service" component, which spins off tasks that can continue even when the associated app is suspended. An Android service uses a client/server model to perform background tasks such as music playback or polling a server for new messages.

It's often these background services that are most likely to eat up battery life on Android phones, because they can open network connections to a remote server and keep those connections open. This forces the 3G or WiFi radio to remain constantly active, which is one of the fastest ways to drain the battery on a mobile device.

An Android service can also activate GPS to obtain regular location updates. This can be even more expensive in terms of battery life, as GPS exercises both the mobile network and the GPS antenna (as mobile signals are used to assist in the task of GPS tracking). Services can also eat up available RAM and consume CPU, but battery life is usually the primary problem.

Multitasking in iPhone 4.0 vs. Android

Apple was certainly aware of how Google had designed Android's multitasking model, and there's no evidence that Google patented the concept of services in its publicly documented, open source operating system. So the fact that Apple didn't clone Google's entire model for multitasking indicates that Steve Jobs wasn't just blowing hot air when he said Apple had studied the problem and devised its own approach to multitasking that it believed to be better.

At the same time, some aspects of Apple's new multitasking APIs are very similar in approach to Android's. According to an overview of the differences in Android and iPhone 4.0 by David Quintana, the "apparent multitasking" of iPhone 4.0, which Apple calls "Fast App Switching," is nearly identical to Android's app suspending concept described above.

When you switch from one app to another in iPhone 4.0, the previous app is held in memory but all activity is frozen. As noted earlier, this isn't really multitasking in the sense of desktop OS multitasking, but rather just an illusion that multiple apps are all running, when they're really not. They're just ready to run again as soon as you switch back: hence the name Fast App Switching.

Before Apple announced this mechanism, many iPhone programmers had expressed the idea that the system didn't really need "multitasking" as much as a "saved state" concept that would allow users to rapidly switch between apps. That's exactly what Fast App Switching does.

Just as with Android, iPhone 4.0 can reclaim memory by saving and then terminating apps that are frozen in the background, so when the user returns, the app can be reopened to the same place it was when the user quit. However, unlike Android, iPhone 4.0 presents a simple way to expressly quit a running app without needing a process management utility like TasKiller.

Because hitting the Home button no longer exits the app, Apple has now made a touch and hold shortcut that presents a red minus badge on running apps that can be used to quit them and remove them from the task tray of running apps, just like the Home button used to do. There's no manual management of apps and systems processes that could result in unanticipated problems for users.

Incidentally, this type of "apparent multitasking" is also what Microsoft plans to use in Windows Phone 7 at the end of the year. And once again for emphasis: this aspect of multitasking isn't really about running multiple apps at once as occurs in a desktop environment, it's about leaving them in memory so you can quickly switch between them.

More Efficient Multitasking in iPhone 4.0

Going beyond the apparent multitasking of Windows Phone 7, iPhone 4.0 will also support a specific set of tasks in third party apps that users will actually want to continue in the background after they leave an app. This is conceptually similar to Android's services, but is implemented in a new way. As Quintana writes, on iPhone 4.0 "background processing is however vastly different than Android."

A primary difference, Quintana notes, is that there is no concept of services in iPhone 4.0. Apps don't provide a background client/server component. Instead, Apple developed a set of rules that apps must follow in order to continue doing tasks after the user switches away from the app.

The idea of apps continuing to work after the user switches away is not new to the iPhone; it's only new to third party apps. Apple's Phone app already does this, as the company has long touted in its ads. With a call in progress, the user can hit the Home button and browse the web or look up a contact or check email while the Phone app remains on the call.

The same thing happens with the iPod app, which can continue to play music. SMS and Mail continue to get messages in the background and so on. However, this would quickly become a problem for users if all of the scores of apps they installed were all consuming resources without restriction as they checked for messages and streamed updates and continued other operations in the background.

In order to balance users' desires to do multiple things at once against users' expectations that their phone would work responsively for a reasonably long period of time, Apple defined a number of background tasks that third parties can implement, and set up rules that ensure these tasks are performed as efficiently as possible.

System-Wide Notifications as a Prerequisite for Efficient Multitasking

The first step down this path was delivered last year: Push Notifications. Rather than having apps sit in the background or spawning background services to poll remote servers for updates, Apple created a system wide service to efficiently listen for updates on behalf of the user's apps, and then present the user with notifications that the user then can act on (when convenient) by launching or switching to the app that has received the notification.

This is something other platforms don't really have in place. Even RIM's Blackberry, which is hailed for its push messaging savvy, has only recently opened up a public push messaging facility for third party apps. The result of this is that most Blackberry apps have already been designed to inefficiently poll their server for updates because unregulated multitasking was already there to allow them to do it "the wrong way." Users pay with shorter battery life.

Android apps similarly cause problems for users' battery life because they're each polling in the background rather than allowing a unified system thread to watch for updates while the individual apps all remain asleep. Apple's Push Notification feature therefore thoughtfully solved a complex problem before multitasking for third party apps was even attempted on the platform.

With iPhone 4.0, there's a second type of system level notification being added: Local Notifications. This mechanism allows apps to set reminders on a schedule that the system handles for them. Rather than being events that are pushed from an external server, they're set up by an app while it's awake, and then held and delivered on time by the system while the app sleeps.

An example might be an app that sets a reminder of a live webcast; the app doesn't need to remain in the background counting down to the notification; the system accepts the reminder and delivers it to the user at the set time on behalf of the app while the app itself goes to sleep.

On page 3 of 3: Getting things done in the background, reasons for multitasking differently.

The key missing component for background processing in iPhone OS 4 is time line based applications, like IM and twitter. These can run in the background on an Android phone and can nicely stack up new messages until the user wants to read them. iPhone OS 4, bizarrely, can't do this (surely the popularity of Twitter can't have escaped Jobs and co), and requires the twitter/IM client to log in anew and refresh each time the user wants to see all the new messages. The push notification system is totally usless in this case (and in most cases to be frank).

I also think Apple are behind on glanceable information/widgets. Wouldn't it be nice to be able to have some widgets on the home page?

I'm all for saving the battery but I'm also all for choice, and it should be my choice if I want to run IM/twitter in the background, not Steve's.

Oh, man, this is just a bad article. Regret the time spent reading it.

If there is one part of the article I can't disagree more it is this sentence : "Apple ... own approach to multitasking that it believed to be better" Who believe this ? You ? Why ? Because Divine Steve at his speech said so ? Ridiculous. You threw no arguments to support this.

Let's get the facts straight :

1, Apple was late to the game, and it mostly copied the Android approach. They might call it differently, but the Apple's multitasking is not any advanced to the one in the Android.It is just copycat work not to be too far behind.

2, There is no client-server model in Android multitasking. It is not any more difficult to do efficient background tasks on Android than with iPhone OS 4. You just don't understand the idea, that's all.

3, Android still maintains the technological lead in the multitasking. There are some areas that weren't copied by Apple (yet), such as broadcasting the system-wide events (not the same as local notifications, although it might be extended this way in iPhone OS 5). This kind of background processing can actually help to save battery life (you do you background networking at the time some other process established - battery expensive - data connection, so you can post your tiny bit of data needed to send to remote server with almost no energy penalty. This is not copied to iPhone, i.e. iPhone is still technologically behind Android in the area of multitasking. This is reason you can't say iPhone is best multitasking mobile implementation, it is just a lie.

4, Apple was overtaken and still plays catchup game. By the time iPhone OS 4 gets to the real users, Android will probably have version 3 released (believed to be announced on Google IO in late May). The the gap, narrowed by iPhone OS 4 will widen again.

One quick question : are you actually paid by Apple to do this kind of marketing for them or goes this from your fanboy nature ?

It's often these background services that are most likely to eat up battery life on Android phones, because they can open network connections to a remote server and keep those connections open. This forces the 3G or WiFi radio to remain constantly active, which is one of the fastest ways to drain the battery on a mobile device.

Even if Apple doesn't support all the features of their multitasking model on the earlier iPhone 3G and 2nd gen Touch, I wonder if they'll support the parts that are not CPU, RAM or battery life intensive. I'm specifically thinking about Local Notifications and the save state model used in Fast App Switching. In the case of Local Notifications, it's just an expansion of existing Push Notifications so there really isn't any hardware limitation concern and the ability to have reminders is a small touch that can be very useful. For the save state model, I'm not talking about implementing actual Fast App Switching, but simply that apps on the iPhone 3G and 2nd gen Touch can save their state on quit so they can be in the same place when they are opened again. Many apps already do this, but it would definitely be better if this abilities is wider used, particularly in games, and is common between 2nd gen devices and newer devices that do support multitasking so that there is more code commonality.

And in regards Section 3.3.1, the way it's worded to require apps be originally written in C languages makes it seem that it's more than enforcing the use of the Clang front-end. Game development often use dedicated IDEs since XCode and Visual Studio weren't primarily designed to make games and was as use other languages for scripting. If it was primarily about the use of Clang, the legal language would only require that apps eventually come in a C language for input into XCode and it's compilers and not require they originally be written in C associated languages which have the potential to exclude game IDEs like Unity. If Apple is really out to completely restrict the use of third-party IDEs like Unity or the much publicized Unreal Engine with it's Unreal Editor and UnrealScript, then they are simply making things more difficult for developers to support the iPhone OS, which goes against the original goals of the iPhone SDK and App Store which was supposed to make things easier for developers to reach mobile customers.

While I think that Apple's multitasking in 4.0 is a very good approach, there is still the issue of the lack of managing modal popup windows. iPhone 3.0 made them unpleasant with push notifications and it looks like 4.0 only will continue down that path as it seems they are relied on more so with local push.

I was very underwhelmed by the lack of any development in this area of the operating system for 4.0 and hope that they just didn't have it ready for the demo. Lacking a good centralized notification app (a la Android's window shade or WebOS's notification area) is a serious issue with the current (and apparently future) operating systems on offer.

The key missing component for background processing in iPhone OS 4 is time line based applications, like IM and twitter. These can run in the background on an Android phone and can nicely stack up new messages until the user wants to read them. iPhone OS 4, bizarrely, can't do this .........

I am not a tech guy, so please explain this to me. The AI article says:

"To accommodate this type of multitasking in iPhone 4.0, Apple added the Task Completion API, a feature that enables app developers to design their app so that it can request a specific amount of time to continue a task after the app is supposed to be put to sleep in the background. Once the app finishes its task or its requested time period expires, the system suspends the app as usual."

So, why can't the IM/Twitter apps request the time they need to continue the task(s)?