Adobe Adds iPhone Native App Creation to Flash

Today at Adobe Max 2009, Adobe announced the ability to create native iPhone applications using Flash 5. Now, this really has very little to do with my earlier rants about Flash, because it has nothing to do with Web Development. This is about creating native iPhone apps using ActionScript and Flash tools, which get compiled down to ARM assembly. You can find some more technical information about how they do it here and an FAQ here.

It's an interesting development, and I'm not sure what to think about it. At first glance, it certainly seems like a good move on Adobe's part, as it will make a great marketing point for their dev platform. From a realistic standpoint, though, it doesn't change my opinion that you should avoid hammer development principles and should choose the best tools for each platform. Flash has always been a compromise that takes considerable overhead to let you create applications that can run on multiple platforms while feeling native on none and getting native performance on none.

I also think that using this technology carries significant risks until Apple's position on it is made clear. I've seen no indication that Adobe worked with Apple on it and have seen at least one claim that it was done without Apple's involvement, knowledge, or consent. If that's true, it will be interesting to see how this plays out, but I wouldn't advise even touching the technology until Apple's opinion is known.

There are currently several applications on the App Store created with the private beta version of the Flash iPhone SDK. Out of curiosity, I downloaded several of them to check them out.

First impression: the end-user is unlikely to have any idea how the application was created. There's nothing about these Flash-created applications that screams "Flash". They look like pretty much exactly like any other immersive iPhone applications. That's good.

The next thing I noticed is that none of the applications are particularly advanced or feature things that would tax the hardware or need to leverage the GPU - no 3D rendering, no crazy amounts of animation, no particle generators. They seem to have the equivalent functionality to Flash games from seven or eight years ago though, to be fair, these are early beta experiments, and I probably shouldn't read too much into that. But, these first examples do feel a little sluggish for what they are.

The applications are also bloated for what they are. That Roach Game is nearly ten megs in size for a game that lets you squash roach silhouettes. Red Hood (App Store Link), is twelve megs in size for a point and click game that shows two static images and you have to find the differences. It's little more than an interactive Highlight magazine on the iPhone, with better artwork. The size is an important thing, since apps over ten megs can't be downloaded over wireless connections from the phone and most people buy over wireless. I would bet good money that these applications, rewritten as a native App, would be at least half the size. Which, of course, makes me wonder why there's so much extra code if there isn't an interpreter or JIT compiler in there. But Adobe claims there isn't and that this is compliant with Apple's 'no interpreters or compiler' term of the SDK. I'm not sure I buy that. I'm not sure Apple will either. I suspect there will be a lot of scrutiny applied to the binaries they produce, at very least.

As I dug in further, I noticed that everything gets compiled into the executable. In a typical iPhone application bundle, all the images and sounds files are stored as individual files, separate from the executable, which contains pretty much only the code. If you unzip a Flash-generated .ipa file, you don't see the typical application bundle structure. Other than the splash screen and icon, you don't see any resource files at all, but the executable file is enormous because all the resources are inside of it. This makes me wonder if these Flash-generated apps are memory efficient, which is very important when writing for first and second generation phones. It's not impossible that they could be, but this doesn't seem like the best storage option for an embedded application.

Digging in even more, I noticed that the images in these apps are PNGs, as recommended for iPhone development, but are not byte-order aligned with the iPhone's video memory (GBRA instead of RGBA). So, Flash iPhone apps would appear to get all the disadvantages of the PNG file format, like no lossy compression, without the advantages you get in Xcode-generated iPhone apps (byte alignment to speed up blitting).

The binary executable inside these Flash apps does link to a number of the standard iPhone frameworks, including UIKit (which Flash developers can't access directly according to the FAQ), Audio Queue Services, Core Graphics, and OpenGL ES. Supposedly these Flash apps can leverage hardware acceleration, which the linking seems to support, though the application performance seems to undermine.

Certainly, many Adobe Flash/Flex/Air devs who are scared by Objective-C are celebrating today. I think that celebration should be tempered with a note of caution.

I'm curious to see Apple's reaction to Adobe's back-door insertion of Flash apps into the store before publicly announcing the technology. That was a smart marketing move on Adobe's part - if Apple doesn't yank the apps, it validates Flash as an iPhone dev tool, but if Apple does pull them, they give Adobe assloads of free publicity in the process. Brilliant… in a skeevy sort of way.

Of course, since Adobe doesn't appear to be doing this in partnership with Apple, then it seems unfathomable that Adobe could have accomplished this feat without having violated the iPhone SDK agreement, specifically section 2.5 which prohibits reverse engineering or redistribution of any of the SDK components as well as the creation of any derivative works. Heck, I think you could argue that Flash 5 with iPhone support IS a derivative work under 2.5, and if it's not, there was no way they could have created it without reverse engineering parts of the SDK.

My guess is that Apple won't take kindly to Adobe reverse engineering certain undocumented parts of the SDK. I'm curious if Apple will confront them, and if they do, if it will be directly, or if they'll just do what they did with Palm and make it so Flash-generated iPhone apps stop working. Given how different the application bundles are between an Xcode-generated application and a Flash-generated iPhone application, it would be trivial for Apple to do that, if they wanted to. Heck, it's even possible that these apps will break on future versions of the SDK just because their bundles are different even without Apple doing anything intentional.

If I were a Flash developer, I wouldn't cheer just yet. This looks like a risky proposition to me at present. Adobe and Apple are still acting in an antagonistic fashion toward each other. Adobe could very well have crossed the line here. There are both legal and technical options open to Apple to prevent Adobe from doing this if they choose to. Will they? I honestly don't know. Apple still makes money from apps that are created with Flash tools, so they might just ignore it and take their 30% cut quietly.

But my gut says they are probably not going to do that. If I had to bet, I'd bet that this isn't going to sit well with Apple, and isn't going to play out well for Adobe. I think I would avoid using Flash for creating iPhone apps until and unless Apple gives the process some kind of blessing. Until that happens, it's just darn risky. Your apps could just stop working. They could get yanked. They could act oddly with future releases of the iPhone OS. I'm not saying any of that will happen, just that it's a risk that Adobe's not being up front with Flash developers about.

We do live in interesting times.

Posted in: Adobe