Get the Lowest Prices anywhere on Macs, iPads and Apple Watches: Apple Price Guides updated May 24th


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

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.