Why did Apple reject my AdMob app for a missing privacy manifest?

You shipped a build to App Store Connect, walked away to make coffee, and came back to a rejection email under Guideline 5.1.1 with the technical line ITMS-91061: Missing privacy manifest for GoogleMobileAds. The build compiled cleanly, the AdMob ad units serve fine in TestFlight, and yet App Review refuses to advance the binary. The cause is almost always a small mismatch between the Google Mobile Ads SDK version, the way the framework is linked, and Apple's privacy manifest expectations.

Short answer

Apple rejects an iOS build with ITMS-91061 when the Google Mobile Ads SDK in the bundle does not contain a PrivacyInfo.xcprivacy file. The fix is to update to Google Mobile Ads SDK 11.2.0 or higher, set the framework's Embed setting to Embed and Sign in Xcode, and check the generated Privacy Report so that GoogleMobileAds is listed alongside its data category declarations. Mediation adapters need the same treatment because Apple inspects every embedded framework, not only the main SDK.

What you should know

• ITMS-91061 is the technical code; Guideline 5.1.1 is the policy header. Both appear together in the rejection email, and they describe the same root cause.
• Google Mobile Ads SDK 11.2.0 was the first version with a bundled privacy manifest. Anything below that line will trip the check, even if your code is otherwise clean.
• Apple inspects every framework in your IPA. GoogleMobileAds, GoogleUserMessagingPlatform, and each mediation adapter are checked separately.
• An app-level PrivacyInfo.xcprivacy does not substitute for an SDK-level one. Both live in your bundle for different purposes.
• The Privacy Report in Xcode is the same artifact Apple inspects on submission. Reading it before you upload is the fastest way to predict ITMS-91061.
• Required reason APIs are part of the same enforcement wave. If your own code reads UserDefaults or system boot time without a declared reason, you can be rejected for that as well.

What does Apple actually check when it flags AdMob under Guideline 5.1.1?

Apple's App Review Guidelines name Guideline 5.1.1 as the legal data collection and storage rule that requires you to disclose what data your app gathers and why. The automated layer that runs against every upload to App Store Connect inspects the bundle for a set of expected privacy artifacts, then maps a failure to ITMS-91061 with the specific framework name attached. Per Apple's privacy manifest files documentation, a PrivacyInfo.xcprivacy file declares four things: the types of data the SDK collects, the linking of that data to user identity, the tracking purpose, and the required reason APIs the SDK accesses.

In the AdMob case the scanner finds the GoogleMobileAds.framework file inside Frameworks/, opens it, and looks for a PrivacyInfo.xcprivacy at the framework root. If the file is absent, the build is rejected before a human reviewer is involved. The email back to the developer reads as if it were a Guideline 5.1.1 finding because that is the policy chapter the missing data declaration violates, but the underlying check is a binary file presence test, not a content review.

This matters because two builds can look identical in source and behavior, and only the SDK version determines whether the build clears the gate. A developer who downgraded the pod accidentally, or whose Swift Package Manager cache is pinned to an older revision, will see the rejection without any change to their own code.

Which Google Mobile Ads SDK version actually ships the privacy manifest?

Google introduced privacy manifest support in Google Mobile Ads SDK 11.2.0, per the AdMob iOS data disclosure page. Versions in the 10.x line and lower do not carry the file, which is why teams who postponed the major version upgrade are seeing ITMS-91061 most often. The privacy manifest inside GoogleMobileAds declares six data categories that the SDK can collect at runtime.

If your App Store Connect data disclosures answer No to any of those categories, you need to align the answers with what GoogleMobileAds declares. Apple cross-checks the app's user-facing privacy questionnaire against the manifest data found in embedded SDKs at review time, and a mismatch becomes a second Guideline 5.1.1 problem even after you fix ITMS-91061.

How do you confirm the manifest is actually inside your archive?

The most reliable check sits inside Xcode itself. Open the Organizer window, select the archive you intend to submit, right-click, and choose Generate Privacy Report. Xcode walks the embedded frameworks, gathers every PrivacyInfo.xcprivacy file it finds, and prints a PDF that summarizes declared data categories per framework. If GoogleMobileAds appears with its six data categories listed, the SDK manifest is in place. If GoogleMobileAds is missing from the report entirely, the file did not embed and you will fail App Review on upload.

The most common reason a manifest exists in the pod cache but not in the archive is that the GoogleMobileAds framework is linked as Do Not Embed rather than Embed and Sign. The framework binary is found at build time but the resource directory, including the manifest, is never copied into the IPA. Switching the General tab setting to Embed and Sign rebuilds the archive with the manifest inside.

