n/t

Hi, the problem comes and goes for us. See also: https://developer.apple.com/forums/thread/678599 A bit frustrating.

According to the 503, something is wrong with the encryption server. It doesn't throw exceptions if remove mlmodel encryption. Meaning I remove the compiler flag "--encrypt model.mlpackage key.mlmodelkey". But I can't ship an app with encryption disabled... so I'm stuck with a non functional app

Hi, I'm having this problem in production. Can't generate new keys. App in production is throwing exceptions.

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.

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.

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.