Skip to content
April 1, 2014 / Daniel Freeman

RE: Gary’s letter. Chris’s Response. AIR vs PhoneGap, etc.


The following essay is prompted by Gary Paluk’s Open Letter to Adobe, and Chris Campbell’s response.  I wanted to elaborate on some technical insights to Adobe AIR vs. PhoneGap, and the severe limitations of PhoneGap.  In particular, for Enterprise and General Purpose apps.  I also wanted to talk about the Adobe AIR and Flash Platform communities.  How the de-emphasis of Flash has affected the community, and disenfranchised customers.


The AIR Community

I was very proud of the AIR community last week.  They may have soured an unfortunately-worded Adobe announcement with their discontent – but their solidarity, and support of AIR was admirable.  In their announcement, Adobe describe their new PhoneGap toolset as “Adobe’s lead­ing cross-platform app devel­op­ment solution.”  It’s no wonder that AIR developers were upset.

To many, this seemed like the final straw from Adobe, who seem to have already truncated the roadmap, neglected the Flash Platform community, failed to communicate the virtues of AIR, and effectively gagged and silenced the Flash Platform evangelists.  The ACPs, like myself try to keep the flame alive, while Adobe itself remains mostly silent about the Flash Platform and its continued success.

It is not unwise of Adobe to focus on HTML5 toolsets.  Although, the challenge will be to stay ahead of free open-source offerings.  Making a success around open HTML5 technologies is going to be a lot harder for Adobe than it was for them to build successful products around their own proprietary Flash Platform technologies.  If I seem dubious about their ability to succeed – it is because new Adobe seems to have lost much of its surrogate Macromedia DNA now.  I just see corporate grey, public relations whitewash, and bland beige bean-counters.

In response to Gary Paluk’s open letterLuca Mezzalira explained Adobe’s financial motivation.  But why do Adobe’s HTML5 ambitions have to be mutually exclusive to AIR evangelism and support?  When Adobe shifted their focus from the Flash Platform to HTML5 – it was like flipping a switch.  The Flash Platform Community was a tremendous asset.  Adobe’s destruction of that asset makes no sense.  Many disenfranchised customers may never trust Adobe again.  Great news for Unity3D, Ancsa Corona, Titanium, Sencha, and Open Source alternatives.  I wonder if it’s possible to a price on the destruction of the Flash Platform community?  Suppose we could calculate that, and put it under the noses of the myopic accountants steering the good ship Adobe – I wonder if they’d change direction?

I watched an interview with Shantanu Narayen where he talked about the de-emphasis of Flash in favour of web standards (6:00). When asked about Flash on an iPad (7:00) – this was a perfect opening to talk about AIR, and apps – but AIR was never mentioned.  This interview is even worse: “With products like PhoneGap, we want to enable people to build great apps, whether they be HTML or native apps, for the iOS platforms.” …. really?


Those disenfranchised ex-customers

I was in Thailand at the end of last year, and I offered to give a presentation to a Bangkok Web Meetup Group.  I joined their Facebook Group, and I saw a discussion related to WebGL, and I responded to a comment that was pertinent to Stage3D.  I might as well have lit a fire under a hornet’s nest.  These guys turned on me, and flamed me, made me out to be some kind of idiot, and hurled personal abuse – before I left their group in disgust.  There was no point.  Most of my technical arguments were way over their heads anyway.  Tough crowd.  I changed my mind about giving a presentation.

The attack came mostly from Caucasian developers, not Thai, who identified themselves as former Flash and AIR guys.  Disenfranchised with Adobe, and its technologies.  The web designers had switched to HTML5 and the app developers had switched to Unity3D.  There was a lot of hate.


The Power of AIR

Overall, HTML5 never superseded the Flash Platform on technical merit.  It just got adequate for making banner ads and rich experiences on the web, so it stole those markets.  The challenge for Adobe then was to develop the capabilities of the Flash Platform into new markets where HTML5 would flounder.  One important and underexploited market is where you raise the bar on the sophistication of mobile/web apps.  Like Adobe’s own Photoshop Touch app.  Did you realise that this was built using Adobe AIR?  I don’t know why Adobe are so restrained telling people what AIR can do?  I don’t believe the conspiracy theories that claim a sinister collusion with Apple.  But I can see that conspiracy theories are more comforting than blaming it on the incompetence of Adobe’s marketing machine.

I’ve always been fascinated in the ability of AIR to raise the bar on the sophistication of apps.  I built a spreadsheet, illustration, and sophisticated publishing app using AIR on the desktop.  It was my intention to port these to tablet devices – but I got busy with other projects.  ( They’re not available for download anymore – but I’ve got some videos on my youtube channel. ).  The publishing app, e2publish, in particular, leveraged the capabilities of Adobe’s TLF Framework.  HTML5 text layout doesn’t even begin to approach what TLF can do.



