A question about Adobe's six new tablet apps

Discussion in 'iPad' started by FloatingBones, Oct 4, 2011.

  1. FloatingBones macrumors 65816


    Jul 19, 2006
    On Monday, Adobe announced six new tablet apps. The Macrumors article about the announcement notes that the Android apps will be available next month but the iOS availability is scheduled for "early 2012".

    The question: if Adobe Flash/AIR with Adobe's packager is such a great programming environment, why isn't Adobe releasing these as Flash/AIR apps? Why did they go to the trouble of creating native apps for each of these two environments?

    The Flash-advocates here seemingly claim that their coding and execution environment is comparable to iOS and Android native environments. The very company we would expect to agree to act consistently with that claim clearly doesn't believe it. What gives? What message should we take from Adobe's refusal to use Flash/AIR for their own tablet programs?
  2. 4DThinker, Oct 4, 2011
    Last edited: Oct 4, 2011

    4DThinker macrumors 68020

    Mar 15, 2008
    While the same programming environment can be used to create apps for Android and iOS, the primary UI functions of the two devices are different. You get one Home button with iOS, but dynamic back, home, menu, and search buttons in Honeycomb. Code can't be simply re-compiled to work on each system. The program's interface takes some re-thinking to best take advantage of both.
  3. FloatingBones thread starter macrumors 65816


    Jul 19, 2006
    Then I am not getting it.

    No limitation of the Adobe packager is noted in the product description of the Flash/AIR packager software descriptions on the Adobe website. If there really are different UI functions, shouldn't those limitations be noted there?

    If these six programs' interfaces take some re-thinking to take advantage of both platforms, wouldn't that be true of any application delivered to both platforms?

    Could it be that the promise of Flash to deliver on all platforms from one code base really isn't true?
  4. mkaake macrumors 65816

    Apr 10, 2003
    or maybe simply an indication that different jobs require different tools? that the types of applications they're going to release are a poor match to the AIR packaging tools? That some apps are more complex and require, again, a different toolset?

    I'm not for or against the AIR packager, but I certainly don't think that adobe choosing a different toolset to code some fairly complex apps is indicative of the toolset being useless any more than I take apple's not using xserve to run their store (while they still made them, anyway) as a sign of the xserve being useless.

    Use the right tools for the right applications...
  5. FloatingBones thread starter macrumors 65816


    Jul 19, 2006
    It certainly could be an opportunity for Adobe to tell us what they think Flash is best-suited to do and what native apps are superior to do. They have spoken very loudly with their actions. Sadly, I don't think they will explain those actions to us.

    I personally think that native apps on iOS apps will always be superior to Flash apps packaged for iOS. Look at the example of Machnarium: it enjoyed a brief (3 day?) run as the #1 iPad app in the App Store, but has since faded to somewhere around #50. I cannot imagine that a Flash app will ever be the superior app in any class on iOS.

    I don't quite know what this means. AFAIK, Adobe has never released programs like these anywhere that were implemented in Flash.

    If you think your analogy is of any value to this discussion, you need to explain why.

    If your goal is to deliver a lowest-common-denominator app to a variety of platforms rapidly, then Flash seems to be a fairly decent choice.

    If your goal is to deliver the best-of-class app for a particular platform, then using tools and APIs native to that platform appears to be the superior choice.

    It is what it is. Each approach has its strengths. If you think that those conclusions are wrong, please provide a counterexample: a Flash app that is the best app of its kind on the iOS platform.

    ... or the Mac platform.

    ... or the PC platform.

    ... or the Android platform.
  6. FloatingBones thread starter macrumors 65816


    Jul 19, 2006
    Someone contacted me privately and asked me to spell out why this analogy was flawed.

    Apple's server products (currently Mac Mini or Mac Pro, with OS X Lion Server software) are pretty clearly defined as a server for a workgroup or small company. There are file-sharing, mail-storage, VPN, backup, calendars, and a Wiki. For an all-Mac (or even a mostly-Mac) shop, I bet it does a pretty darn good job. A quad-core Mac Mini with a Thunderbolt RAID sounds pretty darn sweet for a group server. OTOH, I see no Apple claim that their rack-mount or current products would be a good fit for a generic website or Apple's own store. Have you seen any claims, @mkaake?

    Adobe clearly intends for their tools to be available on both Android and iOS. Adobe also clearly wants those tools to be available as rapidly as possible on all platforms. From the marketing claims I've heard about Flash, it would indeed seemingly be the perfect tool for the job.

    Exactly! What about Adobe's requirements would make their Flash tool a poor match for the job? If Flash were a pill, when is that pill contraindicated?

    I don't know. I've never seen any marketing literature that Flash should only be used for small and simple apps. Do you know something the rest of us don't know? Do you have a reference?

    Remember, the leveraged advantage should be far bigger than just Android and iOS: Adobe could release Flash that would run on PCs, Macs, etc. One set of source code that would run perfectly everywhere. They could get out far more product to more platforms in far less time.

    If Adobe things Flash is great for delivering multi-platform solutions, why do they avoid using it for that purpose themselves?
  7. mkaake macrumors 65816

    Apr 10, 2003
    barring the oddity that someone actually contacted you privately to discuss why my previous analogy was flawed... I'm not quite sure what's with the tone. I'm not saying AIR is the best choice in any given application, just that it's another toolset available to a developer (and yes, you can deploy an AIR application without any flash involved - just saying).

    My example, more to the point, was to say that Apple doesn't run their services off of xserves (not that they could anymore, as they don't sell xserves any more), they don't run them off of mac mini servers, and they don't run them off of server configured mac pro's. The reason is the same that adobe didn't try to create these 6 applications with AIR - it's the wrong toolset.

    Apple doesn't make any claims on their site that a mac mini is a good fit for one of the busiest stores on the web; conversely, they also don't say that it's not a good fit. Same with Adobe and AIR - because to the people who actually *use* these tools, it's fairly obvious when and where you'd want to apply them. You'd have a very hard time finding an IT admin suggesting that a mac mini be configured to handle anything on the scale of apple's website, just like you'd have a hard time finding any programmer worth his salt suggesting that complex photo editing applications are best created using the AIR toolset.

    Again, might be a good idea to calm down a bit. First of all, AIR != Flash, and Flash != AIR. Secondly, the people who need to use these tools don't need to be told what they're a good fit for... just like you wouldn't try and tell a carpenter what type of hammer to use for a given type of job. They know - they're the people who *use* them.

    Adobe thinks its great to have an easy means of deploying applications between multiple environments with minimal hassle, and even better for them if they can continue to get people to use their software.

    End of the day, though I find this whole thread pretty entertaining, here's my opinion on the subject - if I were wanting to deploy a fart app to mutiple OS's, AIR seems like it would be a pretty solid fit - code once, compile for multiple platforms, and done.

    Does that mean its the end all be all? No, not at all. Does it mean you'll be making world class applications using AIR? No, not really. But it also doesn't preclude that you can make a world class application with AIR. I'll toss back your own example of Machnarium - it spent 3 days at #1 - and how many applications developed natively can say that?

    If a programmer does his job right, you'll never *know* what program was used to compile code. Nor should you particularly care. If you are using an app and are unhappy with its performance or interface, don't use it. And if you're using an app that you're thrilled with performance wise and interface wise, why does it matter if it was built using xcode or AIR?

Share This Page