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.
There's also a fair amount of rework that needs to be done with the graphics. Although all the artwork will display if ported as is, the scale is often wrong for the smaller devices. Thus, the sprites that are easy for the eyes to see on a PC screen are often too small on an iPhone. The biggest challenges often come because there's much less room on the smaller screen.
Deeper challenges come from the style of art. Some Flash presentations rely on vector art to display the same visuals at many scales. Although this works on the iPhone, its rendering is often noticeably less zippy than pure bitmapped artwork, which is handled by the smartphone's graphic hardware. Setting the cacheAsBitmap property can speed up such vector art's rendering, this is especially important if the background is vector artwork because the engine re-renders every time a sprite on top of it moves.
Tom Barclay, a project manager at Adobe, says the company is looking at adding more automation to the build process so that the packager tool will instantly rasterize the vector artwork at the right size for the right screens. Developers already know that taking advantage of the extra resolution of the newer iPhones' retina displays requires another set of graphics rendered at higher resolutions. Ideally, the build tool would convert vector images and re-render the bitmaps to take advantage of this higher-resolution display in the future.
How to move to Corona
The challenge of moving to Ansca's Corona is a bit different for Flash programmers because the language, Lua, is not the same as ActionScript. The differences are largely cosmetic, and some report that they just rework their code inline with simple steps like replacing the curly brackets with words like "do."
Ansca's Luh says that porting the code is often simple because the data structures are relatively similar and uncomplicated. For example, Lua offers only one kind of table, a collection of untyped name/value pairs.
Jonathan Beebe, a developer who creates games such as Cavern Drake with his wife and publishes them under the name Beebe Games, says he was attracted to Corona because Lua is much less daunting than the pointers that dominate the C syntax. "When I first came across it, I was about to learn Objective-C," he recalls. He noticed that Lua is very similar to PHP, which he had used before. "It's very easy to transition from PHP to Lua."
Aside from converting existing ActionScript code to Lua, Corona developers have the same challenge of shoehorning a desktop app into the small screens of the smartphones, often a bigger challenge than porting the app's logic. "The funny thing is because the iPhone has such high resolution, [developers] spent more time updating the graphics and bringing them up to iOS quality," notes Luh.
One of the biggest differences between developing for Flash and Corona is working with libraries. The Flash platform is well established, and there are hundreds of libraries, both commercial and open source, available to programmers who want to do the integration.
Corona, on the other hand, comes with several features that Flash developers using Adobe's tools must get by linking in outside libraries, and Corona's version is often simpler. One example Corona pushes is called "Physics in 5 Lines," a simple project that illustrates how objects can be created and set in motion by setting just a few fields. You can use the techniques to build basic games that employ the simple physics to create a world, then watch it break apart as the objects hit each other. Luh said he's watched developers clone Angry Birds in about a day's work.
Beebe said he's enjoyed working with the physics engine because it's simplified most of the hard slog of creating arcade games that accurately simulate the behavior of two-dimensional objects on Earth. "It's really good," he says. He also notes it's based on the Box2d open source library that offers a continuous physics engine simulating how objects can bounce off each other.
The Corona SDK also offers access to several libraries to dig into the guts of the smartphone, including connecting with the camera, speakers, GPS and accelerometer. One of the more surprising is a native library for posting updates to Facebook.
Beebe was particularly thankful for the newer library that simplifies in-app purchases. "I've read some pretty detailed horror stories about implementing them in your app," he says. "In Corona, the most complicated part is dealing with iTunes Connect, and that's something everyone has to do regardless of the SDK used. "
The reality of cross-platform mobile app development
One of the big attractions of Adobe's and Ansca's tools is the chance to write the same code for multiple platforms. But the reality is not nearly as attractive as the promise.
Mark Sigal, a co-founder of Unicorn Labs, a developer of mobile applications, says although developers can just choose the Save As menu option, they won't usually be satisfied with the results. "It's like anything else: There's going to be that 10 or 15 percent of the time that you'll spend refining your target," he explains.
Sigal said that the proliferation of Android devices is an especially taxing challenge because there are so many different sizes and versions with slightly different hardware configurations. But using a neutral development platform like Flash or Corona kept that variability manageable, he says: "Effectively we're supporting 22 different targets." Thanks to the tool, "It wasn't a big deal."