HTML5 on mobile is buggy, fragmented across OS versions, and performs badly.  While both Apple and Google pay lip-service to HTML5, neither want to compromise their app walled-garden.  The iOS performance of hybrid apps is worse than web apps.  Facebook, LinkedIn, and other companies abandoned hybrid HTML5 apps.  This is essentially the same approach as PhoneGap.

So when the AIR developers gate-crashed Adobe’s party, they weren’t being AIR purists, narrow-minded xenophobes, or fan boys.  They were highlighting a valid technical comparison.  That Adobe AIR is generally much more capable than PhoneGap.  Most of these guys have kept abreast of HTML5 advances, and many know PhoneGap too – warts ‘n all.  Ironically, I’m teaching a five day HTML5 and PhoneGap course to corporate clients the week after next.

PhoneGap essentially makes a mobile app out of web pages.  That sounds easy, doesn’t it?  But once you scratch beneath the surface it involves mastery of a whole load of frameworks and tricks.  Once you get deeply into it, you’ll find yourself missing the simplicity and speed of AIR development.

PhoneGap can incorporate mobile-styled HTML5 forms – does this mean that it’s great for enterprise and general purpose apps?  Not really.  PhoneGap has its niche – but it does not scale up well to sophisticated projects. A lot of developers have got their fingers burnt battling with and performance issues and workarounds with PhoneGap / Hybrid HTML5 apps.  I’ve seen it described as “Build Once – Optimise Everywhere!”.  If you succeed getting your app working, then maybe your project will take many times longer than what it would have taken if you’d used AIR.  If you fail (and I’ve heard accounts from many developers where this has happened), then you waste time and money.

So what is PhoneGap good for?  PhoneGap is good at simple thin-client apps, or HTML5 document-based apps such as WikiPedia, or Cross Platform apps deployed to many target platforms (iOS, Android, Blackberry, Widows 7 and 8, WebOS, Symbian, and Bada).

A while ago, I started a discussion on LinkedIn regarding Hybrid HTML5 (PhoneGap), vs. Native, vs. other Cross-Platform approaches.  It makes interesting reading.  Here are some of comments that developers made about HTML5/Hybrid/PhoneGap apps:-

“I spent 9 months… tweaking a html5 app and I pushed the limits of html5 on mobile… We had to go native… html failed.”

“The argument that it is faster and easier to develop a non-trivial app in HTML5 is total nonsense”

“In XCode using Objective-C I’m a pretty happy camper. My HTML5 days are much less pleasant”

“Building a complicated mobile application in HTML5 has been hard”

“The cost of doing HTML5 UI development is greater …. beyond a moderate level of complexity”


asm.js, Enscripten, and

Obviously, asm.js, Enscipten, and are exciting developments that are worth watching.  But do they solve the problems of mobile hybrid and web apps?  I doubt it.  There’s no point of compiling to asm.js to run inside a mobile hybrid web wrapper.  If we’re going to get into Cross-Compilers, then use OpenFL (Haxe NME) to build a real native app.  If ASNext isn’t going to happen, and clearly PhoneGap will fail, then Adobe should at least invest in OpenFL.

Suppose there is a significant improvement using on mobile?  Enough to become a threat to Apple and Google’s app walled garden.  Are they just going to allow that?  When AIR for iOS was first released in 2010, Apple changed their developer agreement to ban it from iOS.  The embargo lasted six months.  The proposed Cordova enhancement relies on a modified version of Webkit.  Not the standard iOS version.  Would Apple allow that?

(btw, I found this detailed article, that goes into a lot of depth about JavaScript and web app performance on mobile)


AIR 2D and UI Frameworks

Adobe AIR is really good at building Enterprise and General Purpose Apps.  The problem is that Adobe has never backed the right UI framework.  The Mobile Flex Framework was slow, bloated, and its inadequacy did a lot to destroy people’s perception about the power of Adobe AIR on mobile devices.  Flex made AIR look like a joke on mobile, and it initiated the exodus of developers looking for alternative frameworks.  The lucky ones found MadComponents, and stayed with the Flash Platform and AS3.  Others abandoned Adobe technologies and went over to the competition.  The mobile side of Flex hasn’t improved under the Apache group – and Flex remains the worst option on mobile.  Feathers is a great option provided that your project is built using Starling.  So it is more appropriate for menus and controls for 2D games.  But again, Adobe backed the wrong framework with Starling.  Genome2D and ND2D(x)  were always much more capable candidates, that demonstrate the impressive power of Flash Platform more definitively.

