App Store Privacy Rejection (Guideline 5.1): Data & Permission Issues

App Store Privacy Rejection? Let’s Find the Data or Permission Issue.

Guideline 5.1 rejections are about data: what the app collects, why, whether users were told, whether they can refuse, and whether the five places where you describe your data practices agree with each other and with the code. The reviewer’s message names one symptom. The underlying cause is usually an inconsistency between the privacy policy, the App Privacy labels, the privacy manifest, the permission strings and what the app actually does.

Free initial review · No payment required · No source code required initially

On this page (12 sections)

Guideline 5.1 at a glance

Sub-sections of Guideline 5.1 commonly cited
Section	Topic	Typical trigger
5.1.1	Data Collection and Storage	Missing privacy policy; vague purpose strings; data collected without need; mandatory login; App Privacy labels wrong
5.1.1(v)	Account deletion	Account creation without in-app deletion
5.1.2	Data Use and Sharing	Tracking without ATT consent; sharing data beyond stated purposes; data brokers
5.1.3–5.1.5	Health, Kids, Location	Sensitive categories with specific rules
Privacy manifests	Required-reason APIs and SDK manifests	Missing PrivacyInfo.xcprivacy declarations (ITMS warnings or rejection)

The five-layer privacy review

Each layer must say the same thing. Rejections come from disagreements between them.

Privacy policy — reachable in the app and in App Store Connect; describes the data types, purposes, third parties, retention and deletion.
App Privacy labels (App Store Connect) — data collected, linked to identity or not, used for tracking or not.
Privacy manifest (PrivacyInfo.xcprivacy) — required-reason API usage, tracking domains, collected data types, for your app and for each SDK that needs one.
Permission purpose strings (Info.plist usage descriptions) — specific, honest reasons for camera, photos, location, contacts, microphone, Bluetooth and so on.
Actual data flows — what the code and the SDKs send, to whom, and when.

Privacy manifest vs App Privacy vs privacy policy

These are three different artefacts with three different audiences: the manifest is technical and per-binary, the App Privacy labels are the store’s nutrition label, and the policy is the legal document for users. They must be consistent, and none of them replaces the others.

SDKs and required-reason APIs

Third-party SDKs are the usual source of undeclared collection and of required-reason API usage (file timestamps, system boot time, disk space, user defaults, active keyboards). Apple expects privacy manifests from listed SDKs and declared reasons for those APIs. Update SDKs to versions that ship manifests, and declare your own usage.

Permission purpose strings

“This app needs camera access” is not a reason. “Scan the QR code on your ticket to check in” is. Every usage description must explain the specific feature that uses the permission. Missing strings crash the app on access (a 2.1 rejection); vague strings draw a 5.1.1 rejection.

Data minimisation and denied permissions

Request only what the feature needs, at the moment it needs it. The app must keep working when a permission is denied — offer the alternative (manual entry instead of contacts access, a fixed region instead of location). Requiring a permission to use unrelated features is a common 5.1.1 finding.

Do not require registration for features that do not need it. If account-based features exist, allow the rest of the app to be used without an account, or explain in the review notes why the app cannot function without one.

Account deletion — 5.1.1(v)

Apps that let users create an account must let them delete it from within the app, and the deletion must be real (backend data removed or anonymised, not just a “deactivate” flag). Apple’s support page on offering account deletion describes expectations. Mention the location of the feature in the review notes.

Tracking, ATT and consent — 5.1.2

If the app or any SDK links user or device data with third-party data for advertising or measurement, or shares it with data brokers, that is tracking. The App Tracking Transparency prompt must be shown before tracking starts, and the app must respect a refusal. Advertising and attribution SDKs initialised before consent are a classic rejection cause.

AI and third-party data sharing

Sending user content to an AI provider or any third party is data sharing. Disclose it in the policy, reflect it in the labels, and make sure the purpose users are told matches what happens. Data used to train third-party models needs explicit disclosure.

Retention and deletion

State how long data is kept and how users can get it deleted. If the policy says data is deleted on request but the app offers no way to request it, expect a rejection.

Resubmission checklist

Privacy policy reachable in-app and in App Store Connect; describes types, purposes, third parties, retention, deletion
App Privacy labels match the policy and the code, including every SDK
Privacy manifests present for the app and for SDKs that require them; required-reason APIs declared
Every permission has a specific purpose string; the app works when a permission is denied
No mandatory login for features that do not need it
In-app account deletion implemented and mentioned in review notes
ATT prompt shown before any tracking; SDKs respect refusal
AI / third-party sharing disclosed

What we can implement

Privacy manifests and SDK updates, purpose strings and permission-denied flows, ATT integration with SDK gating, in-app account deletion with backend support, privacy-policy and label alignment, and removal of unnecessary collection — on iOS native, Flutter and React Native.