ADT works with ipa-test-interpreter but not ipa-test

Question

I could use some help getting my #AS3 / #AIR application running on #iOS !

Right now I have a .SWF (v11) that I'm converting to an .IPA using Adobe AIR (v3.7) on Windows (7).

If I do the conversion with the -target of ipa-test-interpreter it works great.

If I do the conversion with ipa-test, ipa-debug, ipa-ad-hoc, or ipa-appstore, the application seems to compile fine but upon execution of the app on my iPad it just shows a black screen.

Connecting my iPad to a desktop and monitoring console output, I see not crash or error messages generated; the app appears to behave fine internally, it's just lost all external output.

This means I can test and develop but I won't ever actually be able to deploy to the app-store. Anyone else run into this?

Googling around I've run into other people encountering this problem, but no solutions yet. One thing I tried was removing all native extensions, and I also tried removing the -C compiler directive. No luck on either.

To be clear, the app runs totally fine on Mac, PC, Android, Browser, and on iOS in interpreter mode; it's just native-compilation on iOS that's broken. I've heard rumours that ipa-test and ipa-interpreter have different memory allocation routines, but I don't know enough about the low-end here to figure this out.

The remote debugger (in FlashDevelop) doesn't seem to connect either. I think it's failing before the runtime fires fully, somehow? I'm also watching the console output using the iphone-configuration-utility and there isn't anything abnormal showing up.

Temporary file link with sample project and instructions: https://dl.dropboxusercontent.com/u/1348446/test.zip

Epicardium

is your .SWF compiled with the debug flag set to true? – Discernible

Same behaviour set either way. – Epicardium

Answer 1

Figured it out. Rundown:

The ADT command line has a -C flag to change the current working directory on the command line, which allows you to keep your project better organized and keep the command line a bit more sane. -C can be called as many times as you want when importing assets, and I used it several times. IDEs like FlashDevelop also use -C in the AIR template files so this is sorta standard behaviour. As a quick example of asset inclusion:

ADT.exe [blah blah] assets/icons/icon1.png assets/icons/icon2.png

is the same as

ADT.exe [blah blah] -C assets/icons icon1.png icon2.png

(and, with wildcard use) is the same as

ADT.exe [blah blah] -C assets/icons .

As I have different compiling instruction sets for iOS, android, steam, etc., I had adt switch directories with a variable to the current config and execute from there.

This all works fine and as-documented in ipa-test-interpreter mode. When in native-code mode (ipa-test), however, including the main executable .SWF after a -C command [somehow for some reason] messes up the internal pathing; the file ends up being included but ends up being all "file not found" internally when executed, hence the blank screen and no code executing.

So the fix is simply to include the .swf from the current directory, before any calls to -C. As a quick example of my workaround that just tested a-okay:

copy /bin/flash/game.swf ./
adt [stuff] game.swf -c assets/icons .
del game.swf

I've gotten in touch with Adobe about this and hopefully they'll fix -C so it's functionality is the same for both compile targets in the future.

Epicardium

Answer 2

I have seen this happen in the past due to utilization of components "restricted" from use within iOS builds of Air apps. Specifically back in the day before being able to sandbox the loading of app resources with the loader class.

Start shutting down and turning off whole modules of your app and see when the app will build and run on iOS. I'm willing to bet there is some code somewhere that is ipa-test-interpreter safe but has odd behavior under ipa-test

Wretched

Yep, the app was eventually stripped down to a simple hello-world and still failed to execute. grr. – Epicardium

Answer 3

I see you're still stuck with this issue. If you can find a Mac to test on, I bet xcode instruments will show you're exceeding you're memory limits. It is the iPad one right? Are you using flash's embed meta tags?

Largeminded

The game crashes to desktop on iPad1 due to memory restrictions, yes. But on iPad2 and the new iPad, it just stays on a black screen and does not throw any memory limit exceeded warnings or errors of any kind. The app appears to be running normally, just without any output. (There is no "splash" image even as the app attempts to load) – Epicardium

Answer 4

Is Black your swf background color? If it is, maybe it's a cross domain loading issue because you're loading your swf and app.xml from 2 different places. I don't know if this is causing it, but I usually keep them in the same place.

Have you ever seen your provision & p.12 work on a device? If not, it might be a problem with them.

What IDE are you using to make this, Flash IDE or Flash Builder, Flash Develop/ANT? And if you post src code it would help. Sometimes putting your metadata in the wrong place can screw things up on iOS but look fine in the browser...so it could be many things.

Good luck.

Respiration