Apple Blocks Adobe's Flash-to-iPhone Compiler in Latest SDK Agreement

[c.hilding]

Why the hell would we want low-quality crapware applications (with zero focus on iPhone usability/interface/no multitouch) being literally churned out from low quality flash applications? I am THANKFUL that Apple banned this. The App Store is satured enough with crap as it is.

 

[broken-chaos]

But it doesn't run natively, it runs in an runtime.

As a few others have said, Adobe claims this is not the case. they have stated that it compiles it into a fully-compliant (uses all the proper APIs), fully-native iPhone OS application.

If the Flash-to-iPhone compiler actually converted Flash to Objective-C there wouldn't be a problem.

Almost nothing (aside from research projects, really) does this. Machine-converting one source language into another very different language is very difficult to achieve correctly, and is unnecessary when you can simply compile the original code, achieving an often-better result with less steps.

This is a petty shot at Adobe just before their CS5 release -- nothing less. Apple's getting too sure of themselves, and are going to end up doing something absurdly stupid, in the name of control, if they haven't already.

Edit: By the way, for those criticising Flash applications as 'terrible', this is an example of one built with the pre-release CS5: Canabalt, playable online at Newgrounds, with the Flash browser plugin. So far it has not been used for creating 'crap' (enough of that is created with Obj-C), but has been used for porting popular Flash games to the iPhone -- in some cases, at least, quite successfully.

 

[angrynstupid]

Wise Grasshopper

Smart thing to do if Apple wants to buy Adobe.

 

[ranReloaded]

Everything I've read about this says that the Flash-to-iPhone compiler creates a package which translates Flash script to Cocoa Touch API calls. How could it do anything else, as Cocoa Touch is the only way I know to write iPhone apps (though I suppose you could write your own version of Cocoa Touch -- at great expense, and with serious compatibility risks).

