AI AI Tools Guidebook
Troubleshooting

App Rejected for Guideline 5.1.1 Privacy — How to Resubmit

Apple cites Guideline 5.1.1 when your privacy policy, data collection disclosure, or consent flow does not match what the binary actually does. Diagnose and fix.

Published: 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, no broken feature; reviewer simply read your Info.plist usage descriptions, ran the app, watched it call analytics, and noticed your privacy nutrition label said “Data Not Collected.” Guideline 5.1.1 is the most cited rejection reason in 2025, and almost every case traces back to one of six mismatches between what you declared and what the binary does at runtime.

Common causes

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

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

You shipped Firebase Analytics, Sentry, Adjust, Branch, or Facebook SDK. Each of those is “data collected for analytics” or “linked to user” 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.

How to spot it: Open App Store Connect → 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 in App Store Connect → App Information → Privacy Policy URL in an incognito window. If it does not render readable policy text within one click, 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. Hiding it behind a website link or a “contact support” form is a 5.1.1(v) rejection.

How to spot it: In the app, navigate to Settings → Account. There must be a clearly labeled Delete Account that completes the deletion request inside the app — not a mailto: link.

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 nutrition label

In App Store Connect → App Privacy → Edit. Walk through every category:

  • Identifiers: Device 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.

Mark each as Linked to User if you store a user ID alongside, Not Linked if the SDK is configured anonymously. Mark Tracking if you use IDFA or do cross-app/site profiling.

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 NSPrivacyAccessedAPICategoryFileTimestamp, SystemBootTime, DiskSpace, ActiveKeyboards if your code or any SDK uses them. 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 30 days) on your backend, sign the user out, and clear local data. A mailto: link is not acceptable.

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.

Verify

  • The new privacy policy URL opens fully without login or redirect, in incognito.
  • 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.
  • Settings → Account → Delete Account completes deletion and signs out.
  • Build 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 deadlines like the May 2024 required-reason API change 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?

That sub-clause is account deletion. Add the in-app Delete Account flow described above; that single fix resolves (v).

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

Related Articles