Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking
Apple's new iPhone 4.0 SDK license now blocks cross-compiled third party apps, such as those built from Flash CS5. Rather than being just a competitive blow directed at Adobe however, it appears the real motivation is to support sophisticated new multitasking features in the new operating system.
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.
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.
Comments
Huh. I guess Apple may be late to the game, but the best player nonetheless.
?To the extent new releases of operating systems or other third-party products, platforms or devices, such as the Apple iPhone or iPad, make it more difficult for our products to perform, and our customers are persuaded to use alternative technologies, our business could be harmed,? Adobe said today in the filing with the U.S. Securities and Exchange Commission under a ?risk factors? heading.
I guess Steve has their attention.
Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.
Huh. I guess Apple may be late to the game, but the best player nonetheless.
Agreed, better wait till you get something right. The new 4.0 looks awesome. Can't wait for the same abilities on iPad too. I was surprised Steve didn't mention that the iPad would also receive the same new features soon. I have to assume it will though.
At least Flash developers were warned before they shelled out the benjamins on a CS5 upgrade next Monday.
OMG that's a good point - this news will stop a hell of a lot of people upgrading if that was their interest and I suspect it was certainly right up there among the reasons to upgrade (although the new PS looks fun).
It's a business decision, not a technical one.
Especially since I just came from reading outlandish comments in the "Adobe Acknowledges That Apple's Flash Prohibition Could Harm Business" thread.
Check this out too:
http://theflashblog.com/
Now I am not saying that Apple may not have other motives or this is the only reason but this sounds like a good reason to me why Apple is limiting the language being used.
It will come out in the wash if this reason is legit or not. However all these "silly" comments I bet will offer very little apologies if any if this reason turns out to be legit.
OMG that's a good point - this news will stop a hell of a lot of people upgrading if that was their interest and I suspect it was certainly right up there among the reasons to upgrade (although the new PS looks fun).
In the interests of disclosure, I'll be first in line to buy the new 64-bit Photoshop CS5 (as well as Lightroom 3 as soon as the upgrade ships).
Also can someone explain how you quit an App in multitasking environment? I'm sure it has been explained somewhere but I have not seen it yet.
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.
Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?
I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.
Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.
It's a business decision, not a technical one.
Come on!
Daniel Eran Dilger (aka: [email protected]) is the author and you are surprised? that the article seems slanted?
How long have you been around?
Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?
I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.
because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.
Makes sense, but to be fair they really should make a version of iPhone Xcode for Windows. Apple is all too happy to sell Windows users a phone and an iPad, but then not allow them to program for it without buying a Mac. Windows is where Flash CS5 was going to take off with the iPhone export feature.
Then where is Visual Studio for Mac OSX?
Oh well I shouldn't worry about Windows people, they have much bigger problems than no Xcode.
Apple wants applications that have been tailored directly for their platforms... they don't want generic applications that "work" on platforms. So they'll create whatever rules they need to ensure that this happens.
Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?
I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.
I'm not sure I exactly buy the explanation either, which seems to be based entirely on the comments of, "one reader under the name Ktappe."
However, a whole class of apps that, as you say, don't care about implementing multitasking capabilities and don't actually have access to the APIs seems like exactly one of the reasons why Apple would do this.
Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.
It's a business decision, not a technical one.
I’m suspicious too. I don’t know who these mysterious sources are, so what they say has no track record.
If it IS true, then I really hope Apple and Unity can work something out, because a lot of great games will vanish without that kind of middleware! My (not yet released) iPhone/iPad game uses physics and lighting and Unity provides. Without Unity, it will not be released. I can’t afford to hire a team to re-invent what Unity already does so well. (Not that I can even afford all the time and money I have already spent on the game. But it’s a fraction of what it would take without Unity.)
As for Flash, well—that may turn out to be more clear-cut. They bypass Xcode, for instance. Just don’t take down great tools like Unity in the process, and financially ruin some of the creative indie game developers who have helped make the iPhone platform so great! Developers who have always played by the rules—until yesterday the rules changed without warning!