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.
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.
