iOS SKProductsRequest returns products as invalid identifiers

I'm testing my iOS app In-App Purchase module and SKProductsRequest started returning inconsistent results.

On one request it returns my product in "invalidProductIdentifiers" property and after a few requests it returns it as valid in "products" property. I don't see a consistent pattern in this.

I've read TN2259(https://developer.apple.com/library/ios/technotes/tn2259/_index.html) and all the steps are fulfilled, or they seem to be.

My product is a consumable "Ready to Submit", attached to an app version that is in "Prepare for Submission".


I've tested with a different bundle identifier, code signing and provisioning profile from an app where this behaviour dosen't apper, which leeds me to think that there is something in the way my app is configured in iTunes Connect or signed.


Ideas why SKProductsRequest returns my product as invalid sometimes and valid other times?

Replies

I'm seeing this too against the sandbox. If I check to see if products is empty and retry the call to get data, I will eventually receive the actual product in the response.

NOTE: this is not reproducible in AppStore build

The problem which both of you have identified is a bug report issue for iTunes Production Support to investigate. To be clear, this is a case where sometimes the SKProductsRequest works to validate an in app purchase identifier, The call works one times, fails the next, the works again.


To submit a bug report for investigation by iTunesConnect, please use the Apple Developer Bug Report web page - http://bugreport.apple.com.

After logging in, select the iTunesConnect Product.

Fill out the bug report form. In the description section - add the comment -

"check with Rich Kubota for assigning the bug report component/version."

By following these instructions, the Bug Report team will be able to expedite the assignment of the bug report to the iTunesConnect Support team.

In order for the bug report to ber verified, there needs to be evidence of the issue. One way would be to supply an external TestFlight invitation to me, which I could pass along to the QA engineer. A fast means is to capture the console log showing the issue. If you email me at rkubota@apple.com, I will provide the StoreKit profile, along with instructions for installing the profile and capturing the console log from the device. Please include the console log with the bug report.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Any movement on this?


We're also seeing this issue on an application already released in AppStore with working IAPs.


All products are now returning as invalid in the sandbox environment. Production is unaffected, but we're not eager to launch anything to production while this issue is ongoing.


Our Developer License was renewed recently, and we've also refreshed our certificates and provisioning profiles following the renewal. How do you propose we proceed?

The two problems are VERY different. There are many reasons why your IAPs would be returned as invalid products all the time in the sandbox environment. For example, if you did not delete your old version of the app before reinstalling from Xcode or your contracts weren't up to date or you were signed into the production store. There are no reasons for inconsistently returning invalid products. Which is it?

Perhaps they are different, perhaps not – it started intermittent and progressed to a permanent issue. The examples issues you mention are not relevant, as they would not begin as intermittent symptoms.


Regardless, Rick (thanks for the speedy assistance) narrowed the issue down to the sandbox itself, so we're awaiting a fix on that end.

Which is it:


>The call works one times, fails the next, the works again. (RKobota)

>All products are now returning as invalid in the sandbox environment (You)


You also wrote:

>Our Developer License was renewed recently, and we've also refreshed our certificates and provisioning profiles following the renewal.


The intermittent problem is (most likely) on Apple's end. But it is quite easy to have a device that works for awhile and then fails consistently - and that is (most likely) not on Apple's end. More likely the user loaded a production version of the app on that device and then overlaid it with an Xcode version or failed to approve a new contract amendment or any one of a bunch of things and then "(a)ll products are now returning as invalid in the sandbox environment".


Good luck with your problem!

Se have the exact same issue; since our dev account renewal, all inapp purchase products are returned as invalid.

Is the issue identified and can be easily fixed ?

Have you deleted old builds and logged out of the App Store before reinstalling from Xcode? Have you checked your contracts to be sure they are all current?

Yes, I did all these actions.

Last week, it worked for a few days but it finally stopped working again yesterday (without changing code, signature or anything).

I hava a same problem. Before I renew dev account there were no problem.

After I have renewd dev account, It returns product identifier as invalid sometimes.

I ran into the exactly same problem after I renewed my dev account. For 90% of the time, I get invalid productIdentifier error from the sandbox environment. However, it seems my app in the App Store isn't impacted, although I haven't submitted new update since this issue happened.


Has anyone submitted update after they notice this IAP issue in sandbox environment? Did IAP work in the update?

I'm having exactly the same issue. Renewed our Developer License automatically and all products immediately returned as Invalid Product Identifiers. I haven't released the new version of the app as I am concerned this will affect the production level app. Does anyone have any thoughts on this?

Have you deleted old builds and logged out of the App Store before reinstalling from Xcode? Have you checked your contracts to be sure they are all current?

Hello. Have you solved the problem? I've got the similar one.