Building iPhone and Android apps with Flash

Once upon a time, the path to the Apple App Store was very simple for Adobe Flash developers: Put aside your childish ways and devote yourself to the pure complexity of Objective-C. Your fancy tools and rendering libraries are nice for beginners, but only those who master pointers and malloc were welcome to feast at the table of iOS. Everyone else had the door slammed on their fingers.

The reason was simple: Apple refused to accept code with libraries or interpreters and like schoolmarms everywhere insisted that everyone write their own code. Perhaps Apple was afraid of viruses, downloaded code or competition from cross-platform tools.

That was then. Now Apple has relented a bit and is no longer completely shutting out runtime platforms like Adobe's Flash for the development of iOS apps tailored to the iPhone and iPad. This is good news for the people who've mastered a set of tools that continues to produce some of the best-looking content on the web.

"Basically Adobe vector and raster rendering are years in the making and they've perfected this technology," says Paulius Uza, CEO of InRuntime, creator of the game Alchemist. His company often prototypes ideas with other technologies such as OpenGL, but he maintains that "the Flash version always looks prettier."

Now Flash developers like Uza have several paths to the iPhone and iPad from Adobe, as well as a sharp competitor built by people who used to work for Adobe. All of them open up opportunities for those who are accustomed to working in the Flash ecosystem to use their talent and old code to create new apps.

The standalone Packager for iPhone tool takes your ActionScript 3 code and cross-compiles it to run on an iOS 3.0 or later device. The output is native code, not interpreted Flash bytecode, for Apple, this packaging step pretty much guarantees you won't be shipping new bytecode to the device over the Internet and circumventing the gatekeepers at the Apple App Store.

Packager for iPhone is best for developers who understand how to create a Flash website. Uza said his group likes this option because it offers more control for those who prefer to think along the same lines as programmers. "We are writing the code with Flash Builder, which is for developers only. It doesn't have any tools for visual assets," he notes.

More casual creators such as graphic designers who are more comfortable in an integrated application can use Flash Professional CS5, which now comes with Packager for iPhone built in. Instead of saving the project for the web, you choose an option to turn the project into an app that's ready for the App Store. It still requires the developer to have a certificate from Apple, which you get from registering with Apple's iOS development program, but Adobe's tools do the rest.

A third path comes from the Corona SDK built by Ansca Mobile, a company created by people who used to work on the Flash team. Although the SDK uses Lua rather than ActionScript as a language, the structure of the applications and the API are very similar to Flash. CEO Walter Luh says, "There are a lot of people who will find it a very easy product to understand."

Both tools also promise cross-platform opportunities. Google has welcomed Flash developers onto Android, as has Hewlett-Packard for the forthcoming WebOS 2.1. Adobe also plans on ensuring that its Flash code will run on the forthcoming RIM PlayBook's BlackBerry Tablet OS. Corona supports both iOS and Android, and it may add other platforms if demand warrants.

Moving Flash apps from the desktop to mobile

These tools will be very tempting for any Flash developer with a pile of code that already runs on the web.

"In some cases, you can just port them over," says Richard Galvan, a Flash product manager at Adobe Systems. "Update the project for a smaller screen size and then very quickly publish it out for iOS. You can literally take the exact same project and in the next same step publish it out to Android."

Still, he warns that although the Adobe packager will make everything work, there may be UI problems with the ported app. For example, smartphones have small screens and often no keyboards, neither of which desktop Flash apps typically accommodate. Likewise, touch events behave slightly different from mouse clicks. Thus, many desktop Flash apps will require a bit of rethinking of how the user interacts with the code.