App Development on Android and iOS – Why the value proposition continues to tilt further towards Adobe Air over native languages

Cost benefit analysis (Adobe Air vs going native)

If you’ve had the same sort of meetings with clients over the last couple of years that I’ve had then you’ll know when you ask them which platform they want to release their app on the answer is of course “all” – which for conversational purposes let’s interpret as iOS and Android.

Just like the wave of urgency that was generated 10-15 years ago for businesses to get on the web with a website, the new commodity in demand is an App. For better or worse a lot of businesses feel like they need an app presence to be visible. Putting to the side the question of the reach vs profitability of each platform (Android with larger install base, iOS with the larger turnover) there’s a lot of costs involved in natively programming two separate code bases to support the one project. Whether or not the app is just an indulgence or if the budget is more in the toe-in-the water end of the scale, cost effectiveness is nearly always a concern – with Adobe air this no longer has to come with any meaningful sacrifice.


Collateral damage

Adobe Air, as a cross platform app and game development proposition, has suffered the unfair collateral damage from a territorial war that was all but Hiroshima’d by the late Steve Jobs through his Thoughts on Flash letter and more generally his business decisions regarding the iOS platform. Never mind that so much of his argument was conveniently flawed and in someways very miss-representational – the environment and the players have now evolved and most of the premise is not longer relevant. As Moore’s law has continued so have the performance issues become null and void, other arguments such as the misuse of Flash are a straw man that would relate to any language/platform when abused.


Not perfect, but often the best option

Adobe Air (I purposely avoid any mentions of Flash when discussing app development ) may not be the perfect tool for all situations but then when we are talking cross platform development, there is none. Every app is different and some (many) do not actually require the full arsenal of device capabilities. For many scenarios making the suggestion to code two separate native language apps while Adobe Air sits there like the elephant in the room is not good business – for developers or their clients. 9 times out of 10 cost is going to be high on the priority list so when you’re looking at capabilities, expressiveness, speed and portability then Adobe Air should be there as one of your first considerations.


Banished from the browser, born again in the app store

Further to the talk of collateral damage, the fallout from Jobs character assassination of Flash was it’s fairly swift, if not complete, subjugation to pariah status in the realm of the browser. Google and Adobe supported it for a while on Android but now that’s gone, and besides the odd web game or flotsam and jetsam website that floats past your browser from time to time Flash is all but sunk as a plug in that anyone wants to admit making content for.

This is probably a good thing. I do a lot of sites that use JavaScript/jQuery to provide the sort of interactivity that Flash was required for previously, and it does a fine job. Really Flash made things difficult for most web surfing experiences where information was the currency – Flash just got in the way. But let’s not confuse the browser plug in with apps. Like the advent of Flash in the browser, Adobe Air has the potential to transform the standard App look and feel from a cookie cutter native chrome and interface to a totally customized and bespoke experience.

Of course this is a double edged sword and the right choice should be used for the right project but something that may have previously been a micro-site or a brand experience becomes so much more when a phones chrome can disappear and the designed experience kicks in on the screen from corner to corner.


The crimes of the accused – A re-assessment

Previously arguments against using anything but native code (Objective-C or Java) where focused on 3 things:

  • Performance
  • Access to native APIs
  • Consistency of user experience

Today, depending on your project these three concerns have very diminished relevance. From the very start let’s frame this discussion by removing edge cases and thinking in general terms – Adobe Air won’t solve this for all Apps but it will be more than capable of smashing out many if not most of the common garden variety ones.



There’s two areas where performance really counts,  for the most part it’s graphic rendering and code execution. Now that Adobe Air has GPU access in general terms we can say the graphical performance is removed as a handicap – we can push poly’s with native gusto! Code execution still needs improvement but we have to keep our perspective here, I can still create a game with thousands of sprites interacting on screen at 60fps using 100 or so MB of graphical textures with Adobe Air. As it currently stands, for most current generation garden variety apps you’ll have no performance issues, you have the power.


Access to Native APIs

Access to native APIs (things like accessing the camera roll or sending notifications) is a large part of the charm of mobile apps. Rightly so it’s this access that will partly determine which technology to use on your project.

I look at this two ways. Firstly, the quick answer is that Adobe Air now has ANEs (Native Extensions) so this issue has been kyboshed. With native extensions the facility is there to encapsulate any native code and expose it through wrapped functions to your Adobe Air app. Sorted. In reality it can be a bit annoying to work with ANE’s during development so I tend to avoid them where possible, though don’t be mistaken there are a lot of fantastic ANE’s out there, many free, that provide killer functionality.

