Guideline 5.1.1 rejection: privacy, decoded

The pattern underneath almost every 5.1.1 rejection: a third-party SDK collects something the developer never declared. Analytics, ads, and crash-reporting SDKs all collect — the question is only whether your paperwork admits it.

5.1.1 — Privacy Policy Missing or Unreachable

Your privacy policy link is missing, broken, or unreachable — either in the App Store Connect privacy policy URL field or inside the app itself. Every app must include a link to its privacy policy in both places, and the policy must actually describe what data the app collects and how it's used.

Severity: blocker · Decoder confidence for this class: A (see the honesty note below)

The fix

1. Put a working privacy policy URL in the App Store Connect privacy policy field for this app.
2. Add a reachable privacy policy link inside the app (settings/about screen is the usual place) that opens without an account or paywall.
3. Make sure the policy names the data you collect, how it's used, third parties that receive it, and your retention/deletion practices.
4. Test both links from a clean device/session before resubmitting — a policy behind a redirect loop or login counts as missing.

Resubmission checklist

• Privacy policy URL set in App Store Connect
• In-app link present and opens without login
• Policy content matches the app's actual data practices
• Both links tested live

Reply draft

Hello App Review Team,

Thank you for the feedback. The privacy policy is now available at [URL], linked in the App Store Connect privacy policy field and inside the app at [IN-APP PATH]. The policy describes the data the app collects and how it is used.

Thank you for your time.

[NAME]

What the decoder can diagnose here: Which location Apple couldn't find it in, from their wording — App Store Connect field vs in-app link. What it cannot: Whether your policy's content is substantively adequate (data types, third parties, retention/deletion) until it's specific to what the app actually does — generic template policies draw follow-up questions.

Rule text: “All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible location.” — App Review Guidelines §5.1.1(i), retrieved 2026-10-23

5.1.1 — Privacy Practices vs Declarations Mismatch

What your app (or its SDKs) actually collects doesn't match what you declared in the App Store privacy details ('nutrition label') — commonly an analytics, ads, or crash-reporting SDK collecting identifiers or usage data that was never declared, or data declared as not tracking that is in fact used for tracking.

Severity: major · Decoder confidence for this class: B (see the honesty note below)

The fix

1. List every third-party SDK in the build and what it collects (vendor privacy tables + required-reason API declarations).
2. Update the App Store Connect privacy details to declare all collected data types, purposes, and tracking use accurately.
3. Align the in-app privacy policy with the same disclosures.
4. Remove SDKs you don't actually use — dead SDKs still phone home and still count.

Resubmission checklist

• SDK inventory completed
• Privacy details match actual collection incl. SDKs
• Privacy policy consistent with declarations
• Unused SDKs removed

Reply draft

Hello App Review Team,

Thank you for the feedback. We audited the app and its third-party SDKs and updated the App Privacy details in App Store Connect to declare [DATA TYPES AND PURPOSES] collected by [SDKs]. The in-app privacy policy has been updated to match.

Thank you for your time.

[NAME]

What the decoder can diagnose here: That the fix is an audit of every SDK's data behavior against the App Store Connect privacy questionnaire — the mismatch is almost always an SDK, not first-party code. What it cannot: Each SDK's exact data flows from the message alone — use each SDK vendor's published Apple privacy guidance (most publish a data-collection table for exactly this).

Rule text: “You must clearly disclose what data you and your third-party partners collect and how it is used, consistent with the app's privacy details in App Store Connect.” — App Review Guidelines §5.1.1/§5.1.2, retrieved 2026-10-23 (summary wording; see guideline text)

5.1.1 — Account Deletion Required

Your app lets users create an account but gives them no way to delete it from inside the app. Apple requires apps that support account creation to also offer account deletion within the app — not just deactivation, and not only via emailing support (a deletion flow that links out to a web deletion process can be acceptable; making users call or only deactivate is not).

Severity: blocker · Decoder confidence for this class: A (see the honesty note below)

The fix

