IAP are wrong in App Store today

My app:

  • has been published to the app store for a month
  • has 2 IAP (let's call it IAP1, and IAP2)
  • had an update that was approved yesterday Sep 25, 2:08pm pacific

Just this morning, I went to the app store and downloaded my app to make sure things are okay.

I went to purchase IAP1, and it shows the price and description for IAP2. I went to purchase IAP2, and it shows the price and description for IAP1.

The IAP's are switched!

  • Button1 goes to IAP2
  • Button2 goes to IAP1

So the first thing I thought was my code was wrong. To debug:

  • I downloaded the same app build from TestFlight and the IAP1 and IAP2 are NOT switched.
  • I do not have code that changes behavior between sandbox and production.
  • I reloaded the production build and changed the price of IAP1 and IAP2 from App Store Connect, and observed that IAP1 is set to IAP2's price and vice versa. Which in this scenario makes sense. Button1 opens StoreKit dialog for IAP2 (in production), and displays the updated price for IAP2 since IAP2's price is changed in App Store Connect.
  • When I tap Button1, it opens StoreKit dialog for IAP2, and when I tap purchase, it indeed activates/enables IAP2's functionality in my app.
  • Restoring both IAP's work perfectly fine. Restoring IAP1 activates IAP1, etc.

If this was happening in all environments dev/sandbox/production, then I'd say it's a bug in my app. But everything is ok in the same build from XCode, TestFlight, and the StoreKit dialog is switched only in production. And it only started happening (that I have observed) this morning. The last time I know for sure I checked this behavior was last week. The update I pushed yesterday had zero changes to IAP.

Anybody else seeing this?

Update I've discovered the following.

  • I went to App Store Connect and disabled IAP2 by unchecking "Cleared for Sale"
  • In production app build, tapping on Button1 opens Store Kit dialog for IAP1.
  • In production app build, tapping on Button2 crashes app.

Disabling IAP2 does not affect dev/sandbox, there is no change in behavior likely because unchecking "Cleared for Sale" does not enable/disable the IAP in sandbox.

This is a slight improvement because previously:

  • Button1 opened Store Kit dialog for IAP2
  • Button2 opened Store Kit dialog for IAP1

...which would confuse customers.

The fact that this is only happening in production, and that disabling IAP2 from the "App Store Connect" site fixed the StoreKit dialog for IAP1 really indicates to me that this is an App Store bug.

I've received wonderful help by someone (I'm not sure if this person wants to be named):

I've seen a couple of reports of such incident. So far the explanation is that the app makes an assumption of the ordering of the response from SKProductsRequest. This is an invalid assumption. In the response products array, you can't assume that the order of the identifiers is the same as what you sent in to SKProductsRequest. If you can show evidence that this is not the case, then add the evidence to the bug report. This issue would be for the App Store Server team to investigate.

And I believe this is indeed what we are (incorrectly) doing in our app. I'm guessing it's just been a matter of luck that our app has worked until now, or something changed in the app store to rearrange the order - but the solution is to not rely on the order response from SKProductsRequest.

If you are observing some products prices while testing in sandbox and TestFlight are not matching what was configured in App Store Connect, please report these in a ticket and reply with the FB#. http://feedbackassistant.apple.com

While we investigate sandbox, not that production prices should 100% match what is configured in App Store Connect. Meanwhile any testing with Xcode StoreKit testing, those will be using prices from the local StoreKit configuration file and does not sync with App Store Connect.

The problem is not that the prices are different between sandbox and production. The problem is that IAP1 and IAP2 are switched in production in the purchase confirmation dialog. The problem appears to be caused by the fact that we are relying on the order of the response coming back from SKProductsRequest to be consistent, which was an incorrect assumption.

Hello, I am having the same issue where my sandbox prices are not matching what is configured in App Store Connect.

Here is my FB# FB2594652

IAP are wrong in App Store today
 
 
Q