Adobe iPhone Packager 2.0

The whole Flash community has been jumping for joy ever since Apple revised their controversial App Store License Agreement in early September this year. Apps created with Adobe’s “iPhone Packager” are not longer banned from the App Store, and Adobe started working on the product again.

Section 3.3.1 now merely forbids the use of private APIs.. tooling and language restrictions have been lifted, especially the part that prohibits “linking to documented APIs through an intermediary translation or compatibility layer or tool” – the iPhone Packager uses LLVM to cross-compile ActionScript to iPhone-native byte code, which is now allowed.

I didn’t hear many people commenting on Section 3.3.2 though, which i find weird. I think the real good news is this very section. Code interpreters are now explicitly allowed, given that “all scripts, code and interpreters are packaged in the Application and not downloaded”.

This means that Adobe could potentially shelve the existing, LLVM based iPhone Packager, and instead deploy a regular AIR runtime with a separate SWF. This would certainly make the publishing process a lot faster, as there is no cross-compilation step anymore – a standard SWF is published, which is then just packaged together with an iOS AIR runtime. I am uncertain which approach would perform better though: interpreted and JIT compiled via virtual machine, or LLVM translated native code.

Also feasible: a Flash Player engine that developers can plug in to their Cocoa apps, to mix UIKit and SWF. Best of both worlds.

Where do you think the iPhone Packager is heading?

7 thoughts on “Adobe iPhone Packager 2.0

  1. Something that allows UIKit and SWF to be mixed would be truely amazing and definitely top of my wishlist.

  2. In my opinion the packager can only be interested when there is a way to combine the two. I’m a flash developer for many years now and i really love it. I also develop obj c at the moment. But i think all the frameworks available in the iOS sdk are there for a reason. Ofcourse I’ve tried flash to build an iPhone app but at this moment it’s not even on 10% of where it should be to get interesting to use.

  3. > The whole Flash community has been jumping for joy

    I think this is absolutely not true.

    Some sane part of Flash community cannot care less about what Apple (or Steven) does.

  4. To make my point clearer:

    I think Adobe should stop developing (=wasting resources on) iPhone packager.

    Who can say that Apple (=’evil’ Steven) will not change his mind any minute?

  5. I am game for any setup that would speed up execution on iOs. Even a Unity style export to xCode option would work (of course it’s not cross platform tooling).

    Just because you don’t have a need for it doesn’t mean it is a waste. In the past month I have developed 4 Touch apps and 3 iPad apps. All in Flash, to communicate with AIR Apps. Doing all of these in Flash CS5 and Flash builder is a huge time saver. Even if I don’t sell on the App store, there is a huge market for ad-hoc apps. This tool is crucial for a lot of developers.

    If ubiquity is what Adobe is after, then ignoring the iOs platform would be a huge mistake. I command Apple for revising their agreement and Adobe for resuming the PFI development.

  6. I personally think Adobe should finish with their other mobile commitments before going back with the love/hate project that is the iPhone Packager. Lets see AIR for Android finished, AIR for RIM out the door and AIR for WinMo 7 on it’s way before they sink any more resources into Apple.

    They have something that work. I would feel OK with them updating it to include some of the new APIs that they’ve introduced for Android.

    The way I’ve seen it, and how most of the community precieved it — Adobe sunk ALL of their resources into the iPhone thing before it got banned. Once it did, they began to diserify (mostly going with Android), which made other projects start to move forward.

Comments are closed.