The second perspective to have on this is that the list of API support natively built into Adobe Air continues to grow. This is s recurring theme with Adobe Air – it doesn’t do everything but it does all of what you need for most projects. Put simply, have a look at the functionality your projects actually do require rather than the list of what will probably be unnecessary APIs that aren’t currently supported. To give you some example, Air already supports:

  • Geo Location
  • Front and Rear Cameras
  • NFC
  • Acelerometers
  • Camera roll
  • Microphone
  • File Read/write
  • Sockets
  • Video
  • GPU
  • Push notifications
  • And many more…

And through ANEs already available:

  • Game Center
  • In-App Purchasing
  • Ads
  • Rating box

to list only a few.


Consistency of Experience

Finally we come to consistency of user experience. For me if you want an app that has the OS standard look and feel, you probably don’t want to use Adobe Air. That’s quite a big if and might give clear direction on an individual project but it’s totally opinion based.

In terms of what Adobe Air will deliver, there are Native Extensions that give you access to native alerts and other inbuilt dialogs like address book or camera roll pickers so depending on your needs that might suffice. There’s also a smart approach for throwing up native alerts via a little sleight of hand. but this is probably the limit to which you want to masquerade as an app with a native chrome. If anyone remembers the open office days (is open office still a thing?) even though they tried to recreate a native OS experience, it was always just… off and the end result was it was a turnoff.

I think this is where Air would rightly court criticism as users become used to their devices in a very subconscious way and any app that opens the uncanny valley will seem suspect. Of course when the next OS upgrade comes and brings graphical and UX changes with it, you’ve got your work cut out for you to maintain the illusion – remember you’d have to do it for both platforms too so you’re really missing the point of cross platform development as provided by Air.

To consider this a bit more it brings up the question about which apps best benefit from a native chrome experience. This question is probably one of varying opinions as to the right answer but I’d suggest apps that are perhaps data heavy and work on information based productivity probably do benefit from a no frills native chrome look and feel – there’s a certain functional efficiency along with a sense of performant reliability that the native chrome brings. Having said that, the flip side is that there are then a multitude of other app types that beg for a unique user experience that being set free of the chrome would provide; obviously games, but also educational, brand experiences and generally anything that wants to wow the user with experience as much as content.


The Benefits of Adobe Air

But this is only half of the story, above we’ve looked at the concerns previously raised against cross compiling with a technology such as Adobe air, how about we now look at the benefits of doing so.


Rapid Development

For me this one is the the killer. As an app developer I provide end solutions to clients so efficiency and cost effectiveness are of high value. Not only is AS3 fast to develop apps in, but there’s a well established community with a plethora of open source frameworks to utilise. Perhaps the one factor that makes rapid development happen for me is that I have years worth of my own code base to capitalize on, and with each project I am able to refine and enhance this work to continually improve upon the investment. When time is money, rapid development plays a huge factor. As previously suggested this benefit used to come at the cost of performance and while this is always the case, the proportion of tax you pay for this is now dropped to negligible levels for all but the most intensive apps. When it comes to weighing up the cost-benefits, rapid development is very attractive.


The Language

This is where personal taste comes in. Despite the downfalls of JavaScript the one thing it has in common with AS3 is one of the things I like and that’s it’s ECMA roots. This is probably just a familiarity thing, but the ECMA format is now just like second nature to me. If I look at Objective-C and to a lesser extent Java I’m struggling to see through the syntax structure and understand the functionality of the code – with AS3 I can see the matrix. In a more meaningful sense the joy of compile time error checking and strong typing is hard for me to effectively communicate. I not only feel out on a limb when I program in other languages that don’ t have it (JavaScript and hence “HTML5” I’m looking at you) but efficiency is incomparably improved as you’re no longer wondering why or where your code is failing for reasons as frustrating (and easy to miss) as typos or incorrect object typing. This is also invaluable in tracking down bugs that don’t only appear at compile time, but later on during execution.


Authoring Environment

The Authoring environment for Flash, the Flash IDE may frustrate some but it has a long history in building graphically rich interactive programs and the vector editing tool is extremely powerful with all the added flexibility that working with vectors can provide. When it comes to coding though I’m totally smitten with FlashDevelop. Unfortunately for mac users it’s PC only, but those of us on windows are lucky enough to work with an IDE that’s not only extremely light and performant but extensible and smart. Code completion, function hopping, find and replace, snippets and templates all work so charmingly well with FlashDevelop it’s a big reason why I’d lament any move away from AS3. Of course it is a great Haxe editor too if that’s your flavour and not to forget it doesn’t cost you a thing to use thanks to all the amazing contributors.


