How do I update my privacy manifest for AdMob?

Your iOS build uploaded fine to App Store Connect, then Apple emailed back about ITMS-91053 or ITMS-91056 and pointed at the GoogleMobileAds framework. The fix is not a single switch in Xcode. It is a short chain of steps that sit partly inside your app, partly inside the AdMob framework you bundled, and partly in the way the final binary is packaged.

Short answer

The short answer is to update the Google Mobile Ads SDK to version 11.2.0 or later, confirm the framework is embedded and signed in your app target, then add a PrivacyInfo.xcprivacy file to that target covering the required-reason APIs your own code calls. According to Google's iOS Mobile Ads data disclosure documentation, the SDK has shipped its own privacy manifest since version 11.2.0 (released 14 March 2024), with the current stable line at 13.3.0 as of April 2026. Your app manifest does not replace the one inside the SDK. It sits beside it, and Apple aggregates both files in the App Privacy report.

What you should know

• Two manifest files, one report. The SDK ships its own PrivacyInfo.xcprivacy inside the framework bundle. Your app target ships its own. Apple aggregates them at review time.
• Version 11.2.0 is the floor. Google added manifest support in the 11.2.0 release on 14 March 2024. Older builds cannot pass current uploads.
• ITMS-91053 names the API category. The email lists exactly which required-reason category is missing a declared code, such as NSPrivacyAccessedAPICategoryUserDefaults or NSPrivacyAccessedAPICategoryDiskSpace.
• ITMS-91056 means the manifest file is invalid. Apple's parser rejected the plist, usually because of a missing array, a wrong key name, or a stray character.
• 1 May 2024 was the enforcement date. Apple's privacy manifest documentation set that deadline for required-reason API declarations.
• NSPrivacyTracking is true for AdMob. The SDK manifest sets the tracking flag and lists tracking domains, which means the App Tracking Transparency prompt is required before personalised ad requests.

Why is Apple flagging my AdMob build for the privacy manifest?

The short answer is that the build either ships an older Google Mobile Ads SDK that does not include a privacy manifest, or the framework is included in a way that strips the manifest from the final IPA. The flag is rarely about AdMob missing data declarations. The flag is about Apple's reviewer not finding the file.

The mechanism is in the binary packaging. According to Apple's privacy manifest documentation, the App Store reviews each manifest inside the IPA, the one at the app bundle root and any inside embedded framework bundles. When GoogleMobileAds.framework is added manually and the build phase is left at Do Not Embed, the framework is linked but not copied into the IPA, so the PrivacyInfo.xcprivacy that lives inside it goes missing too.

In practice this is what triggers ITMS-91053 emails for the categories AdMob uses internally. The Google AdMob developer group thread on App Store warnings collected reports from developers seeing the warning right after upgrading to 11.2.0, and Google's mobile ads forum advisor recommended setting frameworks to Embed and Sign in Targets, General, Frameworks, Libraries, and Embedded Content.

The limit is that an Embed and Sign setting alone does not cover required reasons that your own code calls outside the SDK. If your app reads UserDefaults directly, your own PrivacyInfo.xcprivacy still has to declare that category, regardless of what AdMob does inside its framework.

What does the Google Mobile Ads SDK declare in its own PrivacyInfo.xcprivacy?

The short answer is the SDK's manifest declares tracking, lists Google's ad-serving and measurement domains under NSPrivacyTrackingDomains, declares the categories of required-reason APIs the SDK itself calls, and lists the data types it collects. The exact keys live inside the framework bundle, not in Google's web documentation.

The categories the SDK touches, based on the forum reports and the iOS data disclosure page, include NSPrivacyAccessedAPICategoryUserDefaults (the SDK persists state such as the consent string), NSPrivacyAccessedAPICategoryDiskSpace (used during ad caching), NSPrivacyAccessedAPICategoryFileTimestamp (cached creatives), and NSPrivacyAccessedAPICategorySystemBootTime (request fingerprinting). The SDK ships approved reason codes for each.

For collected data, the manifest covers what the iOS data disclosure page summarises in prose: IP address, advertising data, crash logs, performance data, device identifiers, and user interactions. The same disclosure lists how each maps to App Store privacy nutrition label categories, which is the section to mirror when filling in App Privacy in App Store Connect.

The limit is that Google's web documentation does not enumerate the keys line by line. To audit them, open GoogleMobileAds.framework in Finder, right-click, Show Package Contents, and inspect the PrivacyInfo.xcprivacy file directly. The plist editor in Xcode renders it cleanly.

What goes into my own app target's PrivacyInfo.xcprivacy?

The short answer is your app's own manifest covers your own code, not the SDK's. According to Apple's documentation, each third-party library ships its own manifest, and the app manifest does not apply to those libraries.

