June 11, 2007 On Adobe AIR and the iPhone SDK

Adobe has released the AIR beta, formerly known as Apollo. AIR stands for Adobe Integrated Runtime, and “fully supports HTML and Ajax, meaning Apollo applications can be created without using any Flash at all. They are also releasing an extension to Dreamweaver web development software.” (via TechCrunch) AIR is a runtime that allows development of connected applications that run on the desktop.
Let’s get one thing out of the way first: AIR is a runtime, that has to be downloaded and installed. I immediately think of the JRE (Java Runtime Environment) and seeing that annoying coffee cup in my Windows taskbar, but AIR is sure to be an improvement upon that experience, and a more approachable development platform. The question remains, though: why are we downloading a runtime to use the Web when we already have a browser? Furthermore, why would I trust Adobe with another download on my system? One of the things that makes me happy having switched to the mac is that I no longer have to deal with Acrobat. The latest version of Acrobat is an unwieldy, crashsome beast that constantly prompts me to update the software when I just want to read a PDF! Preview in OS X is a way better solution.
And how about the Flash download experience these days? What URL do you go to download Flash? How many clicks does it take? And have you noticed that by default you’re opted in to download and install Google’s toolbar as well? Thanks, but no thanks. I’m not terribly interested in more downloads when so many applications (think Gmail) run nicely in the browser, with no downloads. Things I do download, such as extensions for Firefox, are limited to the browser, and stay out of my OS.
But let’s say Adobe plays nice and we don’t mind another download. We can use AIR to build desktop applications now, which makes one TechCrunch reader very happy:
I don’t feel like I have to learn anything…I can just dive right in to coding HTML/Javascript apps. Very exciting, as I’ve always wanted to develop my own desktop apps.
All well and good, but where’s the value for the end-user? This web developer gets a kick out of building an app that runs on the desktop, but he’s writing a web application that would function in a browser. In the browser, he should be relying on browser navigation and conventions to make things intuitive for the user, not inventing his own hare-brained UI just because he can.
Is there a market for web applications that can be accessed when you’re not connected to the Internet? There sure is, and Google Gears is facilitating that by providing a lightweight browser plugin that synchronizes online and offline data and allows access to a web site either way.
The iPhone is a “new” OS, a different flavor of OS X for the mobile device, and there’s been much demand for an SDK so that developers can start writing applications for it. Steve Jobs provided the answer at today’s WWDC keynote. Did Apple develop a “desktop” runtime environment that would enable developers to write applications that could sit on the iPhone and optionally pull data in from the Web? Nope. Use Safari, they said. Use XHTML/CSS/AJAX to write pocket web apps that run on the iPhone. And run in Safari. And....probably work as Widgets.
Dashboard Widgets in OS X are micro-web apps. As soon as the iPhone debuted with all those little squares on the screen, the connection clicked. Little applications that run in Dashboard (also written using XHTML/CSS/JavaScript—no special runtime or SDK), can be easily translated to the iPhone.
The web works. Apple’s putting it to use across the whole damn product line. Adobe’s trying to reinvent it, and trying to force me to download more garbage on my desktop. Which is easier to work with, and which is truly better for the user?