Inside iPhone OS 4.0: Multitasking vs Mac OS X, Android
How you work on a smartphone is very different from how you work on a desktop computer. This reality is particularly true when it comes to multitasking. The approach to multitasking taken by Google's Android and Apple's upcoming iPhone 4.0 is also very different. Here's how they compare.
Desktop Multitasking
On a desktop system running Mac OS X, you don't just want to have multiple apps open and running, each with its own set of open windows. You also want lots of stuff happening in the background, because otherwise your expensive CPU and GPUs are just sitting there idle when they could be doing useful stuff.
Over the last decade of Mac OS X's development, Apple has added lots of new technologies to keep the processors working. The operating system debuted in 2001 with a fancy new compositing graphics engine, which with each new release kept giving the CPU (and later GPUs) additional busy work to do in the background, from shadows to translucency to reflections.
Mac OS X also has Spotlight indexing happening at regular intervals, and throws in automatic file system defragmentation and Time Machine backup change tracking as files are accessed, just to mention a few background features. The faster Macs get, the more extra background tasks the system can throw at the various available processor cores without causing (hopefully) any discernible slowdown for the foreground app.
Many of the new improvements in Snow Leopard were centered around managing how to most efficiently parcel tasks out to the various processor cores available in the system (Grand Central Dispatch) and taking novel advantage of the often idle GPU (OpenCL). The more a desktop operating system does in the background, the richer the experience it can offer.
Mobile Multitasking
When the iPhone appeared and debuted Apple's first mobile variant of Mac OS X, the design goals for the new operating system were turned completely upside down. When a system has to run off its own limited battery, you don't really want it to be doing lots of stuff in the background at all. You really want everything to be idle as much of the time as possible.
Of course, there's still lots that needs to be done, and in many cases, even more to do than a typical desktop. For example, there's a constant need to watch for incoming phone calls or SMS messages. This means the baseband unit has to constantly track the nearest cell tower with an acceptable signal in order to be ready to accept incoming calls or messages.
Power management certainly wasn't an entirely new idea; Apple had been selling notebooks for nearly twenty years, and had created increasingly sophisticated methods for shutting down unnecessary hardware to conserve battery life.
But on a handheld mobile device like the iPhone, there's not just hardware power management to think about. There's also a radically new user interface for working with apps. Apple invested a lot of engineering into deciding how to best deliver a mobile device that balanced features and functionality with acceptable battery life.
Not Multitasking on Purpose
A major design decision of the iPhone was to limit effective multitasking to core system apps, including Phone, SMS, iPod, Clock, and processes that supported these and similar features. When third party apps appeared with iPhone 2.0, there was no provision for running these in the background.
Apple's explanation was that enabling third party apps to run concurrently would simply consume too much battery while presenting potential security problems, and would necessitate providing a manual tool to manage background processes so that they didn't consume all available system resources.
Instead, Apple said it was working on a solution to the primary reason apps would want to run in the background: listening for external updates. Apple's strategy was delivered later than expected as it realized what a huge undertaking this would be, but the resulting Push Notification service enabled iPhone apps to seem responsive to external updates without actually running in the background, constantly polling servers for updates.
There was no technical limitation that kept third party apps from multitasking; the restriction was artificially imposed by Apple to simplify and optimize the performance of its mobile devices. By jailbreaking the iPhone, users can activate unregulated multitasking among third party apps. However, this results in battery life and performance issues the user will need to manage manually.
Apparent Multitasking
Google created multitasking for Android that works very differently than multitasking on a desktop system. In fact, they're so different that its almost confusing that both are referred to using the same word.
On a desktop system, multiple apps all open at once (in addition to background processes) are all able to do work concurrently. As the mouse moves between windows of different apps and clicks on things, events are sent to each app. They're all on and active, although tasks can sit in the background and essentially do nothing, taking up no real processing power and consuming no real memory (thanks to the mechanism of virtual memory) until the user activates them.
On Android, when a user switches from one app to another, the background app is suspended. This is like going into a coma; it's still taking up memory (which is scarce) but can't respond to anything or continue work or begin any new tasks. If the system runs low on memory, it begins saving the state of suspended apps and terminating them.
Terminated apps still appear to be running. When the user jumps to the app, it is relaunched and passed its saved state by the system so that it loads up to look like nothing ever happened and it has been actively running in the background. So far, this isn't really multitasking at all, but rather just a faster way to switch between apps that each run one at a time like the iPhone.
On page 2 of 3: Multitasking in iPhone 4.0 vs Android.
Costly Multitasking with Services
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.
Getting Things Done in the Background
While it's most efficient to have apps sleep, there are a few cases where an app actually needs to do something in the background. The most obvious involves finishing some time-consuming task such as a file upload. Users don't want to be forced to watch a progress indicator, which is what they currently have to do.
Right now, if a user quits a third party app while it's finishing an operation, the operation will fail because the app is forced to quit by the system. Apple's own apps, including Mail and SMS, can continue to send messages after the user appears to have quit the app, but that's because Apple's own bundled apps aren't forced to quit. Other apps are.
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.
Three Special Background Tasks: VoIP, Audio, and Location
There are three other multitasking scenarios Apple supports in iPhone 4.0 which are related to ongoing tasks an app might want to do. This mechanism of granting exceptions to the "one app at a time" model for specific types of apps was anticipated in AppleInsider's earlier coverage of the development of multitasking in the iPhone OS.
The first exception API allows apps to work like the bundled Phone app: being able to accept calls and continue a call while other apps are being used. Only Apple's Phone app can place mobile calls, so this feature is called Voice over IP, as it's designed to support calls placed over an Internet connection using an app like Skype.
In order to make use of this new background VoIP mechanism, an app registers with the system and can then be suspended while the system maintains a network socket listening for incoming VoIP calls. When a call request occurs, the system wakes up the VoIP app and transfers it control of the network connection to service the call.
A second scenario is similar to the built-in iPod app: Background Audio. This allows apps such as Pandora to request the ability to continue playing a music stream even when it is not in the foreground. Apple ties the same background playback controller used for iPod to the app that has requested the use of the new Background Audio facility.
A third scenario for multitasking involves regular location updates. The new Background Location serves two types of apps that use location data: GPS apps that supply driving directions and social networking apps that use the user's location to notify their friends or suggest nearby events.
In the first case, Apple allows apps devoted to driving directions (like TomTom) to remain awake and access GPS in order to provide audible directions even when the app is put into the background. This would normally drain the battery pretty quickly, but most people who are using GPS do so in a car with a kit that supplies constant power.
On the other hand, social networking apps such as Loopt similarly need to know the user's location in order to be useful, but are not typically used in a car kit. If they used GPS, they'd nail the iPhone's battery pretty rapidly just to offer a lightweight service of limited value. In order to support these types of services efficiently, Background Location supplies them with data the phone already gets on a regular basis every time the user moves between mobile cell towers.
This update happens when the user moves between 500 and 1000 meters. When a location change is noted, the system wakes the app, updates its location, provides it with a period of time to process the change, and then suspends it again. This gets around the battery taxing use of GPS while still allowing these types of apps to work without constantly being in the foreground (as is currently the case on the iPhone).
Reasons for Multitasking Differently
In addition to increased efficiency, Apple's approach to regulated multitasking allows for simplified compatibility between devices like the iPhone 3G, which won't support multitasking, and more recent devices that do. Apps that take advantage of the new APIs simply request the ability to do things in the background, so if the hardware doesn't support it the requests are just denied by the operating system.
Google's approach with services requires a new model of client/server components. If Apple had copied that, developers would have to create one set of apps for older devices and an entirely different code base of apps for newer ones, a complex and problematic transition step given that Apple already has a vast library of existing titles in the App Store.
Additionally, much of what developers do with services on Android is already handled by the iPhone OS with Push Notifications. So implementing an Android-like services architecture for iPhone 4.0 would suggest to Android developers wanting to port their apps that they should do so using services rather than the more efficient Push Notifications, creating a problem like the one that exists on the Blackberry, where push features are largely ignored and go unused.
Unified development tools: Clang, LLVM and Xcode
This also all leads to the conclusion that Apple's design for incorporating multitasking features in iPhone 4.0 is all about doing what's best for the iPhone OS platform, rather than trying to create compatibility or similarities with other platforms that do things differently.
It should come as no surprise that Apple is not at all interested in making it easy or simple to port apps between the iPhone OS and other platforms. Doing so would only water down the advantages of the iPhone OS and encourage developers to aim at a lowest common denominator that worked across platforms rather than aspiring to take full advantage of the unique features of the iPhone OS.
This is the same reason why Apple has no interest in supporting Flash or Java as a meta-platform on the iPhone, and also why the company does not want to support third party efforts to create development tools that output iPhone apps. The Flash Professional strategy Adobe hoped to roll out will not offer its users the ability to support iPhone 4.0's multitasking features, Adobe would not be able to rapidly add these features as soon as Apple would like, nor would it necessarily even be in Adobe's interest to add them.
Apple's new prohibition of iPhone 4.0 development in languages other than C, C++ and Objective-C was largely seen as an attack on external development tools like Adobe's Flash CS5. However, observers including Rainer Brockerhoff have since noted that Apple's focus on C languages likely has more to do with the company strategy for optimizing iPhone OS development using Clang.
Clang (short for "C Language") is an open source project Apple funded to serve as a new front end compiler for (unsurprisingly) C, C++ and Objective-C code. Clang connects to LLVM, the Low Level Virtual Machine, which serves as the back end compiler for Apple's Xcode development tool for both Mac OS X and iPhone OS.
The combination of Clang and LLVM effectively replaces GCC (GNU Compiler Collection, the GPL-licensed compiler for Unix-like operating systems). Because Apple's replacement compiler tool chain is licensed under the more permissive BSD license, Apple can integrate it more closely into its Xcode Integrated Development Environment.
Additionally, Clang and LLVM enable Apple to better optimize various steps of the code compiling workflow, creating Mac and iPhone apps that are more efficient, faster, more compact, and easier to debug, due to a variety of optimizations and enhancements that the flexible, modular new compiling tools provide over GCC.
Having invested so much strategic work into Clang and LLVM, it's no wonder Apple is working to push developers to use its own development tools rather than trying to leverage emerging lowest common denominator platforms to deliver iPhone apps that aren't optimized for the iPhone or the latest features of the iPhone OS, including new support for multitasking.
Desktop Multitasking
On a desktop system running Mac OS X, you don't just want to have multiple apps open and running, each with its own set of open windows. You also want lots of stuff happening in the background, because otherwise your expensive CPU and GPUs are just sitting there idle when they could be doing useful stuff.
Over the last decade of Mac OS X's development, Apple has added lots of new technologies to keep the processors working. The operating system debuted in 2001 with a fancy new compositing graphics engine, which with each new release kept giving the CPU (and later GPUs) additional busy work to do in the background, from shadows to translucency to reflections.
Mac OS X also has Spotlight indexing happening at regular intervals, and throws in automatic file system defragmentation and Time Machine backup change tracking as files are accessed, just to mention a few background features. The faster Macs get, the more extra background tasks the system can throw at the various available processor cores without causing (hopefully) any discernible slowdown for the foreground app.
Many of the new improvements in Snow Leopard were centered around managing how to most efficiently parcel tasks out to the various processor cores available in the system (Grand Central Dispatch) and taking novel advantage of the often idle GPU (OpenCL). The more a desktop operating system does in the background, the richer the experience it can offer.
Mobile Multitasking
When the iPhone appeared and debuted Apple's first mobile variant of Mac OS X, the design goals for the new operating system were turned completely upside down. When a system has to run off its own limited battery, you don't really want it to be doing lots of stuff in the background at all. You really want everything to be idle as much of the time as possible.
Of course, there's still lots that needs to be done, and in many cases, even more to do than a typical desktop. For example, there's a constant need to watch for incoming phone calls or SMS messages. This means the baseband unit has to constantly track the nearest cell tower with an acceptable signal in order to be ready to accept incoming calls or messages.
Power management certainly wasn't an entirely new idea; Apple had been selling notebooks for nearly twenty years, and had created increasingly sophisticated methods for shutting down unnecessary hardware to conserve battery life.
But on a handheld mobile device like the iPhone, there's not just hardware power management to think about. There's also a radically new user interface for working with apps. Apple invested a lot of engineering into deciding how to best deliver a mobile device that balanced features and functionality with acceptable battery life.
Not Multitasking on Purpose
A major design decision of the iPhone was to limit effective multitasking to core system apps, including Phone, SMS, iPod, Clock, and processes that supported these and similar features. When third party apps appeared with iPhone 2.0, there was no provision for running these in the background.
Apple's explanation was that enabling third party apps to run concurrently would simply consume too much battery while presenting potential security problems, and would necessitate providing a manual tool to manage background processes so that they didn't consume all available system resources.
Instead, Apple said it was working on a solution to the primary reason apps would want to run in the background: listening for external updates. Apple's strategy was delivered later than expected as it realized what a huge undertaking this would be, but the resulting Push Notification service enabled iPhone apps to seem responsive to external updates without actually running in the background, constantly polling servers for updates.
There was no technical limitation that kept third party apps from multitasking; the restriction was artificially imposed by Apple to simplify and optimize the performance of its mobile devices. By jailbreaking the iPhone, users can activate unregulated multitasking among third party apps. However, this results in battery life and performance issues the user will need to manage manually.
Apparent Multitasking
Google created multitasking for Android that works very differently than multitasking on a desktop system. In fact, they're so different that its almost confusing that both are referred to using the same word.
On a desktop system, multiple apps all open at once (in addition to background processes) are all able to do work concurrently. As the mouse moves between windows of different apps and clicks on things, events are sent to each app. They're all on and active, although tasks can sit in the background and essentially do nothing, taking up no real processing power and consuming no real memory (thanks to the mechanism of virtual memory) until the user activates them.
On Android, when a user switches from one app to another, the background app is suspended. This is like going into a coma; it's still taking up memory (which is scarce) but can't respond to anything or continue work or begin any new tasks. If the system runs low on memory, it begins saving the state of suspended apps and terminating them.
Terminated apps still appear to be running. When the user jumps to the app, it is relaunched and passed its saved state by the system so that it loads up to look like nothing ever happened and it has been actively running in the background. So far, this isn't really multitasking at all, but rather just a faster way to switch between apps that each run one at a time like the iPhone.
On page 2 of 3: Multitasking in iPhone 4.0 vs Android.
Costly Multitasking with Services
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.
Getting Things Done in the Background
While it's most efficient to have apps sleep, there are a few cases where an app actually needs to do something in the background. The most obvious involves finishing some time-consuming task such as a file upload. Users don't want to be forced to watch a progress indicator, which is what they currently have to do.
Right now, if a user quits a third party app while it's finishing an operation, the operation will fail because the app is forced to quit by the system. Apple's own apps, including Mail and SMS, can continue to send messages after the user appears to have quit the app, but that's because Apple's own bundled apps aren't forced to quit. Other apps are.
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.
Three Special Background Tasks: VoIP, Audio, and Location
There are three other multitasking scenarios Apple supports in iPhone 4.0 which are related to ongoing tasks an app might want to do. This mechanism of granting exceptions to the "one app at a time" model for specific types of apps was anticipated in AppleInsider's earlier coverage of the development of multitasking in the iPhone OS.
The first exception API allows apps to work like the bundled Phone app: being able to accept calls and continue a call while other apps are being used. Only Apple's Phone app can place mobile calls, so this feature is called Voice over IP, as it's designed to support calls placed over an Internet connection using an app like Skype.
In order to make use of this new background VoIP mechanism, an app registers with the system and can then be suspended while the system maintains a network socket listening for incoming VoIP calls. When a call request occurs, the system wakes up the VoIP app and transfers it control of the network connection to service the call.
A second scenario is similar to the built-in iPod app: Background Audio. This allows apps such as Pandora to request the ability to continue playing a music stream even when it is not in the foreground. Apple ties the same background playback controller used for iPod to the app that has requested the use of the new Background Audio facility.
A third scenario for multitasking involves regular location updates. The new Background Location serves two types of apps that use location data: GPS apps that supply driving directions and social networking apps that use the user's location to notify their friends or suggest nearby events.
In the first case, Apple allows apps devoted to driving directions (like TomTom) to remain awake and access GPS in order to provide audible directions even when the app is put into the background. This would normally drain the battery pretty quickly, but most people who are using GPS do so in a car with a kit that supplies constant power.
On the other hand, social networking apps such as Loopt similarly need to know the user's location in order to be useful, but are not typically used in a car kit. If they used GPS, they'd nail the iPhone's battery pretty rapidly just to offer a lightweight service of limited value. In order to support these types of services efficiently, Background Location supplies them with data the phone already gets on a regular basis every time the user moves between mobile cell towers.
This update happens when the user moves between 500 and 1000 meters. When a location change is noted, the system wakes the app, updates its location, provides it with a period of time to process the change, and then suspends it again. This gets around the battery taxing use of GPS while still allowing these types of apps to work without constantly being in the foreground (as is currently the case on the iPhone).
Reasons for Multitasking Differently
In addition to increased efficiency, Apple's approach to regulated multitasking allows for simplified compatibility between devices like the iPhone 3G, which won't support multitasking, and more recent devices that do. Apps that take advantage of the new APIs simply request the ability to do things in the background, so if the hardware doesn't support it the requests are just denied by the operating system.
Google's approach with services requires a new model of client/server components. If Apple had copied that, developers would have to create one set of apps for older devices and an entirely different code base of apps for newer ones, a complex and problematic transition step given that Apple already has a vast library of existing titles in the App Store.
Additionally, much of what developers do with services on Android is already handled by the iPhone OS with Push Notifications. So implementing an Android-like services architecture for iPhone 4.0 would suggest to Android developers wanting to port their apps that they should do so using services rather than the more efficient Push Notifications, creating a problem like the one that exists on the Blackberry, where push features are largely ignored and go unused.
Unified development tools: Clang, LLVM and Xcode
This also all leads to the conclusion that Apple's design for incorporating multitasking features in iPhone 4.0 is all about doing what's best for the iPhone OS platform, rather than trying to create compatibility or similarities with other platforms that do things differently.
It should come as no surprise that Apple is not at all interested in making it easy or simple to port apps between the iPhone OS and other platforms. Doing so would only water down the advantages of the iPhone OS and encourage developers to aim at a lowest common denominator that worked across platforms rather than aspiring to take full advantage of the unique features of the iPhone OS.
This is the same reason why Apple has no interest in supporting Flash or Java as a meta-platform on the iPhone, and also why the company does not want to support third party efforts to create development tools that output iPhone apps. The Flash Professional strategy Adobe hoped to roll out will not offer its users the ability to support iPhone 4.0's multitasking features, Adobe would not be able to rapidly add these features as soon as Apple would like, nor would it necessarily even be in Adobe's interest to add them.
Apple's new prohibition of iPhone 4.0 development in languages other than C, C++ and Objective-C was largely seen as an attack on external development tools like Adobe's Flash CS5. However, observers including Rainer Brockerhoff have since noted that Apple's focus on C languages likely has more to do with the company strategy for optimizing iPhone OS development using Clang.
Clang (short for "C Language") is an open source project Apple funded to serve as a new front end compiler for (unsurprisingly) C, C++ and Objective-C code. Clang connects to LLVM, the Low Level Virtual Machine, which serves as the back end compiler for Apple's Xcode development tool for both Mac OS X and iPhone OS.
The combination of Clang and LLVM effectively replaces GCC (GNU Compiler Collection, the GPL-licensed compiler for Unix-like operating systems). Because Apple's replacement compiler tool chain is licensed under the more permissive BSD license, Apple can integrate it more closely into its Xcode Integrated Development Environment.
Additionally, Clang and LLVM enable Apple to better optimize various steps of the code compiling workflow, creating Mac and iPhone apps that are more efficient, faster, more compact, and easier to debug, due to a variety of optimizations and enhancements that the flexible, modular new compiling tools provide over GCC.
Having invested so much strategic work into Clang and LLVM, it's no wonder Apple is working to push developers to use its own development tools rather than trying to leverage emerging lowest common denominator platforms to deliver iPhone apps that aren't optimized for the iPhone or the latest features of the iPhone OS, including new support for multitasking.
Comments
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.
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.
Open != active. An open connection consumes virtually zero power.
Go re-read your GSM specs. Wireless data connections were designed to remain open.
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.
One quick question : are you actually paid by Apple to do this kind of marketing for them or goes this from your fanboy nature ?
I realize you're trying to be sarcastic, but take a guess.
Then, take a hike.
Open != active. An open connection consumes virtually zero power.
Go re-read your GSM specs. Wireless data connections were designed to remain open.
It's not a matter of keeping them open, it's a matter of constantly polling for updates. So your comment appears to be a quibble.
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)?
So, why can't the IM/Twitter apps request the time they need to continue the task(s)?
Because "stay online polling the network waiting for a message for a long time" is not a "Task" in Apple's sense of the word. It's very wasteful.
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.
Well, Brainless, if you read the article it's pretty clear that it's saying Apple believed its implementation to be better. It is jumping to that conclusion, nor is there any need to argue to support this. It's a statement of opinion clearly attributed to Apple.
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.
No, you are factually wrong. There are some similarities, but the implementation is very different, as multiple sources have noted (including ones cited in the article!).
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.
Again, you are factually wrong. Android's own documentation shows you don't know what you are talking about. Services are implemented as a client/server component in apps.
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.
You provide no sources, and say nothing but opinion. You haven't exactly established yourself as a worthy source of information. So maybe link to somebody of some import who can back up your assertions.
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.
Google released its OS just a few months after Apple's 1.0. So if there's any catch up going on, it's Android being on 2.1 (or 1.5 if you have a phone that ships with that, and good luck ever getting updated) while Apple is delivering its 3.2, or perhaps Apple's 25% market share compared to 9% for Android. Who is playing catch up?
One quick question : are you actually paid by Apple to do this kind of marketing for them or goes this from your fanboy nature ?
One might say the same to you about Android, but your presentation is so badly askew of the facts and full of bluster and unsupported opinion that it's hard to suggest anyone would be paying you to throw it into comments. You sound like a Zune fan.
Because "stay online polling the network waiting for a message for a long time" is not a "Task" in Apple's sense of the word. It's very wasteful.
So, will, and if so how will my, say, Gmail account be able to do it? Are you suggesting it won't multitask either?
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.
Personally, I don't see a problem with Twitter and IM updates. I get Push Notifications that there are new messages and when I jump back to Beejive or Tweetie2 it's all there within a moment. Fast App Switching will make this even faster. All they have to do is add part of the Location API that activates Loopt, per the article's example, which then updates before suspending itself again. Having all these social apps running 24/7 when they update their small amount of text data almost instantly after activating the app doesn't make any sense to me.
The push notification system is totally usless in this case (and in most cases to be frank).
If it's totally useless in most cases then why has been adopted by all major mobile OSes despite the fact they have had unencumbered multitasking for some time? Clearly it's been a success on many levels, especially when it comes to IM apps.
II 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?[
That would be nice to have widget apps on the Lockscreen but I think a much more pressing need than that (or multitasking) is a robust system notification app with a running history. The current Popover only shows text from one item, and if it's too long even that gets cut off. If it pops up while you are working and hit Cancel or Ok without reading it you then have to hunt for what app it came from and what message it was. Android does this pretty well and WebOS does a great job here. If any iPhone user has an issue with iPhone OS v4.0 I think that is much more important that being able to run a full Twitter app in the background constantly.
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.
It's Apple's product, not yours. This is a free market and they can make their products work the way they want to support their customers. If it doesn't fit your needs you can jailbreak it, by a different phone, not buy anything or compete with them if you think there is an opportunity in the market between Android and iPhone OS.
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 :
Just by the fact alone that you need a task killing app means that multitasking wasn't done properly. These are things needed to be handled by the OS. Because of this inefficiency, it offsets any battery saving features (and then some) that Android may provide.
As to your belief that Apple was late to the game I agree. It should have been introduced with the 3GS but I'm sure Apple was concerned about 3G users being one year into their contracts and not being able to handle multitasking. This is unlike Android where they allowed on the G1 and subsequent phones even though there wasn't enough RAM which made for a lousy experience.
The only features I see missing in 4.0 was:
1. A central PNS app/gesture swipe to find notifications you missed. Hopefully it will be addressed before it's released.
2. A nicer animation to the multitasking interface. I would have loved to see an animation like Exposè as on the Mac. This seems a little more sloppy but I can understand because the iPhone may be dealing with limited resources.
3. Stop the PNS from taking over my whole screen. It gets annoying to be in the middle of something and have to deal with the notification first instead of whatever I may be doing. Hopefully this is fixed as well.
From Zigurd
Android has four kinds of components: Activity, Service, ContentProvider, and BroadcastReceiver. An app can have one or more types of components. If an Activity is visible or a Service is running, the task is not going to be killed unless memory is very low. This should not be a common occurance.
If an app does not have a Service component that is running, and none of the Activity components are visible, it can be killed and restarted from saved state. The Application Fundamentals article explains the Activity lifecycle. This is a common occurance.
From the descriptions here, it sounds like iPhone multitasking is more like a simplified form of Android's lifecycle for apps with Activity components, and that has some special cases that behave like Android Service components.
In Android parlance, a "background process" isn't visible, nor is it running a Service component. It can be killed to claw back resources. A "service process" is not visible, but it does have a Service component that has been started and can be running.
As far as IM or Twitter I don't really need constant background refreshes on Twitter. Tweetie refreshes fast enough for me to be happy. IM doesn't really present itself well as a background app. The function of IM is communicating with someone unless you are chatting with a very slow typist.
I think Apple and Android, at this point, have covered Multitasking well. I frankly don't think it's as important as some make it out to be.
One might say the same to you about Android, but your presentation is so badly askew of the facts and full of bluster and unsupported opinion that it's hard to suggest anyone would be paying you to throw it into comments. You sound like a Zune fan.
It's an opinion. Off the top of my head, no more 'right' or 'wrong' than yours. I'd love to see your opinions expressed in some way other than a rant of anger and ridicule. Share your knowledge. Help others understand. Take the time to persuade.Shouting at the top of your lungs about how crazy someone else is...well...
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 ?
Being first to jump into the water then getting sconed by a rock shouldn't make you the envy of everyone, it should make them realise that they were lucky not to have gone in first.
Apple sat down and thought about the best way to solve the problem. They then realised the problem was multi-faceted then designed solutions accordingly. When it comes to multi-tasking one size does not fit all.
Apple has taken the logical engineering solution as opposed to the marketing solution of ship it then sort it out later.
As such Apple's way IS better.
As far as IM or Twitter I don't really need constant background refreshes on Twitter. Tweetie refreshes fast enough for me to be happy. IM doesn't really present itself well as a background app. The function of IM is communicating with someone unless you are chatting with a very slow typist.
I think Apple and Android, at this point, have covered Multitasking well. I frankly don't think it's as important as some make it out to be.
One thing I would like to see is support for the "Fast Task Switch UI" on earlier iPhones and iPads... if only to allow the user to rapidly find and restart recently run apps (as opposed to Spotlight search or flipping icon pages). This would refresh the UI and make it consistent across all models.
*
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 ?
I think your handle speaks for itself