Call me biased, but MadComponents is still the best UI framework for AIR General Purpose and Enterprise apps.  The next release will include better tab pages, better scrolling responsiveness for lists with custom renderers, and even more powerful datagrid capabilities.  There’s a video introduction to MadComponents here.  I’ve always wanted to build a drag-and-drop UI Builder app for MadComponents.  But unlike Feathers, MadComponents is not supported by Adobe, and I can only do so much with no funding.  But considering that it has evolved slowly, whenever I’ve had the time – it is pretty impressive.

My App

Most of last year, I spent developing a very sophisticated AIR app that peaked at #4 in its iTunes category.  I don’t want to say too much about it now.  Later in the year, I’ll make updates that will attract a wider release, and I’ll make public announcements when the time comes.

I used Adobe AIR – because it is so powerful, versatile, Cross-Platform, and it scales-up very well to sophistication. I did seriously consider other options.  Xaramin, and OpenFL (Haxe MNE).  But AIR allowed me to utilise MadComponents – and this was a huge bonus in favour of AIR.  It allowed me to incorporate powerful datagrids and novel UI elements.

In the future, both MadComponents, and my app may be ported to OpenFL.  But right now, Adobe AIR is still very much alive and kicking, despite any speculation to the contrary.

Actually, before I got involved with this project, another developer had attempted to implement the app using PhoneGap. Given the sophisticated nature of the app, I’m not surprised that they failed.  PhoneGap was a naive choice that wasted time and money.


Chris Cambell’s Response

I was impressed by how quickly Adobe responded to Gary’s letter.  Chris describes himself as a “customer advocate” for the Flash Runtime product team.  I don’t think we have evangelists anymore.  I wonder how much sway this advocacy has inside Adobe, outside of the marginalised Flash team.

Personally, I’m not unhappy about the updates to AIR.  But I think they need to give us Windows 8 support soon.  Vote on that feature request here.  Also, Android x86 support.  Vote on that here.

Chris mentions “video and gaming” several times in his text.  And every mention of this grates on my nerves.  Adobe AIR is a versatile and powerful technology.  It’s not PhoneGap.  If you build an enterprise app, beyond a moderate level of complexity, you run a higher risk of failure if you use PhoneGap, than if you use Adobe AIR.  The AIR development time will likely be shorter anyway.  YES – AIR is great at Gaming and Video – but it is great at a lot of other things too.

The decision to compartmentalised AIR into Gaming and Video, and PhoneGap into Enterprise, was likely made by some technologically naive Adobe accountant at a board meeting.  It’s a decision that doesn’t stand up to an experienced developer’s objective technical scrutiny.  It was a dumb decision that will backfire – the same as hybrid HTML5 backfired for Facebook and LinkedIn.

If you tweet this – please use the hashtag:  #ListenToYourCommunity )



