AppleInsider is supported by its audience and may earn commission as an Amazon Associate and affiliate partner on qualifying purchases. These affiliate partnerships do not influence our editorial content.
Reports of the change in Apple's 4.0 license trickled in from a variety of sources, many of them either glad Apple was taking a tough new stance against "Flash shovelware" or alternatively upset that the company was limiting developers to its own development tools and languages.
But if Apple were simply trying to block Adobe from cross-compiling Flash to create iPhone apps, it could have added the changed text to its existing license agreement and spoiled Adobe's CS5 party immediately, rather than just threatening change that appears fated to kick in when Apple delivers iPhone 4.0 in June.
The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.
"[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe.
Multitasking in iPhone 4.0
Apple debuted a series of seven multitasking APIs to enable developers to optimize their apps to run on the new iPhone 4.0, only taking advantage of the resources they actually need.
For example, Fast Switching allows running apps to be effectively frozen in the background so that they don't consume any extra overhead at all. If the user is playing a game and switches to a phone call, there's no need for the game to actually continue playing in the background, and this would usually be undesirable anyway.
On the other hand, Apple also demonstrated APIs that enable background apps to keep working on a necessary job under the name Task Completion. This enables apps that truly need to finish working to do so without making that the default behavior for all apps on the system.
Other new services, such as Background Audio, Voice over IP and Background Location, enable apps to take advantage of special APIs to deliver a particular service they want to offer in the background, leveraging operating system support to do so as efficiently as possible.
Push Notifications and Local Notifications allow apps to go to sleep and leave the operating system on the hook for listening for updates or setting reminders.
Multitasking on other platforms
Other platforms have enabled multitasking by simply allowing any number of apps to run. This results in a mess for users because it's up to them to manage which apps are running out of control or needlessly chewing up resources in the background. Android and Windows Mobile are both notorious for needing TasKiller or some other sort of manual process manager to keep battery life and performance in check.
Microsoft's solution to the mess on Windows Mobile was to start over with Windows Phone 7 this winter, which removes multitasking and attempts to save state for each app it puts on hold. But Microsoft hasn't outlined how it plans to deliver the multitasking features users will expect on its new platform in the way Apple demonstrated for iPhone 4.0 this summer.
Additionally, that fact that Apple introduced its Push Notifications service first means that most iPhone apps are already designed to respond to outside events efficiently. On the BlackBerry OS, for example, apps that run in the background often inefficiently poll their servers, a big tax on battery life. This is somewhat ironic because Blackberry is renowned for running its own push services, it just didn't open these to developers until third party software had largely already rolled their own solutions.