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.
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.
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.
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.
Previously arguments against using anything but native code (Objective-C or Java) where focused on 3 things:
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 (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:
And through ANEs already available:
to list only a few.
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.
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.
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.
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.
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.
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.
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!