ditto here...

Follow-up: just as mysteriously as it began to happen, the issue stopped. I checked production builds back 2 months and confirmed the issue existed in those builds. I can only assume that there was something going on with the sandbox store that has been addressed since I posted my initial question.

(In Test Flight) I am intermittently getting "Cannot connect to iTunes Store" errors. This happened yesterday as well and then just went away. I've rolled testing back the current production build in Test Flight and the errors occur with that build as well. Thankfully, all appears fine in Production. There is certainly something going on with the Sandbox.

The issue re-appeared for me yesterday, but is only happening on simulators. When I test on actual devices, the sandbox store is reachable as expected.

Situation resolved. Just got received a TestFlight notification and installed the build that was uploaded hours ago.

I get that this post is almost a year old, but it's relevant to my question and "PBK" sounds well-informed on this topic.I do not have a history of IAP Consumable IAP refunds, but I did just experience a case where 6 purchases of the most expensive offering were refunded on the same date. I can see from my logs that there is only one install that has made a large number of that particular package. While I accept that it's possible that there was a "run" on that package by multiple users, I doubt that is the case given a lack of history of refunds. When I reached out to Apple, I was referrred to "Schedule 2". I don't see anything in "Schedule 2" that authorizes Apple to refund Consumables purchases. I see several mentions about refunding Subscriptions, but my app does not sell subscriptions.Is there nothing that obligates Apple to help developers to prevent basically giving away their Consumable offerings? This particular batch of refunds was pretty expensive to the bottom line of my small app and I'm feeling pretty frustrated with Apple's apparent lack of concern or desire to help to tighten things up.

Update: I am "extremely concerned" that as soon as I applied the IOS update for 14.2 to the iPad test device, Test Flight worked like a charm. I am 100% certain that was the fix because it failed immediately before the update and worked immediately after the update. It was not caused by a reboot, because I had rebooted the device multiple times in an attempt to install from Test Flight. I don't know if that is because of an Apple desire to force the device to be updated or an indication that the version will only work on other devices that have been updated to 14.2. Interestingly, the Test Flight release did install successfully on a test iPhone that is not running 14.2. Hopefully, Apple will realize that developers need to keep later versions of their operating system installed on test devices in order to validate backwards compatibility.

Same Issue. Checked the Apple Systems Availability and everything is green...huh?

metehandemircioglu's solution worked for me as well.

This sounds like great news to me! But to be clear the I completely understand you: I should disable bitcode in my app (I’ve seen guidance on that). Then, the local dsym files can be used with Crashlytics?

Bueller? Bueller? No updates after 2 weeks? Issue still exists.

I'm getting this error message, too, but it appears to be benign. How awesome would it be if the folks who make the changes to XCode ALSO wrote some apps?

One feature of my app is consistently crashing on 16.3.1 and the crash manifests as a device "reset" so there are no logs or crash reports. A simulator would be extremely valuable for cases like this. Everything appears to be good on 16.4 and 15.5. I don't want to attach the device to Xcode because I try to use it solely for TestFlight installs in order to ensure that foundational updates to the app are sequentially installed and tested. In all likelihood, I'll have to upgrade the o/s earlier than I would like, in order to confirm that the issue is specific 16.3.1 and not to the device itself. I hate not identifying a root cause because it's almost guaranteed that the issue will raise it's head again in the future and potentially be even more critical.

My question requires an interpretation of the language in 5.1.1 (iv) because I will be using the Google UMP to collect UE GDPR for my ads that are served from AdMob. Non-UE users will still default to Apple's ATT. Effective in January 2024, if GDPR consent is not fully granted, or if it is not specifically configured using "Manage Options" in such a way as to allow AdMob to serve ads, no ads will be delivered from AdMob. The user-interface from the Google framework is so complicated and convoluted that it will be virtually impossible for a user to define the correct "configuration" - even if they want to. That being the case, any selection other than "Consent" will effectively disable ads from AdMob; thus preventing developers (who rely on AdMob) from generating ad revenue when GDPR applies. My question is whether it is acceptable under 5.1.1 (iv) for me to restrict access to my app unless the user provides the necessary consent to meet AdMob's requirements? Would restricting the app to a "limited evaluation" be considered "forcing the user to consent to unnecessary data access"? Google has indicated that I have the right to restrict my app in the Play Store, but I need a "judge's ruling" for the App Store. Thank you!

I started to receive this warning because Firebase was getting initialized before my SKPaymentQueue delegate