Of course it has to be hooked to Cocoa at some point (otherwise you can't create a window).
But you mean the "translation and hooking to Cocoa" is done at runtime. I thought it was done at compile time (They call it "publish" in the Flash IDE)

If Adobe can do that, then they can generate actual Objective-C code which would call the Cocoa Touch APIs natively and that would compile normally. Code generators are nothing new.

that's what I thought they were doing all along.

Though IMO more than a few Flash developers might need to learn their way around an IDE to get that far.

Start by giving up code embedded into the timeline frames...

If anything, Adobe is probably farther along than anyone else to jumping this hurdle. It just depends how important this exercise is to them (which is more about marketing Flash than anything else).

They aren't doing it for the Mac OS X platform. I mean, CS for the Mac is just a lazy port. From the installer right through the Flash toolbars. Hopefully the iPhone OS bug will bite them strong enough.

 

[Spiritgreywolf]

What if the cross compiler generated source code?

I work with some tools in the healthcare industry where it generates framework code and you take it and run it in the compiler. The source it generates is NATIVE to the platform that runs it.

If what Apple is telling me is that I can't use a tool that generates Objective-C source, and that source opens in XCode and compiles to an iPhone target app, they're on crack.

That makes about as much sense saying I can't write my objective C on paper then type it in to XCode....

 

[ranReloaded]

I work with some tools in the healthcare industry where it generates framework code and you take it and run it in the compiler. The source it generates is NATIVE to the platform that runs it.

If what Apple is telling me is that I can't use a tool that generates Objective-C source, and that source opens in XCode and compiles to an iPhone target app, they're on crack.

That makes about as much sense saying I can't write my objective C on paper then type it in to XCode....

I don't think anyone has the technical means (possibly God?) of telling your source apart from hand-coded Objective-C, not even apple, once it is compiled through Xcode. Rest Assured

 

[John.B]

This isn't even new to people familiar with the previous SDK language.

It dead clear that anyone using alternate frameworks were operating in a gray area at best, because they were operating in violation of even the older SDK wording. This new wording is only a slight variation on what was already present and no actual change in intent.

http://www.appleinsider.com/articles/08/03/11/iphone_sdk_may_block_firefox_java_background_apps.html 2008


"No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and builtin interpreter(s)," Apple says in the agreement. "An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise."

This is nothing more than a clean up of existing language, but in current media frenzy, it is mocked up into another "pro wrestling" style, end of the world drama...

QFT.

I would only add that apparently Adobe went through the mental gymnastics that it took to decide this originally didn't apply to them. So the SDK agreement was updated to remove any possible ambiguity.

 

[ranReloaded]

As a few others have said, Adobe claims this is not the case. they have stated that it compiles it into a fully-compliant (uses all the proper APIs), fully-native iPhone OS application.


Almost nothing (aside from research projects, really) does this. Machine-converting one source language into another very different language is very difficult to achieve correctly, and is unnecessary when you can simply compile the original code, achieving an often-better result with less steps.

This is a petty shot at Adobe just before their CS5 release -- nothing less. Apple's getting too sure of themselves, and are going to end up doing something absurdly stupid, in the name of control, if they haven't already.

Edit: By the way, for those criticising Flash applications as 'terrible', this is an example of one built with the pre-release CS5: Canabalt, playable online at Newgrounds, with the Flash browser plugin. So far it has not been used for creating 'crap' (enough of that is created with Obj-C), but has been used for porting popular Flash games to the iPhone -- in some cases, at least, quite successfully.

I like Cannabalt, it's a pretty simple and retro, yet engaging game. The music is very good too. They ported a (rare) good flash (web) game to the iPhone. But obviously they are the exception. And yes, there ARE crappy native apps (many indeed), but that's another story. Now we are talking Flash

 

[Nuvi]

Why doesn't Apple just buy Adobe, kill flash, and re-write CS5 or 6 so that it becomes a killer mac app for future desktop and touch systems?

Everyone wins, except for windows PC users of course!

Apple Pro app development has been slowing down a lot. Its all about the next iThing not ProThing. Anyway, you never know. if Adobe gets really fed up with Apple they might drop Mac apps all together. I would love to see the look on Jobs face if that happens... and how he goes into insane back pedaling mode trying to save the pro market.

Regarding the actual subject, it really sucks dev with Flash and Unity is not allowed.

 

[Bytor65]

As a few others have said, Adobe claims this is not the case. they have stated that it compiles it into a fully-compliant (uses all the proper APIs), fully-native iPhone OS application.

So you and a few others are ill informed. What else is new?

Here is the new Adobe "native: cross platform solution they demoing (ie the current reversi demo, using AIR):
http://www.engadget.com/2010/04/05/adobe-air-developer-demonstration-one-game-five-platforms-all/

What is AIR?

Adobe Integrated Runtime

It is a Run Time translation Layer to support non native apps. It is exactly like Java + JVM, except the JVM is linked with each app. This wouldn't fly with the old SDK language either.

As pointed out, The prohibitions against Run Time Layers is NOT NEW and not Adobe specific.

In short there is nothing to see here, move along.

 

[cumanzor]

Sounds like someone here isn't familiar with the history of Bill Gates' business practices...

What you are saying is:

"When MS does it, it's a bad thing. When Apple does it, it's good or I just don't care."

Are you seriously that obtuse, LagunaSol?

 

[jragosta]

Some applications have their client GUIs written entirely in Flash. Often, these are server applications and management tools - the application itself runs on a server, but it can be accessed by any Flash-capable browser.

This lets the application support access from Windows, Apples, Linux, UNIX, Android.... without recoding anything in the client.

And they can accomplish the same thing by using html without the security and performance problems of Flash.

I wonder if Adobe will delay CS5 for Apple to investigate... No 64-bit for OSX yet...

How would anyone know? They're already 3 years late to the party.

In fact, customers would probably be better off if Adobe dropped the Mac entirely and Apple had to create a comparable product from scratch.

Is Apple going to provide a rationale for this?

Please, Apple, provide a reasonable explanation.

They did. The fact that you don't like it or didn't bother to read it is no excuse.

I also don't understand all these people hating on Adobe's software. If you work in a creative field doing design in most cases you're using Adobe applications. People I work with love these programs as much as they love their Macs.

I don't know many people who generically hate Adobe software. There are lots of people who hate Flash - in spite of the fact that it's from a company who makes other products that they like. That ought to tell you how bad Flash is.

But it doesn't run natively, it runs in an runtime. If the Flash-to-iPhone compiler actually converted Flash to Objective-C there wouldn't be a problem. What actually happens is that your Flash script calls the runtime which then calls the Cocoa Touch APIs.

Or, heaven forbid, Flash developers learn to use Objective C so they can write REAL applications rather than runtime garbage.

I believe this thread has provided you with hundreds of answers to the question, most of them quite reasonable.

Loss of platform control, development uptake etc. being the most important and valid reasons I can think of.

Not to mention performance. Oh, and the fact that this Flash to iPhone compiler isn't going to be out for at least a year (even if Adobe manages to hit a ship date for a change) - so it's no good to current developers, anyway.

After reading the comments posted in this article, I can definitely say one thing. A lot of the mac fanboys don't live in the realm of reality. Don't get me wrong--I've used Macs since 1987 and would prefer to get a Mac over a PC any day, and when they finally decide to refresh the MBP line, I'm going to get a new iMac, MBP and Air if those get refreshed as well, so I'm definitely loyal to the Apple brand. I'm just not a friggin zealot like some of these tards are.

So a 'friggin zealot' is someone who disagrees with you - even though you don't have any facts to support your position and they do?

Flash isn't as much of a memory hog as Jobs is making it out to be. In fact, there was a speed test done, and basically the results of that speed test conclude that if Flash was given hardware acceleration on the Mac side of the house, then it wouldn't be the resource hog Jobs is claiming it to be.

What still irks me, and this is a bit off topic, is that they claim Flash is such a resource hog, but Apple's own graphics API is so bloated, you can actually see a difference in how it runs on OS X vs. Windows. Until Apple fixes that API and makes my computer useful for over half of what I use it for (gaming), it'll continue to start up in Windows 7 only.

This is, of course, nonsense. Quicktime works on the lowliest Mac out there - and the framework works on iPhones (even the first generation). Flash, OTOH, makes my Core 2 Duo (2.3 GHz, 4 GB) get hot within seconds and CPU usage is well over 100% - even for loading a Flash game and not playing it. Flash's inability to use resources properly is well documented. For that matter, there isn't a full version of Flash that works on ANY mobile device that I know of. They best they can do is a hobbled, limited version that they promise might be out some time this year.

Also, things run better because on a higher level, the application is designed with the native APIs in mind from the start, it knows what services to expect and at what cost, the programmers can exploit the different costs of each operation in their decisions.

By contrast, the interpreter will be constantly asking the iPhone OS for "the closest thing you have to XX or YY functionality", and the developer will have designed their code based on other platform's assumptions (e.g. the relative cost of operating on floats, addressing arrays, playing sounds, etc).



There is no gain with a "man in the middle". Devs have to grow up and get to know their tools and environment, the "Code once, run Everywhere" mantra is BS. At the very least is relies on bloat. Performance will always be an issue. Adobe thinks different and they always find a way to fill your CPU/Memory with their next release of CS. Well, I buy better hardware to accomplish more, NOT because I want to stay in 1996 while making their lives easier.

More important than performance is the issue of reliability - and robustness. When Apple switches to iPhone OS 4.0, odds are pretty good that native apps will work - and that minimal work would be needed to implement multitasking and the other new 'tentpoles'. With this type of runtime app, there's no guarantee that it will work - and it won't support new features.

I work with some tools in the healthcare industry where it generates framework code and you take it and run it in the compiler. The source it generates is NATIVE to the platform that runs it.

If what Apple is telling me is that I can't use a tool that generates Objective-C source, and that source opens in XCode and compiles to an iPhone target app, they're on crack.

Since Apple isn't saying that, you have nothing to worry about. They don't care where your Objective C comes from - whether you write it by hand, get it from a compiler or have it given to you on Mt. Sinai on a stone tablet.

 

[firewood]

Good. Real men code in a language with C in it's name

That's excludes FORTRAN, the language real programmers still code in for really big iron, as well as assembly language, what real men use for the very fastest embedded iPhone compute code (e.g. ARM VFP & NEON),...

...but includes BASIC !! (BASIC is an acronym, so the last 'C' is capitalized.)

 

[cmaier]

That's excludes FORTRAN, the language real programmers still code in for really big iron, as well as assembly language, what real men use for the very fastest embedded iPhone compute code (e.g. ARM VFP & NEON),...

...but includes BASIC !! (BASIC is an acronym, so the last 'C' is capitalized.)

I was hoping no one noticed BASIC. But no language that relies on column numbers for comment detection and line continuation is a real language, so FORTRAN is out.

I concede your assembly language point, and modify my original statement to apply only to high-level languages.

 

[PracticalMac]

Is it really the system hoginess of flash, or is it something else that Apple does not like?

If Adobe makes a Flash-lite, would that change things?

 

[firewood]

I work with some tools in the healthcare industry where it generates framework code and you take it and run it in the compiler. The source it generates is NATIVE to the platform that runs it.

If what Apple is telling me is that I can't use a tool that generates Objective-C source, and that source opens in XCode and compiles to an iPhone target app, they're on crack.

That makes about as much sense saying I can't write my objective C on paper then type it in to XCode....

For one of my projects, I took the generated code, cleaned it up, removed non-executable cruft, added comments, sane variable names, and my copyright notice, etc. Then declared the hand-edited result to be the C source code for my app.

I don't think anyone has the technical means (possibly God?) of telling your source apart from hand-coded Objective-C, not even apple, once it is compiled through Xcode. Rest Assured

You theoretically can't tell good translated code apart. But the CS5 JIT translator produces ARM asm far from anything that a human might write in C... and includes a whole bunch (stinkin' pile?) of library code which can be easily fingerprinted and traced back to the flash runtime.

