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.<\/p>\n
Section 3.3.1<\/strong> 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”<\/em> – the iPhone Packager uses LLVM to cross-compile ActionScript to iPhone-native byte code, which is now allowed.<\/p>\n I didn’t hear many people commenting on Section 3.3.2<\/strong> 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”<\/em>.<\/p>\n 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.<\/p>\n Also feasible: a Flash Player engine that developers can plug in to their Cocoa apps, to mix UIKit and SWF. Best of both worlds.<\/p>\n Where do you think the iPhone Packager is heading?<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading