Adobe Stops Development For iPhone

adeelarshad82 writes "Adobe's principal product manager Mike Chambers announced that Adobe is no longer investing in iPhone-based Flash development. The move comes after Apple put out a new draft of its iPhone developer program license, which banned private APIs and required apps to be written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine. According to Chambers, Adobe will still provide the ability to target the iPhone and iPad in Flash CS5, but the company is not currently planning any additional investments in that feature." Daring Fireball points out approvingly Apple's rebuttal to the claim that Flash is an open format, however convenient it might be for iPad owners. Related: The new app policy seems to be inconsistently enforced. Reader wilsonthecat writes "Novell have released a new press release in response to Apple's announcement that none-C/C++/Objective-C based iPhone application development breaks their SDK terms. The press release names several apps that have made it past app review process since the new Apple SDK agreement."

Comments

Re:Something deeper

[_Swank]

All your points relate to a completely different issue than what this article is actually about (don't worry, it looks like 99% of the 'techies' posting to this article fail to understand what Adobe actually announced related to Flash and the iPhone).

In short: THIS IS NOT ABOUT FLASH IN THE BROWSER ON THE IPOD/IPHONE/IPAD.

Let me repeat: THIS IS NOT ABOUT FLASH IN THE BROWSER ON THE IPOD/IPHONE/IPAD.

Adobe released a feature that allows you to export an app created in Flash CS5 (not the Flash Player client) as a native iPhone app. This meant you could export an iPhone app that includes ZERO bits of Flash that could then be submitted to Apple's AppStore and appears like every other app.

What Apple said in the their license is, essentially, you must not use 3rd party tools to create native iPhone Apps. XCode and Objective-C are your options.

What Adobe said is that they will no longer work on the above feature for the Apple devices. But will work on it for other devices.

So if you want to create an app that targets the web, the desktop, Android, iPhone, etc. You will be able to target all these platforms with a single code base -- except the iPhone...that you will have to write separately in Objective-C as a completely different code base. Because of Apple's whims.

Note that, according to the license, this also applies to all other non-Apple tools that can be used to cross-compile to a native iPhone app.

This is different.

[weston]

Your friends are poor researchers because the iPhone and iPod Touch have never supported Flash. That's why the iPad flap was always so funny to me. It could be summarized as "Adobe is angry that Apple won't start supporting an app that it's never supported on its other portable platforms".

You don't understand what just happened between Adobe and Apple, then.

Apple's said plenty of times that it won't support Flash as an interpreter/runtime on the iPhone. I think everybody understood that.

What happened here is that Adobe took them at their word, and did something totally different: they wrote a compiler which takes content written using CS5 and targets *Apple's* runtime. FLA file in, iPhone Binary out. Not SWF, iPhone Binary. Doesn't need the Flash Player to run. Apple wouldn't have had to do a damn thing to "support" these applications.

So Apple changed their license terms and banned apps from the store that were created by another toolchain to target Apple's runtime.

And, for good measure, they also banned apps that are made by targeting Apple's tool chain from another language. So that way, Adobe knows they can't decide to build a version of Flash that takes a FLA file and emits an XCode project that's ready to build.

Of course, that means you can't do something like write in Scheme that compiles to C, either. Or for that matter, generate any code, really. If you're going to target the iPhone, you'll write all your C, C++, and Objective C code by hand like a real man, buster, and you'll like it.

Re:the hard lesson of photoshop and Acrobat

[beakerMeep]

Every time a Flash story comes out someone pushes this anecdote about cocoa but where's the evidence? You're complaining it took two years to rewrite Photoshop in a completely different language? How many times have you re-written something as complex as Photoshop in the past two years?

Btw here's what one of the photoshop engineers said about the switch to intel based Macs: http://blogs.adobe.com/scottbyer/2006/03/macintosh_and_t.html

Here's another quote from the Photoshop Product manager (John Nack) in 2008:

No one has ever ported an application the size of Photoshop from Carbon to Cocoa (as I mentioned earlier, after 9 years as an Apple product Final Cut Pro remains Carbon-based), so we’re dealing with unknown territory.

...

1) Writers gin up controversy about Apple vs. Adobe, portraying this as a case of some tit-for-tat ("This one time, Steve wouldn't play golf with Shantanu, so Adobe is sulking!"). Oh, come on. This is why Lightroom x64 is a such a nice counterpoint: Adobe's decisions are pragmatic, not ideological. Look, Apple and Adobe share the goal of maximizing Photoshop performance on Mac hardware, and we're working together on all aspects of that story--64-bit included.

"If it bleeds, it leads," however, and writers looking to drive ad impressions will try to fabricate a grudge match. Please don't let them.

2) Adobe gets castigated for "dragging its feet" on Cocoa/x64. This charge will be inevitable, I suppose, but I want you to know that we started work on the problem immediately after WWDC '07. We started peeling senior engineers off the CS4 effort, and we'll keep pouring on the muscle in the next cycle. This work comes at the expense of other priorities, but so be it.

3) We start hearing all about "Cocoa Über Alles"--about how Adobe should have known that Cocoa is the One True Way and should have started the move years ago. Most Mac users don't know Cocoa from Ovaltine, and nor should they: it's just an implementation detail, not a measure of quality. I think Brent Simmons, creator of wonderful Cocoa apps like NetNewsWire, put it most elegantly: "Finder + Cocoa = Finder." That is, rewriting one's app in Cocoa doesn't somehow automatically improve its speed, usability, or feature set.

I'll also note that Apple's Carbon Web site says, "Carbon is a set of APIs for developing full-featured, high-performance, and reliable applications for Mac OS X... The Carbon APIs are also well-suited to cross-platform development." I don't mention it to detract from Cocoa; I mention it to point out that each approach has its pros and cons, and in hopes that we don't hear all about how Cocoa is clearly the only way to write "real" Mac software.

Read more here: http://blogs.adobe.com/jnack/2008/04/photoshop_lr_64.html

This whole cocoa vs carbon drama is stupid. It seems only to suffice as some PR dig from Apple fanboys against Adobe. Or some shit-stirring controversy for tech blogs to get hits or slashdotters to whore karma. Anyone who has used Adobe apps professionally on mac in the past ten years knows at no time were they ever not available on Macs.

Nobody screwed anybody. It's just what happens when platforms change.

Re:Why bypass the OS???

[washu_k]

Ummm, third parties, cannot directly access the video hardware on Windows or Linux either, but apps running on them seem to be able to use the provided video APIs just fine.

Read the up on the problems VLC and others have on OSX. Yes the APIs are there, but they DON'T ACTUALLY WORK!

Flash, VLC and the rest don't need direct hardware access on OSX, just playback APIs that aren't crippled.