Developers: please comment if you notice anything that is erroneous or could be explained better. And feel free to copy/paste this and email it to any clients who contact you with similar questions.
Clients: please don’t comment with job/project proposals here. Just email me: dan@polyGeek.com.
What is Adobe AIR?
Adobe AIR is a virtual machine that runs AIR applications. That may not mean much to you so I’ll try to explain by analogy. AIR is similar to the Adobe Flash Player. The Flash Player is a plugin that you install on your computer and most mobile devices. Once you have the Flash Player you can run games/applications that are built for the Flash Player.
While the Flash Player is a plugin for the browser you can think of AIR as a plugin for the operating system. A user can install Adobe AIR – it itself is an application. Once AIR is installed you can run applications built to run inside Adobe AIR.
Why would anyone do this?
The greatest advantage that AIR offers is cross platform compatibility. The AIR runtime is built to run on Android, iOS, Windows, Mac, and Linux – sorta . Each platform/OS has it’s own specific version of AIR built to run in that particular environment. That’s a lot of work for Adobe to manage. The advantage is that a developer can create one application that can be published to each platform without any modifications.
Suppose you want a mobile application. If you go the native route then you would need to have an application built for Android which is written in Java. And then another application built for iOS which is written in Objective-C. While the languages are similar there isn’t any way to share code between projects. Everything would have to be duplicated.
Think of it as writing a book. You would probably first write it in English. Once you’re happy with it and the editing and proof reading is done then you could have someone translate it into French. Of course it would be much faster to translate than to write the original but the translated version isn’t going to say exactly the same thing either. Close, but not exact.
What’s the catch?
There are a few disadvantages to using Adobe AIR. One is that an app running inside a virtual machine doesn’t run as fast as a native application. For the vast majority of cases the difference is not noticeable. The only places that you are likely to notice a difference is in graphically complex games running on a mobile device. ( When I say graphically complex I’m thinking of things like first-person-shooters. ) That being said the performance of Adobe AIR is getting better and better all the time. With the latest release of Adobe AIR 3.0 it is possible to create a first-person-shooter for AIR that runs smoothly on a mobile device.
Previously a big disadvantage for AIR apps was that there were certain things that it couldn’t do because it didn’t have access to all of the data the underlying OS had. Like for instance the gyroscope data on a mobile phone was not exposed to an AIR app. But Adobe AIR 3.0 introduced Adobe Native Extensions ( ANE ) which bridges that gap. ANEs are native code that bridge the gap between the underlying OS and the AIR app. If for instance you wanted to write an AIR app to run on a refrigerator then you could use ANEs to deliver information like temperature and energy consumption that the OS might know but AIR doesn’t know anything about.
What if a user doesn’t have AIR installed?
There are two ways to package an AIR app. One is to do it the regular old way in which an AIR app is created and it expects the user to have Adobe AIR installed on their machine. If not then when your AIR app starts up it will either download AIR for the user – for PC/laptops – or in the case of Android apps it would take the user to the Android marketplace where they could install AIR there.
But there is also the option of bundling the AIR runtime in your app. That way the end user will never know that your app even uses Adobe AIR. The downside to this approach is that it will add about 7.5 megs onto the download size of your app.
But does it look like a native app?
Lets put it this way: it can look like a native app. I find this is common among iOS users that they want apps to look like native iOS apps. Any AIR application can be skinned to look pretty much identical to native iOS. The same goes for the other platforms. Of course an AIR application knows which platform it is running on so code can be written specifically for each. For instance a mobile device might have some code that says something like:
if( isiOS == true ) { showBackButtonInNavigationBar(); }.
Because Android phones have a built in hardware back button we don’t need to place one at the top-left of the application. But on iOS it is needed. On one of my apps – RunPee – I leave the back button in for Android because it does help with the specific usability issues of this app. Android users seem to like it that way.
Users don’t like AIR
It’s true that there are some people out there who don’t like Adobe AIR and have nasty things to say about it. There’s not much that can be done about that because the world is a big place and there are lots of generally nasty people in it. My RunPee app has a 4.4 rating in the Android Marketplace. But there are a few 1-star ratings and comments specifically upset about the use of Adobe AIR. One common misconception is that AIR slows down their phone. That’s simply not true. AIR does not run in the background all the time. It only runs when an AIR application is running. Others complain about the additional download it requires – 17 meg app. It’s no more than a 3-4 MP3s.
Others complain that AIR apps are slow themselves. That may be. If an AIR app is poorly written then it will perform poorly. But that’s true of native code as well. Any poorly written app is going to suck regardless of the language used.
Of course the one legit complaint is that they can’t run Adobe AIR. On Android it requires version 2.2+ of the OS. Not everyone has that on their phone. And some phones will never be able to upgrade to 2.2. But the vast majority can run it and of course the percentage that can’t is getting smaller and smaller with every new Android phone that comes out. For iOS it requires version 4 running on iPod Touch 4th generation iPhone 3GS and iPhone 4 iPad.
Developers galore
Some good news is that there is a large community of developers who have been creating Flash games and applications for years that can now help you build your mobile games and applications. If you want to go native then you may need to find two teams of developers. It’s possible you could find developers who can create for both platforms. But they are of course in high demand. You better have deep pockets because it’s quite a specialty to be able to create for both platforms. Not that Adobe AIR developers are cheap by any means. But at least with AIR you’re getting two apps for the price of one.
Can you really build one app for every platform?
Technically – yes. Realistically – no. The major difference between AIR apps on different devices isn’t the operating system. It’s the dimensions of the screen. While an app for mobile phones will work just fine on a tablet it might be necessary to build two different apps to take advantage of the increased screen size of the app.
In practice it doesn’t require that you build two different apps. The developer can detect the screen size and make it look one way on a tablet and make it look another way on a mobile phone. Now your essentially getting 4 apps for the price of one – Android phone, Android tablet, iPhone and iPad. Of course the code and design for the different screen sizes is going to pile on a little additional time to the project but the logic of the app usually remains the same so it’s a fairly minor increase in the overall length of a project.
Updates
It should be obvious that updates to an AIR app only need to be done once as opposed to native apps which will each require separate updating. When you consider that over the lifetime of a game or app much of the work will be done updating it then your savings in developer costs will continue to pile up.
Adobe Flex
One massive advantage to using Adobe AIR is that developers can leverage the Flex framework. I could go on for a few more pages just explaining what Flex is. But in an effort to be concise: Flex is a component framework that makes it very easy/fast to build a user interface. It is also very easy to modify. Android and iOS have their own component frameworks but they are, in my personal estimation, no where near the sophistication of Flex.
Testing
Testing takes up a lot of time when working on a project. That’s just a part of development and is unavoidable. But by having one code base as opposed to two separate ones the time spent testing is also reduced. I’m certainly not going to say that it is going to be halved because an app should be tested on both Android and iOS devices – assuming it’s a mobile device. There are minor differences in how the code responds – I just ran into one the other day that stumped me for a while. But the logic of your application should be unaffected by the device. So maybe you only need to do really intense testing on one platform and do just superficial testing on the other.
Besides that testing on iOS is a major pain in the ass and has major limitations on how you can distribute beta versions to users. Android is much, much, simpler – and faster – to test on. There’s another time saver to consider.
Anything else?
Did I miss anything? If you can think of any other advantages or disadvantages please let me know in the comments.