1. Add an account-deletion option inside the app (account/settings area) that deletes the account and associated data, or initiates that deletion.
2. Don't substitute deactivation/disable for deletion — offer actual deletion; extra steps beyond reasonable confirmation (surveys, retention offers) draw repeat rejections.
3. If deletion completes via a linked web flow, it must be a real deletion process, reachable directly from the in-app option.
4. Describe the path in the review notes so the reviewer can find and test it with the demo account.

Resubmission checklist

• In-app deletion path exists and works with the demo account
• Deletion covers account + associated data (retention exceptions disclosed)
• Path documented in review notes

Reply draft

Hello App Review Team,

Thank you for the feedback. Build [X] includes account deletion inside the app at [PATH — e.g., Settings > Account > Delete Account]. It deletes the user's account and associated data [OR: initiates deletion, completed within [TIMEFRAME] as disclosed in the flow]. The path is also noted in the review notes for testing with the demo account.

Thank you for your time.

[NAME]

What the decoder can diagnose here: That the fix is a working in-app deletion path, reachable from account settings, that deletes or initiates deletion of the account and associated data. What it cannot: Timing/retention edge cases (legal holds, fraud prevention retention) — if you retain some data, the policy and flow must say what and why.

Rule text: “If your app supports account creation, you must also offer account deletion within the app.” — App Review Guidelines §5.1.1(v), retrieved 2026-10-23

5.1.1 — Tracking Consent / App Tracking Transparency

Your app tracks users (shares data with third parties for advertising/measurement, or accesses the IDFA) without asking through App Tracking Transparency first, or the ATT prompt/flow is implemented incorrectly — e.g., tracking starts before the user answers, or a custom pre-prompt pressures the user.

Severity: blocker · Decoder confidence for this class: B (see the honesty note below)

The fix

1. Present the ATT system prompt before any tracking occurs, and gate all tracking SDK initialization on the user's answer.
2. Add a clear NSUserTrackingUsageDescription explaining the purpose in plain language.
3. Remove custom pre-prompts that pressure or mislead (incentives for consent are prohibited).
4. Respect denial completely: no fingerprinting or alternative identifiers to work around a 'no'.
5. Update privacy declarations to match the tracking behavior.

Resubmission checklist

• ATT prompt shown before any tracking
• SDKs gated on the ATT result
• Usage description string present and honest
• No fingerprinting workarounds
• Privacy details updated

Reply draft

Hello App Review Team,

Thank you for the feedback. In build [X], the App Tracking Transparency prompt is requested before any tracking activity, and all tracking-related SDKs initialize only after the user's choice. The usage description has been clarified, and a denial is fully respected with no alternative tracking.

Thank you for your time.

[NAME]

What the decoder can diagnose here: The consent-ordering problem (nothing may track before the ATT answer) and the required mechanics: system prompt, usage description string, no gating app use on consent. What it cannot: Whether your data sharing legally counts as 'tracking' under Apple's definition for every partner — when in doubt, the definition is broad: linking app data with third-party data for ads/measurement counts.

Rule text: “You must receive explicit permission from users via the App Tracking Transparency APIs to track them across apps and websites owned by other companies.” — App Review Guidelines §5.1.2(i)/ATT requirements, retrieved 2026-10-23

Related guides

• Rejection decoder — paste your message, get the fix
• App Store Pre-Flight — the full check and $29 Founding pre-sale
• Google Play Pre-Flight — deadlines and declarations
• Google Play — the same problem in Data safety form

Sources

• App Review Guidelines §5.1.1(i), retrieved 2026-10-23
• App Review Guidelines §5.1.1/§5.1.2, retrieved 2026-10-23 (summary wording; see guideline text)
• App Review Guidelines §5.1.1(v), retrieved 2026-10-23
• App Review Guidelines §5.1.2(i)/ATT requirements, retrieved 2026-10-23

Last updated October 23, 2026. Rules change; the retrieval dates above say when this page was last checked against the store's published text.