Adobe Air ios packager

There seems to be a lot of confusion regarding deploying Adobe Air a开发者_C百科pps to ios after the restrictions were lifted. Before apple lifted the restrictions you had to go through the process documented here: http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html using the Packager for iPhone. But now that the restrictions have been lifted and the Air 2.7 update we can use the same ADT tool in the flex SDK that we use with all air applications.

My understanding is that the old Packager for iPhone (PFI) some how converted actionscript code into native objective C in order to be accepted by apple.

If that is correct does the restrictions being lifted mean that the ADT tool is not converting to objective C and is only bundling the AS3 .swf and air player together when creating the .ipa app file?

What exactly changed in the Air deployment process after apple lifted its restrictions?

If anyone could point me to some documentation on how the .ipa file is being created behind the scenes I think this would really clear some confusion.

Thanks for the help

Nothing really changed; apple just lifted the ban. The ban wasn't just on flash-created apps, it was on any tool that created any kind of intermediary language or used a virtual machine, etc. What the PFI does: it actually uses the LLVM compiler to statically compile actionscript 3 BYTECODE (not AS3 source) into native ARM assembly. So essentially when you're deploying an IPA it's the same idea as publishing a SWF to an exe (as in the publish settings) in the sense that both your SWF application and the flash virtual machine are bundled together, except instead of being an exe where the code inside is x86 ASM with AS3 bytecode executed along the VM, it's ARM. The PFI and all its classes were simply merged into the ADT tool. The PFI contained a LLVM dll which is accessed through various LLVM java classes that were added to the internal adobe version of the ASC or actionscript compiler. These LLVM classes and other associated classes, however, are not open source, which adobe is allowed to do, even though the ASC is open source because it's licensed under the MPL or mozilla public license, which permits the use of the open source code in proprietary closed source applications without sharing your changes.

For proof of all that I've told you, just download the new flex SDK that includes the ADT with the PFI merged in and you'll find the LLVM dll's etc. Further, you can decompile the ADT jar and see all the LLVM classes. The LLVM classes ( I believe ) intercept the ASC bytecode through the class GlobalOptimizer, or at least it did back in the day... they've probably changed that. The only other thing that has changed is that apparently Adobe has optimized the PFI (now merged into ADT) quite a lot. More info here:

http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html

http://www.leebrimelow.com/?p=2754

Update

Here is an official Adobe article confirming the things I've told you:

http://www.adobe.com/devnet/logged_in/abansod_iphone.html. I also should clarify that I've really over-simplified the process behind the scenes and appear to me mistaken in one of my points. I guess somehow the PFI actually merges the AS3 bytecode and the VM into a single seamless executable that doesn't use JIT compilation, and thus would technically not be a virtual machine? Not sure on that point, but the above article does seem to imply this:

"When you build your application for iOS, there is no interpreted code and no runtime in your final binary. Your application is truly a native iOS app."