If your build came back this week with a Guideline 5.1.1 rejection naming the Google Mobile Ads SDK and a missing privacy manifest, you are looking at the most common shape of this rejection in 2026. The reviewer is not asking you to remove ads. They are saying the GoogleMobileAds binary inside your bundle does not declare what it touches under Apple's required reason API rules, and Apple has stopped letting that pattern through automated review.
Short answer
The Guideline 5.1.1 rejection for a missing AdMob privacy manifest fires when the Google Mobile Ads SDK in your app does not ship a PrivacyInfo.xcprivacy file, or when the SDK version predates manifest support. Google added manifest declarations in Mobile Ads SDK 11.2.0 in April 2024. Apple's policy on privacy manifest files blocks any new app or update that ships a privacy-impacting SDK from the published list without a manifest. Updating GoogleMobileAds to the current 12.x line, embedding the framework correctly, and matching the required reason API entries in your own PrivacyInfo.xcprivacy clears the rejection most of the time.
What you should know
- GoogleMobileAds is on Apple's published SDK list. Apple's list of commonly used SDKs that need a privacy manifest names GoogleMobileAds explicitly, alongside Firebase, Facebook SDK, and the major analytics frameworks.
- Mobile Ads SDK 11.2.0 is the earliest version with manifest support. Anything older, including pinned versions in older CocoaPods or SwiftPM lockfiles, does not contain a PrivacyInfo.xcprivacy file inside the framework.
- The error code is ITMS-91061, but the human rejection often cites 5.1.1. Apple's automated layer flags ITMS-91061 in App Store Connect. The human letter that follows uses Guideline 5.1.1 Data Collection and Storage as the policy frame.
- Required reason API entries are separate from the SDK manifest. Even with the right SDK version, the app's own PrivacyInfo.xcprivacy must list the disk space, user defaults, file timestamp, and system boot time reasons that match what your code touches.
- Embed and Sign matters for manifest discovery. Frameworks set to Do Not Embed sometimes fail to ship the manifest into the archive, and Xcode's privacy report comes back empty.
What does the rejection letter usually say?
The standard letter cites Guideline 5.1.1, Data Collection and Storage. The body of the letter names the SDK that triggered it, almost always one of three forms: GoogleMobileAds, Google-Mobile-Ads-SDK, or the umbrella package name when the team integrated through Firebase. The letter then asks for a privacy manifest that declares the data types collected and the required reason APIs accessed.
When the rejection is automated, it surfaces inside App Store Connect as the ITMS-91061 validation error: "Missing privacy manifest". Apple's developer forum thread on ITMS-91061 confirms that the rule began as a warning in spring 2024 and was upgraded to a hard block on February 12, 2025 for new apps and updates that include a privacy-impacting SDK. The 5.1.1 letter is the version sent when a human reviewer reads the same finding and writes it in policy language.
Why does Apple cite 5.1.1 instead of the ITMS code?
The ITMS code is the validator's internal identifier. The reviewer letter is written in App Review Guideline language because that is the policy frame the team can appeal under. Guideline 5.1.1 covers the broader rule that an app must accurately disclose what it collects. A missing privacy manifest is the technical evidence that the disclosure is incomplete: Apple cannot match the App Privacy nutrition label against an SDK that did not declare its own data collection.
In practice, you will see both. The CI pipeline shows the ITMS warning during upload. The human rejection cites 5.1.1 a few hours later. Both point at the same fix.
Which Google Mobile Ads SDK versions ship the privacy manifest?
Google added manifest support in Mobile Ads SDK 11.2.0, released in April 2024. The 12.x line, shipped through 2025, refines the manifest entries and trims the required reason API surface the SDK touches internally. Older versions, including the 10.x and 11.0.x lines that many projects pinned during the WKWebView transition, do not contain a PrivacyInfo.xcprivacy file inside the GoogleMobileAds framework.
According to Google's AdMob data disclosure documentation, the developer is responsible for checking the privacy manifest and ensuring the app's data disclosures match. The same page notes that when using mediation, every adapter and mediated SDK must independently ship its own manifest. A single mediation adapter on an older version is enough to fail the rule.
What does the GoogleMobileAds privacy manifest actually declare?
The GoogleMobileAds manifest declares the data types the SDK collects (advertising data, device identifiers, IP address, performance signals, crash logs), the purposes (advertising, analytics), and the required reason APIs it accesses. The required reason set typically covers four entries:
- File timestamp APIs under category NSPrivacyAccessedAPICategoryFileTimestamp
- System boot time APIs under category NSPrivacyAccessedAPICategorySystemBootTime
- Disk space APIs under category NSPrivacyAccessedAPICategoryDiskSpace
- User defaults APIs under category NSPrivacyAccessedAPICategoryUserDefaults
The specific reason codes are listed in Apple's required reason API documentation. The manifest inside the SDK declares the reasons for the SDK's own access. The app's own PrivacyInfo.xcprivacy declares the reasons for any access the app itself makes. The two manifests stack.
What is the fix sequence that actually clears the rejection?
The fix has five parts. Each part has its own failure mode that produces a re-rejection.
| Step | What to do | Common mistake | Where it surfaces |
|---|---|---|---|
| 1. Update GoogleMobileAds | Move to 11.2.0 or later, current 12.x preferred | Stale lockfile pins 10.x or 11.0.x | ITMS-91061 on upload |
| 2. Update mediation adapters | Bump every adapter (AppLovin, ironSource, Unity, Meta) | Adapter older than the core SDK | Mediation debugger warning |
| 3. Verify embed setting | Set GoogleMobileAds framework to Embed and Sign | Set to Do Not Embed, manifest missing in archive | Empty Xcode privacy report |
| 4. Add app PrivacyInfo.xcprivacy | Declare app-side required reason API entries | Relying only on SDK manifests | 5.1.1 letter cites missing app declaration |
| 5. Match App Privacy nutrition label | Update App Store Connect to reflect AdMob data types | Label still says no third-party collection | 5.1.1 letter mentions mismatch |
For most React Native, Expo, Flutter, and FlutterFlow projects the first three steps live in the iOS native layer and may need a clean build and a fresh pod install. For builders that compile in the cloud, the SDK version is whatever the platform ships, and the only lever is to wait for the platform to update or to switch to a builder version that pins a recent SDK.
Does AdMob mediation change anything?
Yes. Each mediated SDK ships its own privacy manifest, and Apple checks them independently. Apple's list of commonly used SDKs that require a manifest includes most of the major ad networks: AppLovin, ironSource (Unity LevelPlay), Meta Audience Network, and Vungle. A 5.1.1 rejection naming AdMob can in fact be triggered by an older AppLovin or ironSource adapter pulled in by the GoogleMobileAds mediation graph.
The AppLovin tracker issue #318 documented this exact pattern in 2024, where the mediation debugger flagged a missing required reason API on the AdMob adapter even when the core AdMob SDK was current. The fix is to bump each adapter to a version that ships its own PrivacyInfo.xcprivacy and to verify the per-adapter manifest in the Xcode privacy report.
What to watch out for
A common mistake is to add a single PrivacyInfo.xcprivacy at the app target root that declares it stands in for all SDKs. That is not how the rule reads. Each SDK on Apple's published list must ship its own manifest inside its own bundle. The app-level manifest only covers the app's own code.
A second mistake is to set the framework embedding to Do Not Embed. The frameworks contain manifests, but Xcode does not copy them into the archive when embedding is disabled. The privacy report Xcode generates from the archive comes back empty, and the App Store Connect validator reports ITMS-91061. The fix is to set Embed and Sign on the GoogleMobileAds framework and rebuild.
A third mistake is to assume the App Privacy nutrition label in App Store Connect is independent of the manifest. It is not. Apple cross-checks the manifest declarations against the nutrition label, and a 5.1.1 letter can name a mismatch between the two as the rejection reason even when both files exist. For builders who want to scan a compiled IPA before submission to confirm which SDKs are present, which versions, and whether each one ships a PrivacyInfo.xcprivacy, PTKD.com (https://ptkd.com) is one of the platforms that maps the framework symbol table against the published SDK list and surfaces the gaps in plain language.
Key takeaways
- The 5.1.1 rejection naming AdMob and a missing privacy manifest is the same finding as ITMS-91061 written in policy language. Apple's strict enforcement of the rule has been live since February 12, 2025.
- Google Mobile Ads SDK 11.2.0 was the first version to ship a PrivacyInfo.xcprivacy file inside the framework. The 12.x line is what reviewers expect to see in a new submission.
- Mediation adapters are checked independently. An older AppLovin, ironSource, Unity, or Meta adapter pulled in by the AdMob mediation graph is enough to trigger the rejection even when the core SDK is current.
- The app's own PrivacyInfo.xcprivacy declares the reasons for any app-side access to required reason APIs and stacks on top of the per-SDK manifests. A single app-level manifest cannot substitute for the per-SDK ones.
- Some teams outsource the pre-submission check entirely to platforms like PTKD.com (https://ptkd.com), which read a compiled IPA against Apple's published SDK list and report which frameworks are missing a manifest before App Store Connect does.
