Adobe AIR is really getting a lot of press and I have to say that I am a fan of the technology. Having come from a client-server background, its nice to leverage the technologies that I’m currently using to build desktop apps.

1. Fast execution. ActionScript 3.0 has a JIT (just-in-time) compiler, putting it on a par with Java or .NET for raw performance.

2. Cross-platform. AIR apps will run on Windows XP and Vista, Mac OS X (PowerPC and Intel), Linux (though not in the beta).

3. Easy conversion of existing Flex or HTML applications. Itâ€™s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Appleâ€™s Safari web browser.

4. Easy installation. Provided the runtime has installed successfully, installing AIR applications is likely to be be trouble-free, since all the files go into the application directory.

Some cons:

1. Limited extensibility. AIR apps have file access, clipboard access, support multiple windows, support drag and drop, and can trigger notifications (â€toastâ€ in Windows). If you app needs to interact with the desktop in other ways, the chances are that AIR is not suitable. For example, thereâ€™s no access to COM automation, and no way to execute external applications. The reason is to maintain cross-platform compatibility. Thatâ€™s a worthy goal, but it would be good to have a way out of the sandbox. Unlike Java or .NET, you cannot extend AIR with custom native code libraries. Nor can you call operating system APIs.

3. Enterprises need to roll out applications over the network in a controlled manner. AIR has no specific support for enterprise deployment. On Windows, AIR does not use the Windows Installer service. Either Adobe or 3rd parties will need to create deployment wrappers to overcome this.

Two things that I’m not quite in line with are his concerns about the proprietary nature of AIR and security concerns. First, being “proprietary” doesn’t mean its a bad thing. I realize that people have become accustomed to OSS but that doesn’t mean that EVERYTHING needs to be OSS in order to be a valuable solution.

Secondly, I had a great conference call with Adobe regarding the security considerations with building AIR apps and can say that they are very much in tune with this. They’ve had conference calls with some JavaScript industry heavyweights and are taking security VERY seriously.

Proprietary does mean it is a bad thing. Adobe dropped support for PPC Macs, so I am cold out. This is what is so dangerous about proprietary, you are at the whim of the company’s policy.

Ignoring this threat might be OK for some applications, but it is something not to put away lightly. I have been burned before and not only by Adobe.

Comment by Martin — September 3, 2007

“putting it on a par with Java or .NET for raw performance”
Hard to believe…
Static typing allows more optimisation and AIR has probably no multithreading API.

Comment by Arnaud — September 3, 2007

I think he means proprietary as in, not standardized by an impartial organization. So the opposite isn’t OSS, but standardized technologies like HTML and CSS.

Comment by em_te — September 3, 2007

Being proprietary isn’t necessarily always a bad thing, it’s more a question of managing the liabilities in regards to all of the ‘what ifs’.

Q. What if Apple migrated to Intel chips rather than PPC?
A. You either invest in an Intel Mac moving forward, be satisfied with your existing PPC machine or migrate to another platform.

Q. What if Adobe drops AIR like it did Central, Drumbeat, SiteSpring, Freehand, Multiuser Server, Atmosphere, SVG Viewer, LiveMotion, etc.
A. You hope you can migrate your AIR apps to something else, or at least continue to run your AIR apps until such time as another option presents itself.

Q. What if you can use Adobe AIR to make great internet connected cross-platform desktop applications using familiar technologies?
A. You embrace it and enjoy it while it lasts and meets your needs.

Q. What if my favourite distro of Linux is abandoned?
A. Move to another or roll up your sleeves and dive in.

Change happens – we’ve all been burned – just be pragmatic about it.
It’s current a 1.0 beta release. If it appears too risky or immature at the moment perhaps it’s best to wait until 1.x or even 2.0 to re-evalute?

Martin said: “Adobe dropped support for PPC Macs”
> …and so is going to do Apple when they will have completely switched to Intel.

Arnaud said: “Static typing allows more optimisation and AIR has probably no multithreading API.”
> Actionscript 3 actually does static typing (as well as dynamic), but admittedly it is missing multithreading – so yes, you won’t do heavy calculations in AIR apps :)

Comment by Philippe — September 3, 2007

Without the ability to build in extra libraries, AIR was essentially useless to me. Enter XULRunner, the very extensible base of Firefox and Thunderbird. It provides easy ways to build new components in either Javascript or native code, plus more things AIR is missing like multithreading, PPC support and a not-going-anywhere-anytime-soon open source community.

A tip, for anyone who bites and starts using XULRunner: use the 1.9 branch. Though it’s still in alpha, the changes since 1.8 are very useful.

Apple has completed the switch to Intel some time ago and they have not dropped PPC support. And there is no indication they plan to do so. Apple and Macs are known for their long hardware usage.

Comment by Martin — September 3, 2007

So AIR is essentially another webkit based web browser that will play swf’s and any old regular HTML locally… Can’t Flash publish to exe without AIR? Can’t any web-browser display local files and run javascript inside them? 10 years ago I wrapped an entire website up in a Macromedia Director “Projector” exe that leverage MSIE as an ActiveX to (re)host the webfiles; this also gave me FULL access to 3rd party DLL’s and the Windows or Mac OS. This is nothing new or even better than what we had before. Please explain what I’m missing…

Comment by Chris Phillips — September 3, 2007

I tend to think that items 1 and 2 in the cons list are Pro’s. The point of AIR would appear to be simplicity. It lives a space between the useless widgets ( Apple Dashboard and Yahoo Widgets ), and full blown apps. You are not going to use AIR to write photoshop, you are going to use it to write lightweight network oriented apps with an offline component… simply put there is no need for a database interface like JDBC or ODBC ( and providing one would present serious security concerns for the service provider ) if you need access to system packages outside what’s included you should probably consider a real programming language for your real programming problem. Don’t wear a Gorilla suit to a Masquerade, it’s not a costume party.

Vance, but get your facts straight before you bash things. The “useless” Apple widgets can have full host access and bind Objective-C Cocoa. So you can use all the great stuff like Core Data and whatsnot.

Comment by Martin — September 3, 2007

Midnight Coders is releasing a version of WebOrb that can be embedded in AIR apps and provides direct access to local databases. (http://www.themidnightcoders.com/blog/archives/2007_07_01_archive.html) This is really interesting because it give the same results as the ODBC style access but lets flash/flex developers work with data the same way they are used to.

So AIR is essentially another webkit based web browser that will play swfâ€™s and any old regular HTML locallyâ€¦ Please explain what Iâ€™m missingâ€¦

AIR isn’t a brand new idea completely unconnected with all that has come before it. It is a collection of technologies that a huge number of developers already know well neatly bundled together. That alone makes it useful. Especially don’t underestimate the built-in SQLite as being very appealing.

For most development projects, especially those that are for internal use, ease of development is more important than ultimate performance. Look at the huge numbers of Access/Filemaker apps out there. Everyone using these apps hates their usability and scaling limits but aren’t going to find a C++ shop to rebuild them. If they did the interface would probably still be a mess. Now the same shop that did their web site can probably do it.

If the result of my work is locked into a proprietary format from which it can’t escape, it’s not an option for me. I don’t want to risk the future of my company on the whims of Adobe if I can avoid it.

The next time Adobe changes its strategy, I’m screwed. Thanks, but no thanks.