iOS/iPhone: in-app purchase sandbox broken while app in “rejected” state?

Question

(See MAIN THRUST below to skip to the main thrust of my question.)

My iOS app was rejected in the Apple review process for a minor reason that was easy to fix.

However, I wanted to give the new build a once-over testing, including retesting our in-app purchase (there is only a single purchasable item in the app).

And now the app crashes when doing the initial retrieval of the product information. It never crashed in this way before, and the code hasn't changed since we successfully tested the in-app purchase in sandbox mode many times. (In fact, no code changed at all between the initially submitted version and this version with the minor fix; the fix was just an info.plist setting change.)

To complicate matters, I'm using the Airplay/Marmalade SDK for building the app, and they wrap the Objective C calls and callback mechanism with their own API and callback mechanism. However, this wrapper is very thin, so I hope/believe that this is really a general iOS/in-app purchase question, not something specific to Marmalade.

So, as I say, it's crashing somewhere between the time I make the Marmalade call to retrieve product information and the time my (C++) callback should be called. (I.e., somewhere between the time that Marmalade calls [productsRequest start] on an SKProductsRequest object, and the time productsRequest:didReceiveResponse() is called and Marmalade calls me back in turn.)

MAIN THRUST of my question:

My app is in "rejected" state on iTunesConnect. Furthermore, when I look at the in-app purchase item itself in iTunesConnect, it's also marked as "Rejected". However, I've already discussed my in-app purchase with Apple during the review process, and it is my belief that the in-app purchase itself works fine for them, and the only remaining problem was the minor issue that I've already fixed (this is what their rejection details said: just that one item).

So: I need to understand whether, when my app (and its associated in-app purchase) are in this "rejected" state pending a new binary upload from me, it's tricky (or maybe impossible) to re-test the in-app purchase, and my best course of action is just to resubmit the app with the minor fix and have faith that (since it's the same code that worked during normal testing when things weren't in the rejected state) the state of the in-app purchase will work itself out once Apple resets everything to test the new binary.

Or is there something different I should do at this point that would allow me to re-test the in-app purchase?

I was thinking of asking Apple in the iTunesConnect correspondence, but I didn't want to introduce any complications with them, since the review process has been amazingly fast and efficient so far.

Answer 1

I got a reply from Apple tech support on this:

I'm responding to your question below regarding in app purchase and the issue where the product preflight process now fails. The answer to this issue is documented in Tech Note 2259 - "Adding in app purchase to your iOS application". http://developer.apple.com/library/ios/#technotes/tn2259/_index.html

In the FAQ section there is the following list of reasons for this issue

Why are my product identifiers being returned in the invalidProductIdentifiers array? Your product identifiers may be returned in the invalidProductIdentifiers array for one or more of the following reasons:

You did not complete all the financial requirements (see the "Contracts, Tax, and Banking Information" section of this document). You did not use an explicit App ID. You did not use the Provisioning Profile associated with your explicit App ID. You did not use the correct product identifier in your code. See Technical Q&A, QA1329, 'In App Purchase Product Identifiers' for more information about product identifiers. You did not clear your In App Purchase products for sale in iTunes Connect. You might have modified your products, but these changes are not yet available to all the App Store servers. If you or App Review rejected your most recent binary in iTunes Connect.

Note the last reason - which applies in your case. The solution is - when you want to test the application, you will need to "temporarily" upload a copy of your application to iTunesConnect so that the application state is no longer "rejected". Instead it will be in the "pending review" state. Go ahead and perform whatever testing you need, then assuming the application still needs work, self reject the application so that it doesn't reach app review. At some point, you will have a finished product and you will finally submit the application formally.

That response wasn't totally correct in my case. I got a separate reply from the app review team. Simply uploading a new binary apparently does not reset the "rejected" state of the in-app purchase item. Apparently they have to manually reset that themselves (at which time I believe both they and I can test it). So currently I have my new binary uploaded but they haven't reset the in-app purchase item yet.

I'll add more to this post when the process is complete...