How to Fix App Store Guideline 5.1.1 Privacy Rejection
Audit privacy policy, permissions, disclosures, data minimization, retention, and deletion after an Apple Guideline 5.1.1 rejection.
Direct answer
Reconcile the whole data flow, not only the privacy-policy wording. The app, embedded SDKs, permission prompts, App Store privacy answers, consent, retention, and deletion behavior must describe the same reality. Remove unnecessary collection and permissions before trying to explain them.
Match the wording in your rejection
Registration is required before non-account-based features can be used
Remove the mandatory data gate or demonstrate why an account is directly relevant to the core functionality or legally required.
A permission purpose string is unclear or incomplete
Name the protected data and the specific user-facing feature that needs it. A generic sentence may fail even when the permission is technically configured.
Privacy policy or App Privacy answers do not match app behavior
Inventory first-party and SDK collection, then align product behavior, disclosures, sharing, retention, and deletion.
What this rejection usually means
A 5.1.1 rejection usually indicates that the app’s collection, permissions, policy, disclosures, consent, retention, or deletion controls do not align. Treat it as a full data-flow reconciliation rather than editing one privacy-policy sentence.
Likely rejection signals
- Privacy policy does not name collected data and purposes
- Permission request is broader than the core feature needs
- App Privacy answers conflict with SDK behavior
- Consent, deletion, or withdrawal path is missing
Recovery plan
- Inventory data collected by the app, backend, analytics, advertising, authentication, and every embedded SDK.
- Match each data element to a feature, legal basis, purpose, retention period, sharing recipient, and deletion path.
- Remove unnecessary permissions and use narrower pickers or system flows where possible.
- Align the in-app policy, App Store Connect privacy answers, purpose strings, and prominent disclosures.
- Test consent denial, withdrawal, account deletion, and data deletion end to end.
Evidence to prepare
- Current data-flow inventory including SDKs
- Screenshots of consent and permission context
- Accessible privacy policy and deletion instructions
- App Privacy answers matched to production behavior
Appeal or fix first?
Clarify when Apple attributed data collection to the app that does not occur in the submitted build and you can prove the SDK and network behavior.
Fix first whenever documentation, App Privacy answers, permissions, or actual production collection do not match.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the affected data type and feature.
- List the verified policy, disclosure, or code changes.
- Explain how users can refuse or delete data where applicable.
- Point to the exact in-app and public policy locations.
Frequently asked questions
Is a privacy-policy URL enough?
No. The policy, App Store Connect disclosures, permission purpose strings, consent flows, SDK behavior, retention, and deletion controls must agree.
Do analytics SDKs count?
They can. Include every SDK that accesses, collects, or shares user or device data in the audit.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Apple App Review Guidelines — 5.1.1 Privacy. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.