Slashdot Mirror


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."

7 of 497 comments (clear)

  1. Re:who cares? by samkass · · Score: 4, Informative

    This has nothing to do with the current and prospective feature set of the iPad, iPod Touch, or iPhone. It relates only to the features available to the developers on those systems. This article does not discuss Flash in a browser or embedded web content, but rather Flash as a development environment that can be compiled down to native iPhoneOS binaries. So it really only matters to developers of existing Flash games who want to port their content to the iPhone easily. Given the market share of the App Store in the mobile space, though, my guess is it won't put much of a dent in app availability, and thus not affect end-users at all.

    --
    E pluribus unum
  2. Re:Hallelujah! by tepples · · Score: 4, Informative

    animated, audible, CPU-eating hellhole

    HTML5 authoring tools will bring this to your iPhone.

  3. the hard lesson of photoshop and Acrobat by goombah99 · · Score: 4, Informative

    Before apple switched to Intel, they warned developers they ought to stick to the cocoa coding guidelines uber strictly. Those that apps that did were nearly just a recompile away from being native fat binaries for intel/ppc after switch.

    Adobe took over 2 years to release native photoshop and acrobat readers. The only reason those apps even ran was because Apple had purchased the company Rosetta to make an emulator. If no emulator had existed then they would have lost photoshop!! Even then graphic arts folks were not thrilled to be having to retain their PPC computers just to run native.

    You can see why apple would not want to have an adobe flash layer running apps on the iphone. Assuming adobe did not update the flash player for two years, apps would not even run on the platform switch. There might not be a suitable emulator that could run on a resource starved iphone.

    Apple would lose a lot of apps. Consumers would be confused. And Developers would blame apple for the platform switch going so ugly.

    Now is it reasonable to presume that Adobe is not using Xcode to develope their apps? yes. One might even speculate they are using adobe AIR or some other cross platform API since their apps run on many more platforms than xcode supports.

    Why bet the farm on adobe's good will when they screwed apple over photoshop and Acrobat

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:the hard lesson of photoshop and Acrobat by beakerMeep · · Score: 5, Informative
      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.

      --
      meep
  4. Re:Something deeper by _Swank · · Score: 5, Informative

    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.

  5. This is different. by weston · · Score: 5, Informative

    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.

  6. Re:Why bypass the OS??? by washu_k · · Score: 5, Informative

    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.