This was done with AIR 3.3 and the swf compiled with Adobe Flex 4.6.
I'm now developing a new version of my application with AIR 3.4 (probably when I finished this, will be tested and deployed with AIR 3.5 if meanwhile goes out of beta) and Apache Flex 4.8.0.
With the AIR 3.4, the icons step (the second step from my build script) could be omitted (at least in theory) because starting with AIR 3.4, Adobe AIR now supports 1024x1024 icons (required by Apple for the MacBook Retina Eye version, so mandatory).
Nice to hear about the 1024x1024 icons, wasn't aware of that.
As for your problem now I seriously have no idea what the problem could be. My app wasn't using the Flex SDK, but I don't see why this would have any influence. Only thing I see is that maybe you are using a component of WebKit, like the HTMLLoader or Flex mx:HTML or StageWebView.
I did exactly the same steps described by firstname.lastname@example.org
My bundle is made with flash cs6 and air 3.4, i don't use any webkit at all.
I have no other errors beside this, and is getting frustrating. On http://pigsels.com/2012/04/air-app-store-publishing-guide/ the final comment (as of August 2012) presents exactly the same error, but still no answer. I also use a Snow Leopard and an Application Loader 2.5.1
Uhmmm maybe Flash CS6 could be the culprit here. I've seen some packaging problem happen with it on Mac. I'm not using it but one of my colleague was buiding and AIR app fos iOS with it and he always had to extract the .app from the ipa as the Zip file was invalid when he was trying to drag it to XCode. In fact, I think the error looked awfully similar, so that might be it!
I know this is not the exact same issue, but I suggest you try to manually bundle your published SWF manually with adt.
Well, i build my bundle without Flash CS6, and still receive the same error. I tried with air3.5... 3.4...3.3...3.2....3.0... still the same error
I still think this is happening because of Application Loader. I mean, i can upload my app if I do this little trick:
but the .app will be broken, without a "Current" simlink.
So, Application Loader let me upload a broken .app, but don't let me upload a working .app.
on http://pigsels.com/2012/04/air-app-store-publishing-guide/ the same error has no answer
For now, on Snow Leopard with Application Loader 2.5.1, publishing air content seems impossible.
I heard some versions of Java caused problems with Application Loader. Maybe that's the cause, but I have no idea what version you should use.
Java causing problems to Application Loader? Although it seems nonsense, what should i do? Uninstall Java Runtime? I'll give it a try.
I mean, all that Java could do to Application Loader is not letting the Loader to communicate with iTunes. I had this type of error caused by java on a wireless connection when trying to upload to app store.
But no way java could make Application Loader read twice the same folder. What I'm saying is that Adobe.framework cannot be correctly read by Application Loader. If Java is the problem, then why can I upload my application if I modify the framework's simlink? And how come this is not an Adobe only error? The same issue was found for MacRuby and SDL.
Ahah you're so damn right, I wrote that in a hurry and didn't think it twice. The Java problem was related to either Codesign or Productbuild. I can't remember if the problem could only be seen when trying to upload or if it was more "fundamental", i.e. operation not completing.
Sorry for the mislead.
Is is OK to create the .app file from Flash Pro by exporting with Air for Desktop? I can select Application with runtime embedded and it seems to work. Run on my mac fine at that point. But I'm getting the error:
object file format unrecognized, invalid, or unsuitable for all the console commands.
Has anyone worked out of Flash Pro for this?
Never tries it from Flash Pro, but that's not quite what you need. Having the .app is fine but you still have to do all the steps mentionned before (remove webkit, edit entitlements, sign with your Mac App store certificates and package it for application loader).
I've been able to remove webkit and edit the icon, but anything from the console gives that error. So I'm still stuck at editing entitlements.
Oh uhmm well I have no idea, sorry !
Maybe try with "sudo" ?
Is there any solution for those of us that want to publish a sandboxed app to the Mac App Store *and* use WebKit.dylib?
I was planning on using HTMLLoader to display in-app help, but having to remove WebKit.dylib prevents one from using HTMLLoader (even in the latest AIR 3.7 beta SDK).
Shouldn't there be a way by now to just have the captive runtime dynamically use the WebKit.dylib already on a user's machine?
I was hoping the further improvements to supporting sandboxing on Mac App Store would have eliminated this WebKit.dylib issue by now. Has Adobe or Apple possibly resolved the issue of rejecting apps that still included this WebKit.dylib from newer captive runtime SDKs?
That was the same reason we wanted WebKit in our apps. We had to pull that feature and just embedd information normally.
We now have two apps in the mac app store now build with Flash Pro and Air:
Geography Drive USA
Gappy's First Words
Compared to iOS the sales volume is pretty low. But it's cool to have a couple apps for Mac desktop.
Yes, I'll have to resort to an alternate solution as well if this is still not allowed in the latest SDKs.
I was just hoping for an update on the status of the latest WebKit.dylib.
I notice WebKit.dylib in SDK 3.7 beta is only 6.7MB while the one in SDK 3.3 was 7.4MB so I was hoping the offending private APIs might have been stripped from the latest captive runtime.
(mentioned in an older post/reply here: https://lists.webkit.org/pipermail/webkit-help/2010-December/001788.html)
Maybe someone from Adobe can comment on the latest WebKit.dylib or someone might have submitted an approved sandbox app to Mac AppStore with a newer SDK without removing the latest WebKit.dylib?
Othewise I'll just try it myself in a fwe weeks when my app is ready for submission.