Not sure about CS5, but Unity drops over 5 MB of library runtime into the simplest app.

There are also some ARM code sequences that the gcc compiler just would not spit out from any C-based language. That's why real programmer occasionally drop down to assembly language for the very fastest graphics and number crunching.

 

[firewood]

Interpreters like Java have always been forbidden. How is this not an interpreter, albeit a very specific one?

The interpreter is part of the CS5 tool, not the code that ends up within the app. Adobe's technology (I went to one of their developer talks) uses the JIT compiler within the flash/air interpreter to produce intermediate source code, and then includes only the compiled result and libraries within the iPhone app. The intermediate code is in exactly the same LLVM format that the Xcode tool path uses. Just a whole lot less elegant, and dragging a pile of air/flash runtime code (excluding the interpreter) with it.

So the new agreement explicitly disallows translated then compiled code as well as interpreted code.

ymmv

 

[benpatient]

This is how you get the anti-trust investigators breathing down your neck.

Apple has become Micro$oft.

How sad.

 

[whooleytoo]

Is it really the system hoginess of flash, or is it something else that Apple does not like?

If Adobe makes a Flash-lite, would that change things?

Probably, a bit of both.

Apple likes to control the entire system, it puts them in an advantageous position and reduces risk. They don't really have much to gain from allowing such Flash-generated apps.