The mechanism in Xcode is short. File, New, File from Template, filter on privacy, pick App Privacy. Add it to your app target only, not to any SDK target. The file is a property list with four top-level keys: NSPrivacyTracking (boolean), NSPrivacyTrackingDomains (array of strings), NSPrivacyAccessedAPITypes (array of dictionaries), and NSPrivacyCollectedDataTypes (array of dictionaries).

For most builds that bundle AdMob and little else, the app manifest looks roughly like this. Set NSPrivacyTracking to true, because AdMob is bundled and the app benefits from personalised ads. Leave NSPrivacyTrackingDomains empty if you do not call third-party tracking endpoints yourself, since the SDK declares its own list. Fill NSPrivacyAccessedAPITypes with one entry per required-reason category your own code touches, alongside the approved reason code from Apple's published list. Fill NSPrivacyCollectedDataTypes for any data your own code collects beyond what AdMob already covers.

The reason codes are short strings. As documented by Apple's required reason API page, NSPrivacyAccessedAPICategoryUserDefaults accepts codes such as CA92.1 for app functionality and 1C8F.1 for accessing user defaults from the same app group. File timestamp APIs accept C617.1 (display to the user), 3B52.1 (inside the same app), or 0A2A.1 (third-party SDK functionality, only when you wrote the SDK yourself).

The limit is that adding an SDK-related reason to your own manifest is a frequent mistake. If your app code does not itself call file timestamp APIs, but the SDK does, the reason belongs in the SDK manifest, not yours. Duplicating reasons inflates the App Privacy report and makes Apple's review harder, not easier.

How do I verify the AdMob manifest is actually inside my IPA?

The short answer is to archive the build in Xcode, right-click the archive in the Organizer, and choose Generate Privacy Report. The report enumerates every manifest Xcode found inside the archive.

The mechanism comes from Apple's documentation on the privacy report, which lists where Xcode looks: the app bundle root, every embedded framework, every static archive that bundled a manifest. If GoogleMobileAds.framework appears in the report with its own privacy section, the manifest survived the build. If the report says the archive does not contain any PrivacyInfo.xcprivacy files, the framework was linked but not embedded.

In practice, the fix recommended by Google's mobile ads forum advisor in the App Store warning thread is to open the app target, go to General, scroll to Frameworks, Libraries, and Embedded Content, and change the Embed column for GoogleMobileAds to Embed and Sign. CocoaPods and Swift Package Manager handle this by default. Manual integration with a downloaded framework does not.

The limit is that Generate Privacy Report reads only the archive, not the final signed IPA. For a last-mile check, unzip the .ipa file, open the Payload folder, open the .app bundle, and confirm a PrivacyInfo.xcprivacy file is present inside Frameworks/GoogleMobileAds.framework/.

How do app and SDK privacy manifests compare?

The short answer is the two files share a name and a structure but cover different surfaces and live in different places.

The limit is that some App Store warning emails name a category Apple cannot trace to either side. When the rejection lists a category that is neither in your code nor in the AdMob manifest, the most common cause is another bundled framework, an analytics SDK, a crash reporter, or a mediation adapter, that has not yet shipped a manifest update of its own.

What to watch out for

Three traps appear in almost every AdMob privacy manifest cycle.

The first is duplicating reasons. Some developers copy the entire AdMob manifest into their own app manifest, in the hope of being thorough. The result is doubled declarations and a higher chance of confusion during App Store review. Each manifest covers its own code.

The second is forgetting mediation adapters. The AdMob waterfall typically bundles adapters for AppLovin, Meta Audience Network, Unity Ads, or others. Each adapter is its own framework with its own manifest. If an older adapter has not yet shipped manifest support, the parent build still fails ITMS-91053 on the categories that adapter touches. Confirm in the privacy report that every adapter framework is listed and contributes its own privacy section.

The third is shipping App Tracking Transparency without the consent dialogue. Because the AdMob manifest sets NSPrivacyTracking to true and lists tracking domains, the app must present the ATT prompt before any personalised ad request leaves the device. According to Apple's App Review Guidelines 5.1.2, a build that tracks without an ATT prompt is a rejectable issue under the data use and sharing clause.

Key takeaways

• Update the Google Mobile Ads SDK to a release that includes a privacy manifest (11.2.0 or later), and prefer the current 13.x line.
• Set GoogleMobileAds.framework to Embed and Sign in the app target, otherwise the bundled manifest will not reach the IPA.
• Maintain a separate PrivacyInfo.xcprivacy in your app target for the required-reason APIs your own code calls; do not duplicate the SDK's entries.
• Run Generate Privacy Report on the Xcode archive before every App Store upload, then spot-check the unzipped .ipa to confirm every embedded framework carries its own manifest.
• For builders who want an outside read on what their compiled iOS build actually ships before submission, PTKD.com (https://ptkd.com) is one platform focused on pre-submission scanning aligned with OWASP MASVS for no-code and AI-coded apps.