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

Same issue here, but it's no longer sporadic. It's almost every time that I open XCode or a simulator that hasn't been opened before. Is anyone looking into this issue? Failing to select "Keep Xcode version" results in the app crashing.

I created the file "PrivacyInfo.xcprivacy" and included it in my project with the keys that I was notified were required. However, I get the same email complaining that these four entries are missing: NSPrivacyAccessedAPICategoryDiskSpace NSPrivacyAccessedAPICategoryFileTimestamp NSPrivacyAccessedAPICategoryUserDefaults NSPrivacyAccessedAPICategorySystemBootTime Is there something else that's required for the newly added privacy manifest to be recognized during review? The file is currently located at the root directory of my project; next to the .xcodeproj file I'm using XCode 15.2.0

I always get nervous about "renewing certs" because it's a once in a year affair and I don't fully understand the process. I just "follow my notes" and hope I don't mess something up. This year is a little bit different because I started to use "Managed Signing" in XCode by checking the "Automatically manage signing" box in XCode. Normally, I have a "Development" cert and a "iOS Distribution" cert. They were to expire at the end of April. So, after getting a successful update posted to the App Store, I started the update process. I was able to get the two certs I'm used to replaced (and revoked the older certs) and was able to get XCode and my keychain updated. Everything appears to be working fine. "Good to go" for another year! However, there is a "Distribution Managed" cert on my account that is set to expire 2024/04/28. The cert is also designated with an "Automatic Certificate Rotation Date" of 2024/01/29. I have two questions: Am I supposed to do something with this cert since it apparently didn't get "automatically rotated" on 1/29/2024? Should I be concerned about being able to push updates when this cert expires? Given that signing is being automatically managed, do I still need to maintain the 'iOS Distribution" cert? Is it redundant to the cert being used by managed signing? Thanks in advance.

Not sure how I missed this reply. Thank you, Eskimo. But, I still don't know if I'm supposed to do anything about the cert that did not rotate in January as it was schedule to do. It expires in 5 days. Am I supposed to use the link to manually rotate it?

I'm not sure that I count as an In-House (Enterprise) team. At the end of the day, "I'm just a guy, standing in front of an App Store, praying that this cert won't expire and create issues when I try to push another release of my app" ;)

Thanks, Quinn! So long as I will know there is a problem when I attempt to build in XCode, that should be good enough.

Anyone at Apple have an idea on this?