Fix App Privacy Questionnaire Rejected / Inconsistent

Q: How long until the status changes after I republish?

For a metadata-only fix, status typically moves from **Metadata Rejected** back to **Waiting for Review** within 1-2 hours of resubmitting. If you uploaded a new build, allow extra time for TestFlight/processing first.

App Store Connect flagged your privacy nutrition labels as inconsistent with app behavior. The fastest fix: build an SDK-to-data-type inventory and reconcile every answer before resubmitting.

Published: May 17, 2026 Updated: Jun 18, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

You finished the privacy questionnaire in App Store Connect, submitted the build, and the next morning the status flipped to Metadata Rejected with a message like “the data collection practices you described do not match the data your app collects.” Sometimes the rejection is more specific — “the app appears to collect Device ID for tracking, but Tracking is not declared” — and sometimes it is the generic “please review your responses.”

Fastest fix (most cases): list every SDK in your build, look up the data each one collects from its vendor privacy page, then make your App Store Connect answers match exactly — including the “Linked to User” and “Used for Tracking” sub-toggles. About 80% of these rejections are a forgotten analytics or ad SDK (cause #1 or #2 below). Editing the questionnaire publishes immediately and does not require a new build unless the rejection also cited the binary.

Apple compares your declared answers against three things: (a) what a reviewer sees when they run the binary through static analysis tools, (b) the SDKs they detect in the IPA, and (c) what your privacy manifest (PrivacyInfo.xcprivacy) plus each bundled SDK’s manifest says is collected. A mismatch on any of those three axes triggers the rejection.

Note (as of June 2026): the answers themselves have not changed, but Apple restructured the App Privacy editor — the first-time button is now Get Started, and after you finish editing you click Publish (not just Save). The role that can edit privacy now includes App Manager, not only Account Holder and Admin. See the steps below.

Which bucket are you in?

Match your reviewer message to a cause before you touch anything. Causes are ordered by hit rate; most apps get hit by #1 or #2.

Reviewer message contains	Most likely cause	Fix section
”do not match the data your app collects” (generic)	#1 forgotten SDK	Step 1-2
”collect Device ID for tracking, but Tracking is not declared”	#2 IDFA / ATT mismatch	#2 + Step 2.4
”Linked to the User” / “Used to Track” disagreement	#3 sub-answers	Step 2.3-2.4
`ITMS-91053` / `ITMS-91056` (email, not Resolution Center)	#4 required-reason API	Step 3
”missing privacy manifest” / “signature” for a named SDK	#5 SDK manifest/signature	#5
”privacy policy” referenced explicitly	#7 policy contradiction	Step 4

Common causes

1. Third-party SDK collects data you forgot to declare

Analytics (Firebase, Amplitude, Mixpanel), ads (AdMob, Meta Audience Network), crash (Sentry, Crashlytics), and attribution (Adjust, AppsFlyer, Branch) all collect data on your behalf. Each one’s “data types” are listed in its privacy documentation, but you have to manually merge them into your own nutrition labels.

How to spot it: Open your Podfile.lock or Package.resolved, list every dependency, then visit each vendor’s privacy page (for example firebase.google.com/docs/ios/app-store-data-collection) and diff its declared types against your App Store Connect answers.

2. You declared “Not Collected” but the SDK proves otherwise

The most common version: you said you do not collect Device ID, but the AdMob or Meta SDK reads IDFA when the user grants ATT. Apple’s static scan catches the ASIdentifierManager call and the answer breaks.

How to spot it: Search the IPA’s symbols with nm -gU YourApp.app/YourApp | grep -i "ASIdentifierManager\|advertisingIdentifier". Any hit means IDFA is reachable and should be declared.

There is a well-known catch-22 here: if a reviewer says your declaration still shows tracking but you believe you removed it, the real problem is usually that the IDFA/ATT framework is still linked. App Store Connect does not let you set “Device ID = collected, but not tracked” once AppTrackingTransparency is present. If you genuinely do not track, the durable fix is to remove the IDFA code path entirely (RAM-only/session analytics that never touch advertisingIdentifier) rather than re-toggling the answer — then re-declare Device ID as not collected.

3. Missing “Linked to User” / “Used for Tracking” sub-answers

Each data type has two follow-ups: is it linked to the user’s identity, and is it used for tracking (cross-app/cross-website). People often answer the top-level type correctly but skip these. Apple rejects when the SDK’s manifest contradicts your sub-answer.

How to spot it: Open App Store Connect → App Privacy → for each data type, both follow-up toggles must match the SDK’s documented behavior.

4. Required-reason API not declared in PrivacyInfo.xcprivacy

Since May 1, 2024, certain APIs (UserDefaults, file timestamps, system boot time, disk space, active keyboards) need a declared reason in PrivacyInfo.xcprivacy. Missing entries trigger a separate but related rejection: ITMS-91053 (“Missing API declaration”) or ITMS-91056 (“Invalid privacy manifest”). These usually arrive as an email at upload time, before formal review, so check your inbox even while the status still reads “Waiting for Review.”

How to spot it: Xcode → your target → Build Phases → look for PrivacyInfo.xcprivacy in the resources. Open it and confirm NSPrivacyAccessedAPITypes covers every required-reason API your code or bundled SDKs touch.

5. A listed SDK is missing its privacy manifest or signature

Since May 1, 2024, when you add (or update an app that adds) any SDK on Apple’s commonly-used third-party SDK list — roughly 80 SDKs including the Firebase suite, the Facebook/Meta SDKs, GoogleSignIn, Alamofire, RealmSwift, SDWebImage and others — that SDK must ship its own privacy manifest, declare required reasons, and (when added as a binary/XCFramework dependency) carry a valid code signature. Apple will not accept the build otherwise, and the rejection names the SDK. Any version of a listed SDK, and anything that repackages one, counts.

How to spot it: The reviewer email or Resolution Center note names the SDK (“missing privacy manifest” or “signature”). Fix it by updating that SDK to the vendor’s privacy-manifest-compliant release (most major SDKs shipped one in 2024); do not hand-write a manifest for someone else’s binary.

6. Contact info / health / financial data missed entirely

Apps with sign-in collect Email and Name. Apps with sharing collect “User Content.” Apps with subscriptions collect “Purchase History.” Skipping these because they “feel obvious” is a frequent rejection.

7. Privacy policy URL contradicts the questionnaire

The reviewer reads your policy URL, sees you mention Google Analytics, but the questionnaire says no analytics. Apple flags the mismatch even if the SDK is not bundled.

Before you change anything

Confirm whether the rejection is for the questionnaire only, the build, or both — the wording differs in App Store Connect.
Capture the exact reviewer message; some reasons (ITMS codes) require precise responses.
Back up your current questionnaire answers (screenshot every page) before editing — Apple does not version them.
Make sure your App Store Connect role is Account Holder, Admin, or App Manager; the Developer role cannot edit privacy (the Marketing role can edit the privacy policy URL only). As of June 2026, App Manager is the lowest role that can edit the questionnaire.

Information to collect

Full reviewer message text and any ITMS-91xxx codes.
List of every SDK with version (from Podfile.lock, Package.resolved, or manual integrations).
Output of strings YourApp.app/YourApp | grep -i "tracking\|advertising\|idfa".
Your current privacy policy URL and the exact text mentioning data practices.
Build number and submission timestamp.

Shortest path to fix

Step 1: Build the SDK inventory

For each direct and transitive dependency:

# CocoaPods
cat Podfile.lock | grep -E "^  - " | sort -u

# SPM
cat YourApp.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved | jq '.pins[].identity'

For every entry, find the vendor’s “App Store Connect privacy guide” page. Build a table:

SDK	Data types	Linked to user	Used for tracking	Source URL
Firebase Analytics	Identifiers, Usage Data	Yes	No	firebase.google.com/…/data-collection
AdMob	Identifiers, Diagnostics	Yes	Yes	developers.google.com/admob/…/privacy

Step 2: Reconcile with App Store Connect

Open App Store Connect → Apps → your app → sidebar App Privacy. Click Get Started if you have never filled it out, otherwise click Edit next to “Data Types.” For each data type:

Choose “Yes, we collect this data.”
Pick all uses (Analytics, App Functionality, Product Personalization, Developer’s Advertising or Marketing, Third-Party Advertising, etc.).
Set “Is this data linked to the user’s identity?” Yes/No to match the SDK column.
Set “Do you use this data for tracking?” Yes/No. If Yes, your binary must call ATTrackingManager.requestTrackingAuthorization and only read IDFA after the user grants permission; if No, the IDFA code path must be absent (see cause #2).

When every type is correct, click Save, then Publish. Published answers go live on the product page immediately — there is no separate review for the questionnaire text itself.

Step 3: Update PrivacyInfo.xcprivacy for required-reason APIs

In Xcode, add a PrivacyInfo.xcprivacy file to your main target. Fill NSPrivacyAccessedAPITypes:

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>CA92.1</string>
    </array>
  </dict>
</array>

The reason codes come from Apple’s Describing use of required reason API page. For example, CA92.1 is the approved UserDefaults reason for “access info from the app group container.”

Step 4: Verify policy URL alignment

Open the privacy policy you submitted. Make sure every data category mentioned there appears in your questionnaire, and vice versa. If your policy says “we use Google Analytics,” analytics + identifiers must be ticked.

Step 5: Resubmit

After publishing the questionnaire, go to the Distribution (formerly “App Store”) tab for the version → Add for Review / Submit for Review. The questionnaire change does not require a new binary unless the rejection also cited the build (causes #4 and #5 always require a new build, because they live inside the IPA’s manifests).

How to confirm the fix

The App Privacy section in App Store Connect shows your edits as Published with today’s timestamp.
Reviewer status moves from Metadata Rejected back to Waiting for Review within 1-2 hours.
No new ITMS-91xxx warning emails arrive after upload.
For builds: TestFlight processing completes without privacy warning banner.

If it still fails

Reply in Resolution Center quoting the exact SDK + data type pairs you reconciled, with vendor doc URLs.
If the reviewer cites a specific symbol (e.g., advertisingIdentifier), search the IPA to confirm it’s actually called; if it’s dead code from an SDK, ask the vendor for a “data-collection-off” variant.
Reduce to a minimal build: remove one SDK at a time and resubmit until the rejection clears, which identifies the culprit.
Escalate via App Review Contact form with the IPA’s static analysis output as evidence.

Prevention

Maintain a PRIVACY.md in the repo listing every SDK and the data types it touches; update it in the same PR that adds the SDK.
Add a CI step that fails the build if PrivacyInfo.xcprivacy is missing or NSPrivacyTracking is true but no ATT prompt code exists.
Before each submission, run a 5-minute diff: questionnaire screenshots vs SDK inventory vs privacy policy text.
Pin SDK versions; new minor versions occasionally add new data collection without bumping major.
Subscribe to Apple Developer News — the required-reason API list and the commonly-used-SDK list both grow periodically.

FAQ

Do I need to upload a new build just to fix the questionnaire? No, if the rejection was metadata-only. Editing and publishing App Privacy answers takes effect immediately without a new binary. You only need a new build when the rejection cited the IPA itself — i.e. a missing required-reason declaration (ITMS-91053/ITMS-91056) or an SDK missing its privacy manifest/signature, since both live inside the build.

How long until the status changes after I republish? For a metadata-only fix, status typically moves from Metadata Rejected back to Waiting for Review within 1-2 hours of resubmitting. If you uploaded a new build, allow extra time for TestFlight/processing first.

The reviewer says I track users, but I don’t. Why can’t I just answer “no tracking”? Because App Store Connect ties the answer to your binary. If the AppTrackingTransparency framework or advertisingIdentifier is still reachable in the IPA, the static scan overrides your “no” and the rejection repeats. Remove the IDFA code path (or the ad/attribution SDK pulling it in), ship a new build, then declare Device ID as not collected.

Where do I find what data each SDK collects? Each vendor publishes an “App Store data collection” or “privacy details” page that lists the exact data types, whether they are linked to the user, and whether they are used for tracking. Build the table in Step 1 from those pages, not from guesswork.

Is PrivacyInfo.xcprivacy the same thing as the App Store Connect questionnaire? No. The questionnaire is metadata you fill in the web console (the public nutrition label). PrivacyInfo.xcprivacy is a file inside the app/SDK bundle that declares required-reason API usage and tracking domains. Apple cross-checks both against the binary; they must agree.

Which role can edit App Privacy? Account Holder, Admin, or App Manager (as of June 2026). The Developer role cannot; the Marketing role can edit only the privacy policy URL.

Tags: #Troubleshooting #App Store #App review