Adobe AIR – Crippled at Birth?

I’m not much of a sensationalist. I don’t subscribe to hype very easily, I’m a natural skeptic and I have been accused of intentionally downplaying my excitement. So it was fairly out of character for me when I jumped up and down with anticipation when Adobe announced their new desktop application platform codenamed “Apollo” (now called AIR - Adobe Integrated Runtime). My instinctive moderate reaction was thrown out the window when I imagined the ability to make full-featured, first-class desktop applications with my existing Actionscript and MXML knowledge.

Kevin Lynch, chief software architect and senior vice president of Adobe’s platform business unit said “[Adobe AIR applications] should be first-class citizens on your computer” (CNET News.com, May 11th, 2006). Naturally, I began dreaming up all the applications I wanted to create but previously couldn’t because of the restrictions on browser-based deployment. After attempting developing with AIR, reality sank in. I realized that I took Lynch’s comment too literally. He said that web applications “should” be first-class citizens on your computer. He did not say that Adobe would achieve this goal.

According to Adobe’s official press release, AIR is intended to be “a cross-operating system runtime that allows developers to use their existing web development skills to build and deploy rich Internet applications to the desktop.” What Adobe does not explicitly state is that AIR is not intended to develop true, first class desktop applications with the performance of native applications written in OS-specific code. While this isn’t such a big deal if you have a web application that you just want to move to the desktop (for offline access, user data synchronization or some other reason), it’s one heck of a bummer for everyone out there that thought they could use their existing expertise in Actionscript to do something that couldn’t be done before.

Here’s my list of reasons that Adobe AIR is not the revolution I hoped it would be:

Adobe AIR cannot be extended with native code.

An AIR application is created with Actionscript, MXML and web languages like Javascript and HTML. If there is any functionality you would like and that functionality cannot be created with these tools it simply cannot be done without hacks, workarounds and headaches to serious that most developers would rather not create it and end users would just rather not use it. Need a DLL to get the job done? Too bad. Want to run an EXE utility to make your application have more functionality? No dice. AIR apps run AIR and AIR alone.

Adobe AIR applications can not launch native applications.

This is an enormous limitation of the platform. If you cannot call another application from your application (other than another AIR application) the options for integration with other applications is highly limited. You can’t launch installers. You can’t integrate with Adobe Creative Suite. You can’t even send a log file to Notepad or TextEdit. One developer found an innovative way to work around this limitation (on OS X only) by calling dynamically writing shell scripts that are called through Applescript but it requires the user to take the extra step of installing an Applescript and configuring folder actions ( http://www.thatblokemike.com/blog/index.php?mode=viewid&post_id=79 ). While inspired, it’s far too complex for the average user to do and requires a level of trust that far beyond what Adobe asks of it’s users. Additionally, this only works on OS X so you are essentially writing a one-platform application that runs on a cross-platform virtual machine, robbing it of the performance that a native-code application could have.

AIR has restricted directory access on OS X.

On a PC, the Adobe AIR’s file I/O API has the full run of the directory structure available. Your application can browse all the way up the root of the C drive and back down into the Windows, Documents and Settings or any other sensitive folder. On OS X this just is not possible. The highest an AIR application can navigate without an open or save dialog is the Users directory. That means the system cannot access Applications, the system-level Library or System directories. If you had any hopes of reading or writing files to any files to anything above Users, including system-level preferences, application support config files and that sort pf thing you can forget about it. I understand that AIR runs in a partial-trust sandbox and therefore is subject to the security rules of the OS hosting that sandbox but if AIR were truly designed to create “first-class desktop applications,” developers would have the ability to create full-trust applications and leave the decision as to whether to trust the application to the user.

Adobe AIR still runs inside a virtual machine.

AIR is an extension of Flash Player. What this means is AIR applications, much the same as Flash and Flex-based rich internet applications, are compiled down to Adobe-specific bytecode, not native OS bytecode. That bytecode is then interpreted by a virtual machine, not run by the operating system itself. You are not going to get the kind of spectacular performance you would expect from a native application. Java works the same way and every multilanguage developer is highly aware that Java, while easy to write and multi-platform compatible like AIR, is among the slowest and poorest performing of all development environments. The best Adobe could possibly hope for is to achieve Java’s level of performance. No AIR app will be able to compete with an app written in any flavor of C (C, C++, C#, Objective-C). Additionally, AIR will have no access to performance-enhancing technologies that native apps enjoy like dedicated hardware 3D accelerators (video cards), OpenGL and DirectX. Unfortunately, 3D gaming in AIR is likely to be stuck in 1995.

This isn’t really new. It’s just easier.

For years there have been technologies that enabled people to create Flash-based applications and run them as desktop applications. Zinc, mProjector, and Screenweaver are all “projector” applications that let you create “app-like” SWFs. Macromedia’s own Director lets you use Actionscript to create a desktop-runnable application. SWFs could also be embedded in to Visual Basic or C applications. None of these technologies, even Director, ever became as commonly accepted and used as Flash for the browser, but they exist. AIR is primarily a standardization of a lot of the functionality these projector tools already had. The one feature AIR has that these tools didn’t is a native HTML renderer. However, that’s an incremental feature upgrade for the platform, not a revolution.

Whenever I discussed Adobe AIR one particular colleague would always asked the same question: “why create an AIR application instead of a browser application?” Without the use of native code this question is even more valid. In effect, the only reason to create an application in AIR instead of Flex is for offline use or to better integrate it into the user’s data (assuming that data is located in a place on the hard drive within AIR’s security sandbox). Other than that there’s nothing AIR can do that Flex alone cannot. Don’t get me wrong, Adobe AIR is a great product for what it is intended for. Flex and Flash-based web application developers have never had a tool that makes it so easy to move their apps to the desktop. I just wish it did more. Baby steps, I guess.

Explore posts in the same categories: Design, Development