Leave a Comment
  1. Zync / Apr 1 2014 10:26 am

    I like Mad components, only thing I’m not a fan of is putting XML inside of actionscript. Still looking but can’t find a good tutorial on keep it external with the tempting functions still working. Tried a while ago but just gave up as I ran out of time on a project. Any resources on that?

    • Daniel Freeman / Apr 2 2014 5:13 am

      For most developers, defining XML inside an ActionScript Class file is fine. (That’s why there are no tutorials on this – it is specific to your unique requirements, and not generally applicable to anyone else). You may use separate Classes for XML views if you like. Separate from your app logic, or controllers – you can organise your project as you see fit.

      It IS possible to read XML dynamically, and assign to the UIForm.xml setter to render a layout dynamically.

      But you won’t be able to use the curly-brackets notation inside your XML. Not unless you write your own text substitution code. You’d have to write your own code to pre-process your XML strings if you use curly brackets.

  2. ActiveCaptain / Apr 1 2014 11:25 am

    Wonderful focus on the meaning of all the comments to Adobe on phonegap/air. I pray they read it and think about it.

  3. lucamezzalira / Apr 1 2014 12:27 pm

    First of all thanks for the mention.
    I like the tech point of view of the situation for newbie people or people outside the Flash Platform community, really a good overview.
    Next time we should join the force to write down one post with everything, because from your post to the Gary’s one to mine we touch basically any points of view of the situation!!! 😀

  4. Luis Guajardo Díaz / Apr 1 2014 3:14 pm

    personally use Flash / Air as my main tool to do a lot of labs&demos that involve Arduino, OSC, and other Physical Computing related tools. And I agree that flash can be used for more than Games/video, i do not know any tool that can be used to prototype as fast as flash can be used today. Not even with Adobe Edge or newer IDE’s.
    I will stay with Flash and its ease of use, and support and spread the word about its capabilities.

  5. Jeff Adams / Apr 1 2014 5:20 pm

    I’ve always valued your comments and input, and this post is no exception to your well thought out expertise, however I feel I must comment that I think your calling out of Starling being a ‘wrong choice’ by Adobe is unfortunate and unrelated to the discussion of Adobe’s own commitment to the future of AIR/Flash.

    “But again, Adobe backed the wrong framework with Starling. Genome2D and ND2D(x)
    were always much more capable candidates, that demonstrate the impressive power of
    Flash Platform more definitively.”

    I know in the past you have made similar comments about your lack of love for Starling, and I am in no way trying to change your mind on it, but to somehow infer that the lack of Adobe’s success with AIR/Stage3D was perpetuated by an ‘unimpressive’ Starling framework and that they would have enjoyed better success by having backed some other (just as equally available) Stage3D framework is quite unfair and not backed up by evidence reflected in the volume, success and comments from the majority of developers that have created apps with Starling. If anything, the existence of frameworks like Starling, Genome2D and the rest have all breathed a longer life into AIR/Stage3D that it otherwise wouldn’t be currently enjoying, irrespective of Adobe’s own decisions on its future.

    I’d like to think most of us all belong to the same shared united front to see AIR/Stage3D solutions succeed, without having to further divide our camps by what frameworks we happen to choose.

    • Daniel Freeman / Apr 2 2014 5:59 am

      It’s good that Adobe sometimes supports open-source community frameworks. But the exclusivity and favouritism is wrong. I would prefer less support if Adobe could hedge their bets over more candidates. When Adobe shines their spotlight one favoured particular framework – it casts a shadow on all the other guys. So it’s not Starling that I dislike, as much as the spotlight. If I’m making the spotlight seem a little dimmer – then good!

      The frameworks that Adobe doesn’t support also lose support from the wider community – because that community rush to the Adobe “recommended” technology. Even though it is invariably inferior. For a start, this doesn’t looks good in benchmark comparisons. ND2D development almost collapsed because of this uneven playing field. (This always reminds me of guided evolution.)

      The danger is when a developer tries the “recommended” framework, and it isn’t powerful enough, or it isn’t appropriate to their application. So they tick the Flash Platform off their list – and they move on to the competition. This happened many many times with Adobe Flex for mobile. It likely happens with Starling/Feathers too. I’m not saying Feathers is bad. It’s great for apps that use Starling anyway. But not a general-purpose or enterprise app that doesn’t need Starling. (Because Adobe AIR isn’t OFFICIALLY for that use-case anyway.) I’ve had quite a few developers move from Feathers to MadComponents. I don’t know how many others went over to the competition.

      I would not recommend direct rendermode and Stage3D for general purpose UIs anyway. (And I’ve elaborated on the reasons in great detail before)

      • alexh00 / Apr 2 2014 5:17 pm

        I’m with Jeff on this one. There is more to what constitutes a good framework than benchmarking performance. One area that Starling really shines in is basic ease of use. It makes developing Stage3D apps extremely simple by sticking to code structures and concepts that AS3 developers are already familiar with. I can’t speak for the alternatives like Genome2D and ND2D because I haven’t used them but I get the impression that they all have a steeper learning curve.

  6. Jaime / Apr 1 2014 6:22 pm

    I totally agree on that. I use AIR to make APPS with nice visuals and GAMES with even more visuals:)
    The last one I did it is by far the best app of its genre (making teas).

    And I also used AIR to make games that are extremely full of visuals effects , physics and particles. Running smooth in most phones.

    If you want to see what AIR can do check the apps.

    If Adobe is watching this, please check the tea app you will use it very often and yes it’s AIR! (Not shitty – slow – inefficient HTML)

  7. radu / Apr 3 2014 2:51 pm

    Right on, how can we count the active developers in the community?

  8. Keith / Apr 4 2014 6:11 pm

    Hi Daniel,

    I’ve been following your blog for a few years now and really agree with many of the things you say. I was on the Flex/Air bandwagon for years and prototyped flex mobile apps. Once I saw how poorly they performed on mobile I was shy to continue down the path of Flex for mobile. Once, Adobe gave Flex to the open source community, I felt the support would die off and Flex would fade away. Indeed, Flex is not the right framework for mobile, but Adobe willingness to quickly do away with it makes me think twice about using their technology.

    I’m currently seeking the next technology I will use for an upcoming project and PhoneGap is winning out because it is HTML/JS/CSS. All of these technologies will be around for a LONG time. Longevity of the technology is important to me because I can’t afford to rewrite my apps if/when Adobe decides to do away with AIR. That is my largest factor in choosing AIR and a 2D framework or something like Phonegap. While mad-components may be the solution, my concern is the same – how long until support ends?

    I truly would like to use AIR, but I cannot get over my concerns stated here.


  9. selt / Apr 5 2014 4:22 am

    I wholeheartedly agree with the comments. I would add that I think it is pointless to expect or even ask Abode to continue to support or promote AIR/Flash. Even if the company announced tomorrow that it was going to do an about face and start to pay attention to what was arguably one of the best development communities and development platforms in the world I would not believe them. They have proven themselves untrustworthy. I think we (meaning the loyal AIR/Flash developers) are being cynically used by whatever this company has morphed into, and I don’t think we should let them do that to us anymore. It smacks of a type of abusive relationship where we are the enablers, and that can’t be good for us. Let’s face facts, this corporation is going to abandon us at its earliest convenience, and when it does it will be without compassion, pity or regret. So why give them that kind of power? I understand that we all have significant business considerations with AIR to think about (I certainly do), but I don’t like being used, especially after how much I have defended this company over the years.

    I think the best thing now is for all of us to abandon this sad situation in mass and move our skills to something else–and something not Adobe. In our going, let’s produce a sinking experience for Adobe reminiscent of what they did to us a few years ago. Perhaps we could provide a lesson for the industry as a whole about what it means to abuse your loyal developers.

    Daniel, thanks for all your hard work. Please make good on your promise to move Madcomponents over to OpenFL as soon as you can. I’ll join you over there.

  10. mr_mmmmore / Jan 28 2015 4:43 pm

    I believe that when judging Adobe people we too often underate their decisions. When not making the points they could make with AIR, it’s not because of a bad communication, it is an intended strategy. They have a runtime technology that works and they cannot drop everything just now: many enterprises rely on applications developped with Flex, many website and business still rely on the Flash Player. Droping the whole Flash platform instantly would be disastrous to Adobe in terms of image: upsetting a community of dedicated developers is not as costly as upsetting top companies and businesses or many customers (“where is my gaming platform??”). So they let it die slowly, but they can’t state it clearly.

    So why do they need to drop it anyway? That’s because Adobe shareholders don’t want to spend money on developing runtimes or optimizing renderers when this can be left to browsers developers. This is written in these lines of the Flash roadmap:

    “With the growth of competition in the browser market, browser vendors are increasingly innovating and providing functionality that makes it possible to deploy rich motion graphics directly via browser technologies, a role once served primarily by Flash Player. ”

    Understand: Why bother spend all this money when others can do it for us? Let’s just wait all these technologies are mature enough and meanwhile let’s develop products for this future. In this perspective, abandonning ASNext was perfectly logical.

    I think Adobe people are not comfortable with managing and selling such technologies (Macromedia people could do it), so they can’t believe in investing on them. Plus the 2010 crisis that followed Steve Job’s letter against Flash made them fear being that much dependent on the strategies of OSes companies. Building on the open standards seems much more safe…

  11. Josh Strike / Sep 20 2015 6:22 am

    I can’t believe I just stumbled on this post. I try not to read too much AIR/AS3 hate stuff, it’s been going on for years and I just do what I do with the tools I prefer.

    It is scary to think that support could cease totally for AIR. I’ve developed frameworks in Phonegap and Canvas and HTML5 from scratch, I know what they can do, and they are truly awful. I just finished a 6-month private in-house app project for a business that I was really on the fence about. In fact I began two parallel code processes for the front end in Phonegap and in AIR. It was not very long before it became obvious that the HTML5 solution just wasn’t going to cut it, for so many reasons. Simply put, the DOM is not made for drawing complicated models, or for multi-touch interactions, and every patch you put on it just adds to the nightmare. And Javascript is SLOW when dealing with huge data models and blitting things on a phone. And I know, because I’ve written heavily optimized drawing/display list systems that do their absolute best to squeeze cycles out of canvas redraws and interactions.

    It’s offensive to hear people claim anything about HTML5 being a superior way to write code. No one who has ever had to write a cross-platform app for anything more sophisticated than a clone of a web page would ever say that. I can make either system bend into whatever shape I want, but at this point I am still building major products using AIR that I expect will be supportable 10 years down the road.

    Maybe the best thing that could happen to AIR now would be Adobe handing it over to Apache, as they did with Flex. Heck, the only reason I pay $50 a month for CC is because of FlashBuilder, which is being horribly neglected and is completely buggy. Talk about adding insult to injury.

To discuss MadComponents/MC3D, join the Facebook group!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: