Mac App Store and WebKit.dylib

[jadams602]

There are some useful (now archived) discussions that talk about required steps to prepare your AIR mac desktop .app for submission to the Mac App Store:

http://forums.adobe.com/thread/1022213

http://pigsels.com/2012/04/air-app-store-publishing-guide/

http://forums.adobe.com/thread/1145598

All of them talk about removing the included WebKit.dylib from the AIR captive runtime distribution that gets placed inside your .app before you codesign because including Adobe's bundled WebKit.dylib from the AIR runtime and trying to use HTMLLoader etc with it, will cause a rejection of the app since it supposedly used private APIs.

I had mentioned in the archived discussion that I was going to try keeping WebKit.dylib in my new .app, using it for HTMLLoader based Help system, using the latest AIR SDK 3.8 and see if things have changed regarding Apple's rejection of the latest WebKit.dylib.

I am happy to say that my sandboxed app, leaving WebKit.dylib and codesigning it along with the rest of the app was approved and is now live on the Mac App Store.

So this no-WebKit.dylib/no-HTMLLoader use in Mac AIR apps on the Mac App Store might have finally been worked out by Adobe/Apple.

Would at least be good to get some official confirmation from Adobe whether this was done, or I just got lucky on the submission??

[jadams602]

Scratch that. Spoke too soon. While the 1.0.0 version of the app was accepted and is live on the store, when we attempted to do a minor bug fix update (just changing some ActionScript code), this 1.0.1 got flagged and rejected for the private API uses.

Same AIR SDK, same captive runtime.  Just an inconsistent and probably different reviewer for the update.

So continue to remove WebKit.dylib from your apps.

[jadams602]

Just to followup in closing, the update was accepted by Apple after removing WebKit.dylib as documented, and replacing the HTML help system with an included PDF file that opens for the user using File.openWithDefaultApplication();