Guideline 5.1.1: Privacy — Data Collection and Storage

5.1.1 is the second most common rejection after 2.1, and it has the most sub-clauses of any guideline you're likely to hit. A typical message:

Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage

We noticed that your app requires users to register with personal
information that is not directly relevant to your app's core
functionality.

Or:

Guideline 5.1.1(v) - Data Collection and Storage

Your app supports account creation but does not appear to include an
option to initiate account deletion from within the app.

The sub-clauses that actually get hit

Clause	What it requires
5.1.1(i)	Only request data your app genuinely needs. Registration can't be a wall in front of features that don't need an account
5.1.1(ii)	Explain each permission with a purpose string, at the moment you ask
5.1.1(iv)	Don't require personal data — real name, birthday, phone — that the feature doesn't need
5.1.1(v)	If users can create an account in the app, they must be able to delete it in the app

Plus two things that live outside the guideline text but get filed under it: a Privacy Policy URL on every localization, and an App Privacy label that matches what your code actually does.

5.1.1(i) and (iv): stop asking for so much

The pattern that gets rejected: launch the app, hit a sign-up screen, and the sign-up screen demands a name, a birthday, and a phone number before showing anything.

What passes:

• Anything that works without an account works without an account. Gate only the features that genuinely need identity — sync, purchases, social.
• Optional fields are marked optional and are skippable.
• If you ask for date of birth, you need a reason. Age gating is a reason. "Analytics" is not.
• Phone number as a required field for a non-communication app is a near-automatic rejection.

5.1.1(ii): purpose strings

Every permission prompt needs an Info.plist purpose string explaining the benefit to the user, and it must be specific. "Camera access" restates the permission and gets rejected; "Scan a receipt to add it to an expense" gets approved.

Missing the key entirely doesn't reach a human reviewer at all — the upload is rejected automatically with ITMS-90683, and if it somehow ships, the app crashes the first time the API is called. Full walkthrough: ITMS-90683: Missing purpose string.

5.1.1(v): in-app account deletion

The rule since mid-2022, and the one indie apps forget most often, because it's work that has no visible payoff.

What is required:

• The deletion flow starts inside the app. A "email us to delete your account" link is explicitly not sufficient.
• It deletes the account, not just the local session. Signing out is not deleting.
• If the account was created with Sign in with Apple, the deletion must also revoke the token (ASAuthorizationAppleIDProvider credential revocation), not just drop your own row.

What is allowed:

• A confirmation step, including re-authentication.
• A grace period before the data is purged, as long as the user's action initiated it and you say so.
• Directing the user to a web page you host for the deletion itself is tolerated when local law requires extra verification (regulated finance, health) — but the entry point still has to be in the app, and you should justify it in the review notes.

Privacy Policy URL and the App Privacy label

Two separate things, both under this heading, both mechanical:

• Privacy Policy URL is required on every localization of the app. Set it on the English one and forget the French one, and the version sits in Missing Metadata or comes back rejected.
• App Privacy (the nutrition label) must match your binary. Declaring "no data collected" while your code references CLLocationManager and an analytics SDK is a mismatch reviewers do check, and it's a rejection with an unpleasant tone.

If your app calls a Required Reason API — file timestamps, boot time, disk space, active keyboards, UserDefaults — or embeds a listed third-party SDK, you also need a PrivacyInfo.xcprivacy privacy manifest in the bundle. Uploading without one draws a warning email and, increasingly, a rejection.

Catching it before you submit

Most of 5.1.1 is verifiable without a reviewer. AuditStore covers it from both sides:

• usage-strings — parses your sources against your Info.plist and reports any gated API missing its purpose string as Blocking. Local, no credentials.
• privacy-manifest — flags a project with no PrivacyInfo.xcprivacy.
• guideline-account-deletion — detects an account system in your code and reminds you 5.1.1(v) applies to you.
• guideline-siwa-data — flags the Sign in with Apple anti-pattern of re-asking for name and email afterwards.
• privacy-url — checks privacyPolicyUrl on every localization and names the ones missing it.
• privacy-crosscheck — compares the sensitive APIs your code references against the data types you declared in App Privacy, and flags the mismatch.

The last two need an App Store Connect API key; the first four run locally on your .xcodeproj.

Related

• ITMS-90683: Missing purpose string
• Review Guidelines checks — the app-type-gated policy checklist
• App Information checks — privacy policy URL, age rating, App Privacy
• Guideline 4.8: Sign in with Apple