Cross device consistency

In contrast to the device chrome, one flip side of a customised graphical interface is the consistency between platforms that an Adobe Air app can allow you to provide. This is very similar to the benefits developers may have found with Flash in the browser where they were able to sidestep the nightmare cause by different browsers rendering of HTML and for 99 out of 100 times rely on the Flash player to render and behave consistently wherever it was playing.



When it comes down to it, not only are there technical strengths and benefits but these things effect your personal day to day experience in a very real emotional way – coding with an IDE that can remove the boring and mundane and a language that can be quickly expressive generates a real happiness that would be otherwise smothered by a clunky, long winded and overly abstracted or obtuse language. Really, for my day to day quality of life and of course the productivity acceleration this provides – it’s non negotiable.


Spread the word

It’s up to us to let clients, CTO’s, tech leads and peers know about the benefits of Adobe Air cross platform app development. In business terms it makes sense to consider Air as one of the first options for development because put simply, you’ll be able to build more quickly, cheaply and with more versatility than by using a native language.


If all the boxes for a particular project are ticked with Air, then aren’t you lucky!

  • For business productivity applications, nothing beats Adobe Air w/Apache Flex. This was true two years ago, but the performance was obviously sub-native…flex is heavy. However, with the performance improvements made under the Apache umbrella, combined with new hardware and improvements to Adobe Air, one can quickly develop business applications which not only take advantage of all Adobe Air has to offer, but also the application centered paradigm of Apache Flex…remote objects, arrayCollections, mobile iconItemRenderers and tons of other mobile specific UI components.

    The recently released Flex version 4.11, along with ActionScript and Adobe Air is truly a winning combination for business productivity applications (not so much for marketing driven consumer facing applications or games).

    • Hi Mark, good to hear that the handover to Apache wasn’t just a token gesture – how is Flex performing on mobile targets via Air?

    • “For business productivity applications, nothing beats Adobe Air” agreed! But as you say – Flex is HEAVY! And it’s slow – especially on mobile. And in the last 2 years, most of the development of Flex has been focussed on the browser – not mobile.

      If we want to talk about the evolution of AS3 frameworks in that last 2 years – Take a look at MadComponents, and it’s new new GPU Rendermode accelerated DataGrid components, etc.

      Why am I bashing Flex?… because the danger is that the limitations of Flex will push developers away from AIR. Flex is like putting concrete tires on a sports car! I know that it has already put developers off developing in Adobe AIR – and they’ve gone over to the competition.

      Don’t take my word for it. Try out Flex for yourself. But also investigate MadComponents, and for Starling project UIs, check out Feathers. Adobe AIR is incredibly powerful – provided that you carefully choose the right framework.

  • Very well stated.

    Per the native vs custom UI – even tools benefit from a nice non-native interface. I’m thinking of Ookla’s beautiful Speed Test app, which is a simple networking tool with a great custom look.

    And speaking of nice UI’s, Flash has a great ability to work with various creative workflows to import both raster and vector assets, which enables interesting workflows that allow you to render assets at just the right size for the variety of device resolutions and aspects at runtime.

    And you hint at it, but the Flash platform’s ecosystem and synergies (like the JS/ecmascript similarity you pointed out) are actually much larger (and open) than Adobe. Haxe is syntactically similar (and supports Flash targets.) Many of the most popular Flash frameworks are growing to support JS/TypeScript – I’m thinking specifically of Away3D and Starling.

    Additionally, if you don’t care for IDE’s or just want to play with the technology, then you can start with the free AIR SDK and the command line. You can prototype apps on Android devices entirely free (iOS requires a dev license to deploy to devices, even for testing.) And while not officially a supported workflow, you can do that from Linux as outlined in my blog:

    There are so many great reasons to still love the Flash/AIR platform.

    • More good points Jeff – each project will have different requirements so the tools need to be chosen on a case by case basis.

      TypeScript is an attractive solution looking ahead – in particular the way it bridges compile time error checking and strong typing with a forward looking JavaScript target. Seems like the Goldilocks zone if you need to head in that direction – hope MS give it a strong commitment.

  • Great try to make everyone trust Adobe AIR is the cross platform solution but sorry, you miss some points:

    1/ performance is still an issue : I can’t no longer use it for professional app, the times it took to save a record on a single sqlite table is just not acceptable and I won’t talk about the launch time ! The argument is not the same for game but if you’re really serious about cross platform, OpenFL is way better and get even better result than AIR+gpu+stage3d

    2/ not crossplatform : sorry with poor tablet vs phone distinction, it’s no longer cross platform. And with windows phone 8 right on the corner, you’ll soon no longer to sell the ‘cross platform’ issue

    3/ Flex drop in is just the proof Adobe bets on game not app so do as they’re saying and stop making app. Even more : every AIR release is more and more incompatible with Apache Flex, ruining their “we’ll continue to support Flex”

    4/ size : 10M ! It’s still too much

    5/ ide : I can’t argue FD is a bad IDE but far from Flash Builder and I’m really bored to lost code completion every 15 minutes

    6/ one fits all : having the same experience in ios and android is a no-go for most of my clients. They want native feelings and an app a-la-mode : action bar and slide menu pn android, not on ios !!
    I loved Flex, I loved AIR, I tried 2 years to sell it as cross platform one and only solution but I’m tired of so many issues and from no-go of my clients…and no, I didn’t follow the fool PhoneGap way.
    Native is the only solution for great user experience and clients’ satisfaction.

    • Hi Willna, while I wouldn’t argue outright with any single issue you’ve raised (besides 5!) it just highlights the fact that you choose the tool based on the project.

      If you need to build an App that needs to have a native chrome, ports to Windows phone and is for people that will notice a 10MB download as being an issue then don’t use Adobe Air. I can’t say this represents the sort of project I come across.

      For instance If you’re using SQLite to a degree where performance is not up to scratch, then look elsewhere . So far I’ve needed SQLlite in none of my Adobe Air apps so why would I use that measure to determine it’s suitability in those cases.

      My argument above is based very openly on avoiding any absolute claims about covering edge cases or extremely intensive situations, and that’s the point – in practical terms to let exceptions drive your strategy is a considered decision you’d need to make. For me, I’d be cautious of making that the driving factor when there are other concerns at play that need to be balanced, namely those related to cost-benefit.

      Finally I totally agree that Air needs to be continually improved and hopefully we can convince Adobe to do that, maybe by means of a yearly licence to sponsor the costs? I’ve heard a lot of people suggest they’d support such a model.

      • I totally agree you should use the right tool for the right project.
        What is the shame is the fact AIR is the right choice for so few projects.
        It’s again fall in the ‘quick demo’ or ‘tool’ only categories while it’s / was a professional framework.
        We should be able to use for at least 50% of mobile projects (again I’m not talking about games) but it’s far to be possible. Adobe missed again some thing here.

    • Just going to give my point of view based on the two years I’ve been making mobile apps:

      1) I agree performace should be better, but I’ve also learnt it depends of the framework used and your own coding. Even if latest versions improve the situation, Flex should be avoided all the possible… there are other mobile UI frameworks with better performace and smaller size. Out of all the apps I’ve made, just one of them involved SQLite highly, and at first also had a lot of bottlenecks, but after tweaking my queries and how I developed my data access layer, the performace gains were really huge. I’m talking about inserting, updating and removing thousands of rows from several tables at once. I don’t have numbers, but could dig them up if needed.

      2) Well, it seems we may see WP8 support sooner or later after all, but time will tell… right now I’d say there is no worthwile 100% cross platform solution, even more, at the price of Adobe AIR.

      3) They still have people contributing to, and helping with, Apache Flex. I haven’t heard from Flex incompatibilites with latest versions either (in fact, I often test several Flex apps with latest AIR frameworks and haven’t found problems so far). Again, I’d avoid Flex for mobile apps if possible.

      4) I’ve made several mobile apps where the final size was around 5 or 6MB. I guess you are talking about including Flex as well?

      5) I use FD a lot and never lost code completion. I know their MXML support leaves a lot to be desired, although I never checked it out myself. There are other IDEs like FDT and IntelliJ IDEA.

      6) I guess this is more a matter of tastes, I’ve never been asked to give different look and feels. But if I were, there are ways around it which doesn’t require much work, although depending of the design, it may increase your size more than desired.

    • Great try to make everyone not to trust Adobe AIR that it’s not a cross platform solution but sorry, you too missed some points:

      1. We have used iPad apps with SQLite db using Flex|AIR, which gives resonponses lighting fast(ranging from 1/10th of a second to maximum of 2 seconds). Flex| AIR or any other UI technology doesn’t have a say on performance when you use sqlite. It’s a job of your tables and the queries that you use. If your db is properly indexed and you use optimised queries, you’ll get responses within milliseconds. I’m talking about a db that we have used which has 16 tables and records of which are approximately 14,187 | 35,292 | 36,557 | 400,844 | 506,828 | 2,473,802.

      2. It depends on the target audience who use the app. If my clients has a huge customer base on Android and iOS platform, and if my app works on these 2 platforms, then that tool is a cross platform for my clients. Some stats:
      Coming to windows, Adobe hasn’t said that there wont be AIR support for windows at all! It says that there is no plan for now. It all depends on demand.

      3. I’m not sure how you made that comment, as youyour team have been building apps using other tools and not flex|AIR, of late ;). According to my experience, I had developed an app using flex 4.6|AIR 3.6. I ported this same app to Apache flex 4.10|AIR 3.8 first and then to Apache Flex 4.11|AIR 3.9. The performance is boosted 1.5x times! So basically, it just gets better and better.

      4. Smartphones come with memory in Gigs! 10 to 30MB isn’t a big deal.

      5. I have been using Flash Builder 4.6, haven’t come across any code completion issues. I haven’t used FD or IngelliJ. So, no comments :)

      6. This can be achieved by using CSSSkins in flex|AIR and can give native feelings. Have one application, and maintain separate CSS files for iOS and Android. Not a huge effort when you compare it to maintaining 2 separate code bases for same app, for the same outcome!

      I have been developing web applications for 7 years and mobiles applications from past one year using flex|AIR and flex|AIR solves all the problems that my clients used to face with native coding, especially development time. It’s quite fast in flex|AIR. And cross platform capability is what selling flex|AIR apps for my clients quite seamlessly.

    • Some fix for MXML has been recently pushed into the FD main branch, I don’t know what it’s fixing or improving, but maybe it’s related to the complaints listed here?

  • Very few clients are willing the shell out 2 x the cost to build apps in two languages. Marketing budgets (at least in Australia), seem to be getting increasingly tighter.

    Sure, AIR dev may involve jumping a few hurdles, and have some performance pitfalls compared to native dev, but in no way is this comparable to the added time, money and effort required to build multiple native apps.
    And then we have updates, which must once again be rolled out and tested across several projects/code sets.

    Such scenarios are just not feasible in today’s market climate. I know of many agencies (including my own) which primarily use AIR as a development platform. The existing adobe tools allow for easy collaboration between designers and coders, with debugging tools such as Scout only sweeten the deal.

    But as mentioned by others, it is a tool, and you need to find the glove that fits for your situation.
    Nothing is perfect, you need to weight up the pros and cons and occasionally make some sacrifices in order to satisfy budgets and timelines.

  • Good comments. Something not mentioned here is the inevitable benefits of time. Now, on the iPad 4 I can develop retina apps integrating high poly 3D models via Stage3D, and 2D Display List elements with high performance. As the power of devices continues to get closer to desktop, I’ve found a lot of the complications I ran into previously have slowly diminished. Of course I still have to factor in slower devices, though I’ve mainly developed private apps. So I haven’t had to worry too much about this as our clients typically purchase their devices new for the app.

    My biggest frustration now is Adobe’s lack of promotion of AIR. I’d be happy to pay a yearly fee or the like to increase marketing/developer resources within Adobe for AIR.

    I like the reference to the elephant in the room too :) Very few clients will mind with the clear cost benefits when AIR is appropriate.

  • I have been developing in Flex for a long time and have been disappointed by its performance on mobile. Abandoning Flex development on mobile and going pure actionscript with Stage3D has allowed me to create iOS/Android apps that are so close to mobile performance that I can’t tell the difference and neither can those I deliver or demo to.

    I won’t add to the already listed benefits arguments around time, ease of development, etc that have been mentioned above but in regards to performance. We have two really powerful options to combat performance on device… ANE (native extensions) and the work being done with Feathers UI ( ).

    Feathers UI has completely changed my view on building mobile apps in AIR since I first saw the beta versions of it. It is a new way of building mobile apps with starling that very cleanly separates UI from your code and even makes it easy for designers to deliver themes for your apps. I encourage anyone who is on the fence about building mobile apps with AIR to take a look at this if you aren’t already familiar with it. Take a look at their showcase page to see how some people are creating themes to create their own look and feel with this flexible UI.

    Teleport App:

    This is a sample app teleport that was created a year ago. Since then feathers has had a few releases and has improved performance. I encourage you guys to take a look at the latest release and what people are doing with it ( ). I think its the right tool for a lot of projects.

Leave a Reply to Jeff Ward Cancel reply

Your email address will not be published. Required fields are marked *

Creative Digital Agency

Code and Visual works with clients around Australia to create and build outstanding and accessible digital services. If you want to discus a project contact us now for an initial consultation.


Recent Posts