Another failure mode shows up in projects that use static linking through use_frameworks! :linkage => :static in the Podfile. Static linking strips resource bundles by default, and the AdMob privacy manifest is delivered as a resource. Setting install_pods to merge static resource bundles, or switching the AdMob pod to dynamic linkage, keeps the manifest discoverable.

For builders who want an external automated read of their compiled IPA before submission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS for no-code and vibe-coded apps, with a specific check for missing privacy manifests across embedded SDKs.

Do mediation adapters need their own manifests too?

Yes, and this is where teams that thought they fixed the rejection often hit a second wall. Apple scans every framework in your IPA independently, so each AdMob mediation adapter (Meta Audience Network, AppLovin, Unity Ads, Mintegral, IronSource, and others) needs its own PrivacyInfo.xcprivacy. The Google adapter pod versions track the underlying SDK versions, but adapter releases often lag behind core SDK releases.

The versions above are directional, drawn from adapter release notes patterns; verify against the Google Mobile Ads adapter release pages for current numbers before pinning. The point is that you have to update each adapter you actually ship, not only the AdMob core SDK. App Review will name the specific framework that failed in the ITMS-91061 message, so read the email carefully: a rejection that says Mintegral, not GoogleMobileAds, means the AdMob update was already correct.

What changes if the app is built with FlutterFlow, Expo, or React Native?

The rejection mechanism is identical, but the version pins live in different files. For FlutterFlow apps, the google_mobile_ads Flutter package wraps the native SDK, and the package version determines which native AdMob version the Pod resolves at build time. The google_mobile_ads package began shipping with privacy manifest support in versions that depend on the underlying iOS SDK at 11.2.0 or higher; older Flutter package versions will pull a stale native SDK even if your Flutter SDK is current.

For Expo projects, the react-native-google-mobile-ads package is the most common wrapper, and the Expo prebuild step writes the Pod entries into the iOS folder. Run npx expo prebuild --clean and inspect ios/Podfile.lock for the Google-Mobile-Ads-SDK line. The pinned version is what App Review will see. For bare React Native, the pod is added directly, and a pod update Google-Mobile-Ads-SDK is enough to lift the version, followed by a fresh archive.

In every wrapper case the rule is the same: the native AdMob version is what Apple scans, not the wrapper version. A FlutterFlow app on the latest Flutter package can still ship a 10.x native SDK if the package itself is old, and Apple will reject it for ITMS-91061 with no mention of Dart or Flutter in the message.

One more piece of documentation worth flagging: Apple maintains a list of commonly used SDKs that require a privacy manifest, and GoogleMobileAds is not currently on that published list. Some developers read the absence as permission to ship without a manifest. That reading is wrong. The published list names SDKs whose manifest is enforced on update submissions even when no new SDK is added, while every SDK that accesses a required reason API or collects data still needs a manifest. GoogleMobileAds accesses several required reason APIs (UserDefaults for ad personalization state, system boot time for performance metrics, and disk space queries for caching) and collects the six data categories listed earlier. That alone triggers the manifest requirement under Apple's general privacy manifest documentation, independent of the named list.

What to watch out for

• A clean Privacy Report in Xcode is not a green light on its own; it confirms the SDK manifest is embedded, which is the most common fault, not the only one. App Review still verifies your App Store Connect data disclosures against what each manifest declares.
• Pod cache poisoning is real. If a teammate ran pod install with an outdated Podfile.lock, your local 11.x update can be silently downgraded back to 10.x. Always check the lock file after a fresh install.
• Mediation adapter versions move independently. An opt-out adapter that you stopped using but never removed will still be inspected at App Review and can fail the build.
• The CocoaPods source repo can lag behind Google's SPM source. If you switched from Pods to Swift Package Manager mid-project, the resolved version may not match what you expected.
• An app-level PrivacyInfo.xcprivacy is still recommended even after the SDK side is clean. Some teams skip it and then face a second Guideline 5.1.1 rejection for direct API usage in their own code.

Key takeaways

• Treat ITMS-91061 as a version-pin problem first. Update Google Mobile Ads SDK to 11.2.0 or higher, confirm the framework is embedded and signed, and regenerate the archive.
• Read the rejection email carefully. The framework name in the message tells you whether the issue is the AdMob core SDK or a specific mediation adapter, and the fix differs for each.
• Use Xcode's Generate Privacy Report on the archive before every submission. The PDF that Apple inspects is the same one you can read locally.
• For wrapped builds (FlutterFlow, Expo, React Native) check the resolved native SDK version in Podfile.lock, not the wrapper version, before you submit.
• Some teams outsource the pre-submission scan to platforms like PTKD.com (https://ptkd.com) to flag missing privacy manifests, stale mediation adapters, and required reason API usage in one pass before the build reaches App Store Connect.