Hello Friend, Did you check that the status of your IAP packs is Approved? Because on Testflight you can purchase packs/product_ids that have not been approved by Apple.

The answer marked as correct is a good workaround, but it is not the ideal correct solution. The correct solution for this issue, if your app is using Game Center, is to: regenerate your provisioning profile for your app (this will add the Game Center entitlement com.apple.developer.game-center in the provisioning profile) add the Game Center entitlement com.apple.developer.game-center in your entitlements file in Xcode. If you want more context for this change from Apple, please read: https://developer.apple.com/documentation/Xcode-Release-Notes/xcode-14-release-notes

Im also having the same issue trying to upload using the Transporter app for Linux. Using the macOS one works perfectly, but on linux i get the same error: ERROR ITMS-90529: Invalid package. Applications built with sdk 9.0 or later must be packaged as proper IPA files

Friend i dont know what's going on exactly, i also expected to receive the warning email soon after upload, but i didnt get any warnings for my app. I do have a friend who got the email though, i think he got it soon after the upload to testflight and it looks something like this: We noticed one or more issues with a recent submission for TestFlight review for the following app: • [redacted] • Version 1.3.2 • Build 81 Although submission for TestFlight review was successful, you may want to correct the following issues in your next submission for TestFlight review. Once you've corrected the issues, upload a new binary to App Store Connect. ITMS-91053: Missing API declaration - Your app’s code in the “PlugIns/blaaaa.appex/blaaaa” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

Judging by the nature of your question, I assume you're not a developer so I'll answer this as non-technical as I can. As an app developer, you are still responsible for all the code inside your app, third-party or in-house. So No, thirdparty and firstparty in-house sdks are the same in the eyes of the law. That being said, for in-house sdks you have the advantage of choosing how you want to deal with the Privacy Manifest requirement: code dependency vs binary dependency, static linking vs dynamic linking, use whatever packaging format you want (xcframework/staticlib (.a)/.framework), etc. If you have a ton of in-house static libraries/frameworks that you just dont want to update and they do not require being embedded inside the app bundle, you can just declare all the Private Reasons APIs Usage inside the App's privacy manifest. Hope this helps! Cheers!

I'll try and answer your question the best i know how, since you'll probably not hear anything from any official source :P My best guess is that in order to determine what APIs that require reasons your app uses, Apple just runs a script with the nm CLI command that inspects your game binary and all the other binaries in your app bundle like the frameworks in the Frameworks folder. If you run nm on your MyApp.ipa/Payload/MyApp.app/MyApp binary, you'll probably find the NSUserDefaults class there being used. It'll show up like "U OBJC_CLASS$_NSUserDefaults". When you generate the Privacy report, if the third-party SDK is embedded & signed inside your app, it'll show up in the MyApp.ipa/Payload/MyApp.app/MyApp/Frameworks folder and the privacy manifest stuff will correctly be shown in the Privacy Report generated by Xcode. Except for NSPrivacyAccessedAPITypes, they dont show up in the Privacy Report. Since it is a third-party static framework, by default, Xcode is configured to remove these static executables from embedded frameworks to ensure that your app bundle is as lean as possible (see REMOVE_STATIC_EXECUTABLES_FROM_EMBEDDED_BUNDLES setting). Also because it is a static framework, it gets incorporated into the binary of the main executable. As a result of all of this, you've now ended up with your app's executable containing symbols for NSUserDefaults API, your app's privacy manifest is missing the declaration of this API, your third-party static framework does not have the binary there, so apple doesn't find the NSUserDefaults API usage in it , and the privacy manifest of your third-party framework declared the NSUserDefaults API even though apple cannot check the framework's binary. So, if you ask me , it's a bug, Apple should merge the privacy manifests of static embedded frameworks with the privacy manifest of the main app. As for steps to ensure that Apple reviews the Privacy manifest of the third-party SDK, if you see NSPrivacyCollectedDataTypes from a privacy manifest correctly show up in a Privacy Report generated with Xcode, you can pretty much bet you've done your job correctly and Apple is reviewing it. I hope this helps. At least, this is how i understand it, im not an expert. Have a great day, -Sisky

If you wish to do this properly, see this tread on the Apple forums which links to this guide about "Using a Link Map to Track Down a Symbol’s Origin" but also contains a few additions to the guide. However, you can also try your luck and just do a text search for each API through your pods and see what comes up, but you've no guarantee you haven't missed something.

First thing you should do is make sure that the PrivacyInfo.xcprivacy file actually exists. This means that after you create the iOS App archive , you need to check that the .ipa build that you actually submit to the AppStore contains the privacy manifest at path: MyApp.ipa/Payload/MyApp.app/PrivacyInfo.xcprivacy. You can also check this by generating the Privacy Report from the Organizer Window in Xcode, and , if the privacy report can be generated, it means that Xcode found it in the correct place. Another thing to check in Xcode in order to be sure your privacy manifest resource is copied inside the app is to select the target that you want to build -> go to Build Phases -> Copy Bundle Resources and make sure you find the privacy manifest in there somewhere.

Hey @SlippedCognitive , I've been having the same issue. If you are to take things literally, Apple has said "Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update." So, in other words, if your app already included those "commonly used third-party SDKs" before Spring 2024, you should be fine. You dont have to believe me but it seems that Unity is saying the same thing to their users, see "What does this mean for updates of already published apps?" section on their forums, im not allowed to link it here. As for your own frameworks that you have embedded inside your app, if they are statically linked and they use an API that is not used in your app, you have to have a privacy manifest or you'll get a warning. Otherwise, for dynamically linked and embedded frameworks, it does seem like Apple doesnt care about those atm but i cant find any confirmation for that to be the case. Seems Apple is purposely vague with their statements.