But also Flash - on the Mac at least - has been inefficient in performance and unstable (very much so, in my experience). Whether that's entirely due to Adobe, or is partly due to the OSX/iPhoneOS graphics model, is hard to say.

The new Flash beta on Mac is a massive improvement (in framerate and CPU usage) on previous versions, but I doubt even that would sway Apple into letting Flash onto the iPhone; there's too much antagonism.

I think it's a pity; choice is always good for the consumer. It's not as if the App Store is free of useless, tacky apps as it is. But ultimately, now Adobe probably needs Apple more than needs Adobe. And big companies will always stomp over smaller ones, because they can.

 

[firewood]

This is how you get the anti-trust investigators breathing down your neck.

To repeat this one more time...

Apple isn't even the leading smart phone or cell phone seller. The anti-trust regulators would have to go after RIM and Nokia way before they got down to Apple and their tiny share of the cell phone hardware and even total cell phone browsers. (Just because the vast majority of Nokia customers don't use their lousy browser doesn't mean that they haven't shipped billions of them, versus Apple's mere tens of millions.)

 

[netnothing]

Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking

From AppleInsider:
http://www.appleinsider.com/article...ps_in_iphone_4_0_related_to_multitasking.html

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.

Not sure I believe this though.

-Kevin

 

[John.B]

From AppleInsider:
http://www.appleinsider.com/article...ps_in_iphone_4_0_related_to_multitasking.html

Not sure I believe this though.

By Daniel Eran Dilger (aka: prince@appleinsider.com)

As I alluded to over there, a hefty dose of skepticism is advised.

 

[jragosta]

The interpreter is part of the CS5 tool, not the code that ends up within the app. Adobe's technology (I went to one of their developer talks) uses the JIT compiler within the flash/air interpreter to produce intermediate source code, and then includes only the compiled result and libraries within the iPhone app. The intermediate code is in exactly the same LLVM format that the Xcode tool path uses. Just a whole lot less elegant, and dragging a pile of air/flash runtime code (excluding the interpreter) with it.

So the new agreement explicitly disallows translated then compiled code as well as interpreted code.

ymmv

If that were the case, then it wouldn't be a problem. Use the intermediate code and put that through xcode instead of only supplying the compiled version. Problem solved --- if your explanation is correct, which I doubt.

This is how you get the anti-trust investigators breathing down your neck.

You've just managed to prove to the world that you don't know anything about antitrust law. Congratulations.

Antitrust law isn't about whether your suppliers, partners, customers, competitors, or even government regulators LIKE what you do. It's about whether you create and/or maintain a monopoly via illegal methods. Since that is clearly not the case wrt Apple, antitrust law doesn't apply.

(There are also sections about creation of cartels, but those don't apply, either. They MIGHT apply if Google, Adobe, and Microsoft were to band together to attack Apple as has been suggested here).

 

[WilliamLondon]

COBOL lover!!!

BASIC!

 

[WilliamLondon]

How so?

This is how you get the anti-trust investigators breathing down your neck.

Apple has become Micro$oft.

How sad.

The last thing Apple has become is Microsoft - I fail to understand your logic (though, you haven't tried to explain it to be fair). What exactly do you think the anti-trust investigators can breath on Apple's neck regarding?

First, though, please explain why they investigated Microsoft.

(hint: IIS and IE)