Flash for the iPhone is too much, too late

Adobe gets full points for moxie for making some Flash content targetable to the iPhone, but it's not practical

We're hearing now that Adobe has tools in private beta that generate native iPhone applications from Flash projects. Some Flash-derived applications are even listed in App Store already; click the link for pointers to a few of them, because their descriptions make no mention of being authored in Flash.

With this PR bombshell, Adobe sought the attention that it didn't get when it made the more significant announcement earlier in the year that Flash intellectual property (the source code for the Flash runtime) was delivered to handset makers and mobile platform owners. I had given up on Flash as a unifying technology for mobile, but the more Adobe returns to its creative, developer-focused self, the more hopeful I am.

[ Read why InfoWorld's Neil McAllister believes that Flash for iPhone is a Hail Mary pass for Adobe. ]

That said, I see Adobe's journey as a difficult one. If Adobe simply smears Flash Lite circa 2006 across mobile platforms, it'll crash into the wake being raised now by HTML 5, H.264, HTTP streaming, and OpenGL ES native code. Adobe will have to surprise us to get noticed, but judging from the release of Flash-derived content to App Store, Adobe knows that.

Flash, and not Flash

Despite a frank and concise treatment in a FAQ on the Adobe Labs site, there is still confusion about how Adobe managed to squeeze Flash content onto a device that expressly forbids it. Adobe itself explains that it can't do a Flash Player for iPhone because Apple's SDK agreement excludes Flash. It also excludes Java, Silverlight, Python, Ruby, LISP, and Reverse Polish Notation. All interpreted or dynamically linked code (except JavaScript in Safari) is against the rules. Since Apple holds the only keys to App Store, those rules are law.

Adobe hasn't found a backdoor, and this isn't a crack through which Microsoft, Sun, and others can slip. Flash Professional 5 doesn't supplant the need for an iPhone Developer Program membership or for a Mac running Xcode. Flash content embedded in Web sites still won't play in Safari. If someone sends you a URL to a nifty Penguin Hunt applet that runs on their Flash Lite device, your iPhone won't open it.

Adobe has traded away a lot of the qualities that developers associate with Flash, characteristics that end-users don't necessarily notice, in order to get a toe in the door. Adobe's hope is that once Flash developers and iPhone users get a taste of the combination, they'll scream for more.

Adobe had to resort to a radical, but not unprecedented technique to sneak Flash-derived content past Apple's palace guard. My understanding comes from experience with similar solutions. Flash Professional 5 digests (I hesitate to say "compiles") each line of ActionScript into the equivalent sequence of machine language calls into the Flash runtime. Then it takes that digested ActionScript and statically binds it with the Adobe iPhone runtime to produce one big executable file that passes muster in App Store.

At first glance, this sounds like it would net a huge performance win over interpreted ActionScript. Not necessarily -- the simplest approach effectively generates a runtime call for every keyword and operator in each line of the script. The enormous size of the packaged iPhone executables compared to the equivalent encoded Flash content file means that speed benefits are likely eaten up by the greater number of memory accesses.

Unintended consequences

There are other drawbacks that put Flash-derived iPhone content at a severe disadvantage on iPhone compared to Flash Player or Flash Lite-enabled platforms. Flash is a normally a great fit for mobile because it's modular, it's compact, it's dynamically loaded but locally cached, and a given release is implemented almost identically across platforms. On the iPhone, Flash Professional 5-generated apps can have none of these qualities. What pushes this idea toward ludicrous is that Flash content can't be updated simply by replacing files on the Web server. Any change to the content or the runtime requires redownloading Flash-derived iPhone apps from scratch.

My concern is that this could be used as a lazy method for delivering self-playing comics, media, blog entries, and other content that belongs in HTML 5, H.264, PDF, or another intrinsically supported form. App Store could be overrun with Flash-derived "content apps" that really should be Web sites of a few kilobytes, but are instead packaged as 10MB-plus executables to grab the greater visibility and potential impulse revenue from App Store. If there is a breaking point at which the volume of App Store submissions overwhelms Apple's ability to adequately screen them, I'd wager that Adobe Flash Professional 5 will eventually find it.

Adobe might not mind seeing App Store overrun with lots of supersized, supersimple apps. If Adobe's smart, it'll work the typical file size down to fit just under AT&T's 10MB 3G download cap. After AT&T's wireless network gets a few weeks of viral episodic Flash comics packaged as 9.6MB App Store downloads, it will switch from complaining about iPhone users' bandwidth appetite to pleading with Apple to relax restrictions on interpreted code and dynamic linking.

I'm not wishing Apple or AT&T ill. It's good that technologies like this and HTTP streaming are forcing the mobile industry to wrestle with issues like software restrictions, platform interoperability, and "unlimited" data plans.

Does this leave anything to get excited about? Sure -- this is another sign of Adobe's commitment to mobile Flash. Existing Flash developers who are put off by Objective-C's learning curve will have a more familiar path to the iPhone platform for some of their content. The fact that Flash Professional 5 won't be able to convert every project isn't a show-stopper if Adobe emphasizes software, like AIR clients and in-house content, where size really doesn't matter. HTML 5, CSS Animation, and SVG cover much of Flash's capabilities at runtime, but they still require a lot of hand-coding to derive optimal performance. Interactive graphics are easier for nonprogrammers to author in Flash and related tools.

Now matter how you cut it, it's good to have Adobe rocking the boat in mobile again.

This story, "Flash for the iPhone is too much, too late," was originally published on InfoWorld.com. Follow the latest developments in the iPhone and mobile at InfoWorld.com.

Copyright © 2009 IDG Communications, Inc.