TestFlight Catastrophe

[William Spence]

I have a real mystery on my hands, and need any thoughts you can muster to help me solve it.

I have written an AIR app for iOS, and when I debug it, everything runs perfectly.  It traces out all of my values and I feel confident that I am doing things right.  No errors are thrown at all.  Then I export a final build, upload it to Apple and run it in TestFlight on my iPad, and bam!!! It doesn't work.

Specifically, it is an ANE for in-app purchases that is not working correctly.  Everything else it my app runs like a charm, but when I click a button to make a purchase for my subscription, the app becomes unresponsive.  How does an app work when installed directly on a device for testing or with an ad hoc distribution without throwing any errors, but when you run it in TestFlight, it does not behave properly?? How is this even possible?

So, if you have any suggestions on how to debug an app that runs in one environment but not in another on the same exact device, I would love to hear your suggestions!

Thanks!!

[Douglas McCarroll]

I'm not sure how helpful this will be, but I experienced a similar problem with distriqt's MediaPlayer ANE. This issue hasn't been resolved - it wasn't clear whether it was my code that was causing the problem, or whether the problem is in the ANE - and I ended up suggesting that we switch our focus to another issue, resolve that one first, then return to the first issue...

But perhaps it would be helpful to you and Michael to compare notes ...  ?

[William Spence]

HaHa!! Your issue looks to have been removed from github. Michael and I have been comparing notes all week and I have been unable to find traction. I thought I would try another forum to look for some suggestions. It is really hard to make money with an app if you can’t make a purchase.

Any other thoughts how I could debug this? I have attached my tablet to a Mac and ran it with Console to collect some logs. But the information is cryptic to me.

I just don’t understand why an app can work when placed directly on a tablet, but not when loaded through TestFligh?? Is it the difference between a sandbox vs productionsandbox vs production environment??

[marchbold]

Hi, The Media Player issue hasn't been removed you just probably don't have access to the Media Player extension repository. This issue is a hard one to isolate as we haven't been able to replicate and seems to only happen in this app.

@William I think you have isolated your issue to conditional compilation? There really shouldn't be much difference between a test flight release and a local development build apart from the normal production / development profile and info addition changes.

If there are issues with TestFlight in-app purchases then the most common cause is related to the user logged in on the device. We suggest signing out of the AppStore on the device and making sure you are using a valid test user, installing it through test flight.

[William Spence]

OK, I think I am finally narrowing in on what the problem finally is and I would have never guessed.  I develop on a Windows machine, and it is such a process to compile and move it over to a Mac, and upload it to the app store for testflight and wait 15 minutes till it was ready to test that I would make several changes before each test, making it hard to narrow in on the exact culprit.  In my final analysis, I do not believe it was conditional compilation, I believe it was my switch statement in my purchases_updatedHandler.

I have never used a switch statement before.  Between a few of the cases, I had some conditional logic with enough code that I put the information between brackets like the following:

case Purchase.STATE_CANCELLED:

        {

                trace("purchase cancelled");

                InAppBilling.service.finishPurchase(purchase);

                if (isThisARenewal == false) {

                        this.currentState = "signUp";

                } else {

                        PopUpManager.removePopUp(savingPopUp);

                }

                break;

        }

Perhaps I needed to have the "break;" outside of the brackets, but apparently brackets are totally uneccessary, so I removed them all, and now I am happily getting all the authentications that I desire.  I was so frustrated by this I thought I might explode.  This turned out to be straight up silly.  Sometimes I love programming, sometimes I do not.  Still don't understand why the switch statement would process in debug mode and not in final release with this switch statement.

[rewb0rn]

We have experienced one or two times bugs in the release compilation for .ipa from Air where code just plain does not work as expected. We had a function call in which return someValue; always returned false, we had to change it to if (someValue) return true; else return false; to fix it. There seem to be rare cases where the release ipa compilation just produces bugs in the code translation. You do not find them in debug mode, because in debug mode, the AS3 code is still interpreted and the errors seem to come into play only during compilation from AS3 to objective C. So yes, hard to find bugs you continue to scratch your head over after you find them.

[William Spence]

That totally makes sense, I guess it slipped my mind that one was interpreted and one was translated.  I just figured they were the same app.  What a frustrating experience.

Just in case, remember that if you use a switch statement, not to put brackets around any code under any case statements like this:

Switch(foo) {

     case bar:

          {

               // Some code

               break;

          }

}

The brackets are unnecessary. This totally broke my app.

[marchbold]

Have you tried debugging using ipa-debug rather than ipa-debug-interpreter as your iOS package target?