Flash for iPhone is a Hail Mary pass for Adobe

Flash CS5 will output native iPhone binaries, but can Adobe convince developers to choose Flash over Web standards?

Everyone wants to be able to run Flash applications on the iPhone. Or wait, scratch that: Every major software vendor named after a Native American earth-based building material wants to be able to run Flash applications on the iPhone. And if its latest plan comes to fruition, it looks like Adobe might finally get its wish -- albeit not in quite the way it had hoped.

So far, Adobe has been stymied by the same thing that has prevented Sun Microsystems from porting the JVM to the iPhone. According to Apple's iPhone SDK license agreement, "No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s)." That means Java is out, as is the runtime for Flash's built-in ActionScript language -- ergo no Flash Player for iPhone.

[ iPhone apps are all the rage, but Apple makes it hard on developers. Read about one developer's torturous iPhone app dev journey. ]

But Adobe thinks it has found a way around Apple's requirements. Flash Professional CS5, the forthcoming version of the company's authoring environment, will allow developers to take existing Flash applications and compile them into native binaries for the iPhone. The resulting apps will be completely stand-alone, with no runtimes and no Flash Player required -- if Apple lets Adobe get away with it, that is.

Is Adobe pulling a fast one on Apple?

Adobe isn't the only company looking to allow developers to build iPhone apps in unorthodox ways. If Apple's Objective C language isn't your bag, MonoTouch is a commercial SDK that lets you write iPhone apps in C#. The cross-platform Unity game engine uses similar techniques to compile iPhone apps from a combination of C# and JavaScript code. And Rhomobile's Rhodes framework enables cross-platform smartphone development using HTML and Ruby.

One thing all of these products share in common, however, is that they don't output native iPhone binaries on their own. All of them generate intermediate code that must be imported into Apple's Xcode IDE for the final build process. It's sort of like the early days of C++, where the C++ "compiler" was really just a preprocessor that output ordinary C code.

Specifics are pretty scant so far, but from the sound of it, this isn't the approach Adobe is taking. Instead, Adobe is using Apple's Low Level Virtual Machine (LLVM) compiler infrastructure to build iPhone binaries directly. Adobe engineers have written a new front end for the compiler that understands ActionScript code, which then gets translated into native ARM assembly language by the existing back end.

The phrase "assembly language" here is a little unclear. Technically, assembly language is source code, which still needs to be run through an assembler to produce a final, machine-language binary. If that's what Adobe is outputting, then Flash CS5 will be much like the other products on the market. If Flash really will be able to output binaries, however, I wonder how Apple will take it.

Apple keeps tighter grips on its iPhone developers than any other smartphone vendor in the market. Its control over the iPhone App Store is absolute. Plus, it has the most expensive developer program around: Sure, the membership fees are reasonable enough, but because you can't output iPhone binaries from anything but Xcode, every iPhone developer also needs to go out and buy a Mac. I doubt Apple wants anyone messing with that sweet setup -- not even a longtime partner like Adobe.

Flash's last chance for relevance

As much as Apple has at stake, however, Adobe may actually have more. Flash has been around as a Web-based graphics format for a long time, but it's a relative newcomer as a development platform. It has built a strong niche in games, entertainment, and online marketing, but Adobe has never really managed to convince businesses that Flash is the right tool for "serious" applications. Meanwhile, open Web standards have gained ever more interactivity and multimedia capabilities, gradually eroding Flash's advantages over ordinary HTML, CSS, and JavaScript. Flash's grip on the browser is slipping -- and if Adobe doesn't move fast, it could lose mobile, too.

Already the idea of using Web languages and tools to build smartphone applications is taking hold. Palm has built an entire smartphone platform around the idea. Apple supports the use of Web technologies like AJAX to build applications based on the iPhone's Safari browser, though it doesn't emphasize that fact in its marketing. And developers will soon even be able to build Web-based applications for BlackBerry handsets, thanks to a new SDK from Research in Motion.

By comparison, Flash is still a niche player on mobile handsets, where it's used more for playing YouTube videos than for delivering real application experiences. Adobe claims its Flash Lite player will be on 1 billion handsets by year's end -- and Flash video is even coming to TVs -- but convincing developers of its value as a legitimate application development platform remains an uphill battle.

A version of Flash that can output ARM binaries opens the iPhone to all of the developers who are already building Flash games for the Web. That's a potentially huge market, and it will be interesting to see how many take the bait. If Adobe can extend this idea to other smartphone platforms and create a true cross-platform mobile development environment, it would have a compelling offering. Still, it wouldn't be the first. As late to the game as it is, what Adobe needs now is to convince developers that Flash is better than the other options -- and that could be a tough sell.

This story, "Flash for iPhone is a Hail Mary pass for Adobe," was originally published at InfoWorld.com. Follow the latest developments in iPhone, mobile, and app dev at InfoWorld.com.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies