App Rejected for Guideline 5.1.1 Privacy: How to Resubmit

Apple cites Guideline 5.1.1 when your privacy policy, App Privacy label, or consent flow does not match what the binary does at runtime. Diagnose the six causes and resubmit.

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

You submit a perfectly functional app, sleep on it, and wake up to a rejection citing Guideline 5.1.1 — Data Collection and Storage. The message says your app collects personal information without a privacy policy, or your privacy policy does not match the data types declared in App Store Connect, or the binary requests data the policy never mentions. There is no crash and no broken feature; the reviewer simply read your Info.plist usage descriptions, ran the app, watched it call an analytics SDK, and noticed your App Privacy label said “Data Not Collected.” Guideline 5.1.1 is among the most cited rejection reasons, and as of June 2026 almost every case traces back to one of six mismatches between what you declared and what the binary does at runtime.

Fastest fix: read the exact sub-clause Apple cited in Resolution Center (it tells you which of the six causes you hit), make the binary and your App Privacy label agree, then reply point-by-point with a new build number. The single most common trigger is an analytics or crash SDK (Firebase, Sentry, Crashlytics) collecting data while your label says “Data Not Collected.” If that is you, jump to Step 2.

Which cause are you in?

Match the sub-clause Apple cited to the fix. Apple’s current sub-clause numbering (as of June 2026):

If Apple cited / wrote	Cause	Go to
”does not match… App Privacy” or “Data Not Collected” but SDKs present	Label vs. SDK mismatch	Cause 1, Step 2
”privacy policy URL… could not… access” / 404 / login wall	Policy URL not reachable	Cause 2, Step 3
Policy text missing a declared data type	Policy vs. label mismatch	Cause 3, Step 3
5.1.1(iii) data minimization / prompt before context	Out-of-context permission prompt	Cause 4, Step 6
5.1.1(v) Account Sign-In	No in-app account deletion	Cause 5, Step 5
ITMS-91053 / “Missing API declaration”	No `PrivacyInfo.xcprivacy` manifest	Cause 6, Step 4

Common causes

Ordered by how often they show up in real rejection emails.

1. App Privacy label says “Data Not Collected” but SDKs collect

You shipped Firebase Analytics, Sentry, Adjust, Branch, or the Facebook SDK. Each of those is “data collected for analytics” or “Linked to You” per Apple’s taxonomy, but you ticked the “we do not collect any data” shortcut in App Store Connect because your own code does not touch user data. Apple treats a third party’s collection as your app’s collection.

How to spot it: Open App Store Connect, your app, then App Privacy. If the answer to “Do you or your third-party partners collect data from this app?” is No while your Podfile or SPM manifest lists analytics, crash reporting, or attribution SDKs, the label is wrong.

2. Privacy policy URL returns 404, redirects, or is non-public

Reviewers click the policy URL during review. A redirect to a marketing landing page, a 404, a noindex page behind a login wall, or a Notion link that asks for email all count as “no privacy policy.”

How to spot it: Open the URL set in App Store Connect under App Information, then Privacy Policy URL, in an incognito window. If it does not render readable policy text within one click, the reviewer will flag it.

3. Privacy policy text does not list the data types you collect

The policy says “we collect your email for account creation” but the app also sends device ID, IP, and crash logs to Sentry. Reviewer cross-references the policy against the nutrition label and Info.plist usage strings; any data type in either that is missing from the policy text triggers 5.1.1.

How to spot it: Search your policy page (Cmd-F) for each declared data type — “device identifier”, “crash”, “analytics”, “advertising”. Any miss is a finding.

4. App requests data access before showing a meaningful screen

You prompt for camera, contacts, or location on the first launch splash. Apple requires consent prompts to appear in context — only when the user is actually using the feature that needs the permission.

How to spot it: Watch your first 30 seconds of cold launch. Any system permission alert before the user has tapped a relevant feature is a 5.1.1 risk (and also Guideline 5.1.2).

5. Account deletion is missing or buried

Since June 30, 2022, any app with account creation must offer in-app account deletion. This is sub-clause 5.1.1(v) “Account Sign-In” in Apple’s current numbering. Hiding deletion behind a website link or a “contact support” form is a 5.1.1(v) rejection. Apple requires you to delete the entire account record and associated personal data, not merely deactivate or disable; an in-app option to start the deletion must exist.

How to spot it: In the app, navigate to Settings, then Account. There must be a clearly labeled Delete Account control that initiates the deletion request inside the app — not a mailto: link or a “we will email you” form. (Apps in highly regulated fields can add a customer-service step under 5.1.1(ix), but the in-app entry point is still required.)

6. Required Reason API used without declaring NSPrivacyAccessedAPITypes

Since May 1, 2024 Apple requires a PrivacyInfo.xcprivacy manifest declaring use of “required reason” APIs (UserDefaults, fileTimestamp, systemBootTime, diskSpace, activeKeyboards). Submitting without one — or without the reason code — gets a 5.1.1 / ITMS-91053 rejection.

How to spot it: Search your build for PrivacyInfo.xcprivacy. If it does not exist, or it does not include entries for APIs your code (or any embedded SDK) calls, expect a rejection.

Before you start

Pull the exact rejection text from App Store Connect → App Review → Messages. Note which sub-clause Apple cites (5.1.1(i), (ii), (v)).
Save a screen recording of your first-launch flow before you change anything — Apple sometimes references a specific screen, and you need to match it.
List every third-party SDK in your Podfile.lock, Package.resolved, or framework folder.

Information to collect

Current privacy policy URL and a screenshot of what it renders to an unauthenticated visitor.
The full App Privacy answers from App Store Connect (export the questionnaire as a checklist).
All NSXxxUsageDescription strings from Info.plist.
Each third-party SDK’s data collection disclosure (most publish one; Firebase, Sentry, Adjust all do).
Whether the app has account creation and where the Delete Account button lives.

Step-by-step fix

Ordered: fix the substantive gap first, then re-message the reviewer.

Step 1: Run the SDK data audit

For every SDK, capture what it collects:

grep -RE "Firebase|Sentry|Branch|Adjust|Facebook|Amplitude|Mixpanel|OneSignal" \
  Podfile Podfile.lock Package.resolved 2>/dev/null

For each match, open the vendor’s “App Store Privacy” docs page (every major SDK has one). Write down the data types and link/unlink to user status.

Step 2: Rebuild the App Privacy label

In App Store Connect, open your app, then App Privacy, then Edit. Walk through every category Apple lists:

Identifiers: Device ID (and User ID) is collected by virtually every analytics SDK.
Diagnostics: Crash data and performance data are collected by Sentry, Firebase Crashlytics, Bugsnag.
Usage Data: Product interaction is collected by Mixpanel, Amplitude, GA4.
Contact Info: Email is collected if you have any account creation.

For each declared data type Apple asks how it is used. Mark it Linked to You if it is tied to a user identity (you store a user ID or account alongside it), Not Linked to You if the SDK is configured anonymously and the data cannot be tied back to a person, and Used to Track You if you use the IDFA or do cross-app or cross-site profiling. “Used to Track You” also requires an App Tracking Transparency prompt at runtime — see App Tracking Transparency Prompt Never Appears.

Step 3: Rewrite the privacy policy to match

Add a “Data we collect” table with one row per declared type, what it is used for, and which third party receives it. Minimum sections to include:

Data types collected (matching the nutrition label exactly)
Purpose of collection (analytics, advertising, app functionality, etc.)
Third parties that receive data (named, with links to their privacy pages)
Data retention period
User rights: access, deletion, export, contact email
Children’s privacy (COPPA) statement if applicable

Host it on a public HTTPS URL with no login wall. A static HTML page on your domain or a GitHub Pages site is fine; Notion public pages work but render slowly.

Step 4: Add `PrivacyInfo.xcprivacy` for required reason APIs

In Xcode: File → New → File → App Privacy File. Add entries for every required reason API. Example for UserDefaults:

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

Repeat for every required-reason API category your code or any SDK uses. The five categories and their most common approved reason codes (verified as of June 2026 against Apple’s “Describing use of required reason API” docs):

API category	`NSPrivacyAccessedAPIType` value	Common reason code
User defaults	`NSPrivacyAccessedAPICategoryUserDefaults`	`CA92.1`
File timestamp	`NSPrivacyAccessedAPICategoryFileTimestamp`	`C617.1` or `3B52.1`
System boot time	`NSPrivacyAccessedAPICategorySystemBootTime`	`35F9.1`
Disk space	`NSPrivacyAccessedAPICategoryDiskSpace`	`E174.1` or `7D9E.1`
Active keyboards	`NSPrivacyAccessedAPICategoryActiveKeyboards`	`54BD.1`

Pick the reason that actually matches your usage; Apple rejects a manifest whose declared reason does not fit the code path. The full list of categories and approved codes lives in Apple’s Describing use of required reason API docs. SDK vendors publish their own .xcprivacy inside the framework; verify they are bundled in your final archive.

Step 5: Implement in-app account deletion

If your app has accounts, add a destructive button under Settings:

Button(role: .destructive) {
    showDeleteConfirmation = true
} label: {
    Text("Delete Account")
}
.confirmationDialog("Delete account permanently?", isPresented: $showDeleteConfirmation) {
    Button("Delete", role: .destructive) { Task { await deleteAccount() } }
    Button("Cancel", role: .cancel) { }
}

deleteAccount() must actually delete (or queue for deletion within a reasonable, disclosed period) on your backend, sign the user out, and clear local data. A mailto: link is not acceptable. Apple’s Offering account deletion in your app page is the authoritative reference for what counts.

Step 6: Move permission prompts to in-context

For every requestAuthorization / requestWhenInUseAuthorization call, move it behind the user tap that needs the feature. The relevant pre-prompt should explain why the permission is needed in plain language before the system alert appears.

Step 7: Reply through Resolution Center with a diff

In App Store Connect → App Review → Messages, write a structured reply:

Hello,

Thank you for the detailed feedback under Guideline 5.1.1.

We have addressed each point:

1. App Privacy nutrition label updated to declare:
   - Device ID (Diagnostics, Linked to User) via Firebase Analytics
   - Crash data (Diagnostics, Not Linked) via Sentry

2. Privacy policy at https://example.com/privacy rewritten to list every
   data type, third-party recipient, and retention period.

3. PrivacyInfo.xcprivacy added in build 1.4.2 (8203) covering UserDefaults
   and FileTimestamp required reasons.

4. In-app Account Deletion now available at Settings > Account > Delete
   Account (demo video attached).

5. Camera permission prompt moved from onboarding to the in-context Scan
   Document button.

The new build 1.4.2 (8203) is now in review. Please let us know if any
gap remains.

A specific, point-by-point reply with the new build number typically gets re-reviewed within 24-48 hours.

How to confirm it is fixed

The new privacy policy URL opens fully without login or redirect, in an incognito window.
Your declared App Privacy answers match every SDK’s published disclosure plus your own collection.
Cold-launch the app: no system permission prompts appear before the user taps a feature requiring them.
In the app, Settings, then Account, then Delete Account actually completes deletion and signs the user out.
Generate the Privacy Report from the archive: in Xcode, open Organizer, right-click the archive, and choose Generate Privacy Report. The PDF lists every data type and required-reason API across your binary and bundled SDKs. Confirm it matches your App Privacy label and that no SDK shows a missing manifest.
Confirm the archive contains PrivacyInfo.xcprivacy with entries for every required-reason API your binary touches.

Long-term prevention

Treat privacy disclosure as a CI step: any new SDK added to Podfile triggers a “did you update App Privacy and policy text?” checklist.
Keep a single source-of-truth spreadsheet mapping SDK → data types → linked/unlinked → policy section.
Re-run the SDK audit before every major version bump; SDKs add tracking quietly.
Subscribe to Apple’s privacy news on developer.apple.com so changes like the May 1, 2024 required-reason API enforcement do not surprise you.
Add PrivacyInfo.xcprivacy to every framework you build in-house, even if you do not publish it externally.
Keep a public, versioned change log of your privacy policy with a “last updated” date — reviewers and EU users both check this.

Common pitfalls

Copy-pasting another app’s privacy policy without updating SDK names; reviewer notices the wrong analytics vendor.
Marking everything “Not Linked to User” because you do not store names — Apple’s definition of “linked” includes any persistent device ID combined with user behavior.
Putting Delete Account behind a confirmation that requires emailing support, which Apple counts as not in-app.
Forgetting that TestFlight builds also need a valid privacy policy URL once external testers are involved.
Adding PrivacyInfo.xcprivacy to the app but not noticing that a vendored XCFramework is missing its own — the SDK’s missing manifest fails ITMS-91053.
Listing data types in the policy that you do not actually collect, hoping for safety; reviewer can also reject for over-disclosure causing user confusion.

FAQ

Q: My policy is on Notion. Is that a problem?

Notion public pages can work, but they load slowly and sometimes serve a loading shell that looks like an error. Host on a fast static page on your own domain to be safe; one-line policies on Notion are the most common 5.1.1 trigger we see.

Q: I do not collect any data myself — only crash reports through Crashlytics. Do I still need to declare?

Yes. Crashlytics collects device ID, crash logs, and performance data; all must be declared as “Diagnostics” in App Privacy and listed in the policy. The third party’s collection still counts as your app’s collection.

Q: Apple cited 5.1.1(v) specifically. What is that?

5.1.1(v) is “Account Sign-In,” which carries the in-app account-deletion requirement. Add the in-app Delete Account flow described above; that single fix resolves (v). It must delete the account record, not just deactivate it.

Q: My app is a bank / health / crypto app and deletion needs identity checks. Can I send users to support?

Partly. Under 5.1.1(ix), apps in highly regulated fields (banking, healthcare, gambling, legal cannabis, air travel, crypto exchanges) may add a customer-service step to confirm and complete deletion. But you still need an in-app entry point that starts the request — you cannot make support the only path. Apps outside those fields cannot require a phone call or email to delete.

Q: Can I appeal if I think the rejection is wrong?

Yes, via the Resolution Center or App Review Board. But in 5.1.1 cases the appeal almost always loses unless you can show the reviewer mis-read your binary; just fix the underlying gap and resubmit — it is faster. See App Review Guideline 2.1 Info Needed for related response strategy.

Q: Does my app even need a privacy policy if I have no accounts and no SDKs?

Yes. Any app that gathers user input, uses any analytics (including Apple’s), or accesses any device identifier needs a policy. The bar for “no privacy policy needed” is essentially a static read-only app with zero network calls.

Tags: #Troubleshooting #App Store #App review #privacy #guideline-5-1-1