adobe air

Earlier today AppleInsider posted photos of the banners hanging at San Francisco's Moscone Center in preparation for the Macworld Expo.

They feature a teasing phrase - "2008. There's something in the air."

Today Bob Cringely also posted an article on why Apple will buy Adobe.

There's something in the air.

Adobe AIR.

Will Apple announce an acquisition of Adobe? I don't know, but I'm betting that Steve Jobs will at a minimum announce the delivery of Adobe AIR support in not only the next iPhone firmware, but in the next Apple TV. I wrote about the argument for delivering Adobe AIR or an AIR-like platform on the iPhone back in October. It made sense then and it makes sense now.

Back to the potential acquisition - who doesn't love Cringely? He's always entertaining and thought provoking, but not right all that often (which is understandable because he dares to predict big and bold). But the idea of this acquisition makes a lot of sense on many levels.

Not to mention - can you imagine Steve Jobs' glee at sitting atop a triumvirate of Apple, Adobe, and Disney? That's a powerful combination.

Adobe's AIR platform has shown that the web development model is fundamentally capable of delivering applications every bit as rich as native platform apps. Hence the outcry over the idea of web applications as the primary development model for the iPhone is overblown. Yes, the current iPhone development environment sucks but it's important to keep in mind that we haven't seen the true power of this model.

So what will Apple do if they are serious about the web development platform?

First up, a JavaScript bridge into native device capabilities on the iPhone. Right now in terms of access to device functions via web technologies, the iPhone offers nothing beyond the microbrowsers on feature phones. Yes, the AJAX support enables a quantum leap in usability, but we need more.

Top of the list - "the basics"

• file access
• camera access
• location
• address book
• calendar

But beyond these now familiar mobile device capabilities, there is an opportunity for Apple to provide powerful APIs that would provide an unparalleled mobile development environment, web or otherwise:

• SQLite local store
• Access to iTunes account-based charging
• Event subscriptions with persistent ECMAScript object handlers
• timers
• calendar events
• location
• support for installable URI handlers

Key to app usability is that these capabilities should be provided through a user consent system which does not take away the user's choice to make use of device features with a given application, a la the restrictions in many J2ME runtimes:

On first load, present the list of "privacy affecting" services being requested by the application - and listen to what the user wants! Empower the user already - they bought the damn thing.

When can we expect such features? Who knows, but I would be very surprised if the first GPS-enabled iPhones, expected in Q1 2008, ship without at minimum a JavaScript bridge to location data following soon after.

Gut check: For anyone with development experience on J2ME, can you imagine going back to the underachiever that is the J2ME RMS storage API after being provided with a local SQL store?

The native app vs. web app argument is stale!

Jeff
Chief Software Architect, EQO