Is Apple's cross-compiler ban pro-multitasking not anti-Adobe?

Screen shot 2010-04-08 at 10.12.23 PM

While Apple's ban on cross-compilers in the iPhone 4.0 SDK has raised a lot of discussion on the net, and generated some fiery responses from Adobe, AppleInsider claims a source who says the move had nothing to do with Flash CS5 or another other, specific cross-compiler, and everything to do with multitasking performance:

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.

Apple is using a different kind of multitasking than we've seen before in mobile -- saved state combined with API-level services that take the place of running apps. Are Cocoa touch apps generated in Xcode really different enough from Flash or C#/.Net apps cross-compiled by Flash CS5 or MonoTouch to cause Apple's multitasking system problems?

We're not developers, you tell us.

Have something to say about this story? Leave a comment! Need help with something else? Ask in our forums!

Rene Ritchie

EiC of iMore, EP of Mobile Nations, Apple analyst, co-host of Debug, Iterate, Vector, Review, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts



← Previously

Adobe fires back at Apple over cross-compiler ban

Next up →

iPhone 4: Notes Sync for IMAP

Reader comments

Is Apple's cross-compiler ban pro-multitasking not anti-Adobe?


Not sure it's true, but sounds likes valid and reasonable argument. When you look at just programming in general i would say the more layers between you and the 0s and 1s the less efficent it will be.

How you arrive at multitasking is not controlled by the language.
But reference to a library of APIs (Adobe's, not Apple's) that is shared by a number of apps would impose restrictions on a processor's ability to manage them efficiently in a multi-tasking environment, (as well as potentially break the sandbox).
Many compilation environments make use of standard libraries of tiny APIs, because of the huge saving in program size. Something as simple as adding two numbers of different types is often rendered by compilers to an API call.
However, Apple's highly touted Sandbox already prevents this this to a large extent, leaving only Apple's library of APIs available system wide, and your own set of APIs must reside in your own sandbox, not in a shared runtime.
So Adobe shifts gears, emits C/C++ code, (even for its API/Function calls) and Apple can't say a thing about it any more.
This sounds like a security issue more than a multitasking issue, because the sandbox pretty well eliminates and private shared libraries anyway. Apple wants hands on your code. (Well they want their Compiler's "hands" on it anyway). That way it can optimize it for multi-tasking and security issues.
Its a huge step backward in software design, but need not be a death knell for Adobe.

The end result is not a runtime-enabled app. It is an iPhone app, purely. When you compile an Objective-c written iPhone app, it compiles down to a base language. The same happens with the iPhone Packager. They take ActionScript, compile it down to the same base language done with Objective-C, and voila...a faster dev cycle w/ better tooling, IMO. :-) short, no. Multitasking is not the reason at all. I'll never buy that. Adobe will update the iPhone Packager to work with the newest api's soon, I assume, so all of the multitasking goodies will be available. Once that is done, where does that leave the clause? Excessive?

Writen by Daniel Eran Dilger? If so, it's about Flash and not multitasking.
I don't know why anyone reads such a biased and full of hatred blogger

I suggested this to a fellow dev earlier today, and he's not convinced but I still think it's a plausible explanation.
You might think Apple would have pointed this out themselves by now, just to quell the storm, but they're not the most articulate of companies when it comes to talking about stuff that is technically under NDA.

First, are the two different, no. Just because an Apple hack says its different, does not mean it is... Secondly, this is not the first that we've seen this kind of multi tasking in mobile. Microsoft already claimed that title with Windows Phone 7. This is the exact same model that WP7 uses.

Total bs.. It's easy enough to mark a thread with an attribute.. A thread is a thread, no matter what the orginial code base was written on.
Infact it might be easier to manage with something like mono..
Apple is gunning for flash, and does not care who else gets caught in the crossfire..
I don't see what right (morally) they have to force my programming tools - if Microsoft did this, they would be called evil and controlling.

I don't know of any multi-million/billion dollar company who hasn't done anything morally wrong. Stepping on people on your way up the ladder is how most people/companies get ahead in this world.
I'm not saying that it's right, but that's simply the way it is. It's simply Apple doing business as usual.

Generaly agree - does not make it right.
Microsoft tried this with ie - ended up (righfully) in court. Same should happen to apple.

The problem is they are on the top rung already and kicking everyone else off who is attempting to climb up a connected ladder. ;-) Ok...sounded better in my head but basically they aren't climbing the ladder any longer.

@John C.
Well the problem isn't that Apple isn't at the top as far as Flash-like technology. Adobe has been at the top with Flash for the last 15 years. Because Adobe was at the top all by itself with it's own proprietary technology, they didn't feel the need to innovate. It's Adobe's own fault Apple made this power play.
Imagine driving a 15 year old car that has had minor tweaks done to it but basically is the same old car. Then imagine some new kid on the block comes out with a 2010 model that's more efficient and better than that 15 year old car. Flash is that 15 year old car. HTML 5 is the new Ferrari 599 GTO.
You snooze, you loose!

MonoTouch can compile directly to C code that can then be compiled in XCode. I'm skeptical that multitasking is the motivation behind the tos language change--but hopeful if it is. That would mean that 3rd parties (like Novell) could work with Apple to overcome the technical hurdles.

If Apple can deny an app that was created from another source then there has to be something fundamentally different. It must be enough so that under the approval process, they can detect it and reject it. It may be compatible and run perfectly, but its different. From an embedded systems tester's perspective, this opens the door to lots of potential problems. Once an iphone/ipad have enough resources to no be deemed embedded, then I would start to point the shame finger at Apple.

Yes, Apple does seem to have largely copied Andoid's Bundles/Services model, but in a way, worse. On Andoid, applications CAN run in the background, not just certain "tent pole" processes - the iPhone appears to rely exclusively on task switching to simulate this level if multitasking. The iphones's version is undoubtedly less powerful and flexible, but time will tell if that trade-off was sensible.

You're getting your technical advice from Hollywood. This article is totally unfounded in reality.