Guideline 5.1.1 Data Collection and Storage: account deletion, purpose strings and forced logins

Guideline 5.1.1 sits under 5.1 Privacy in the Legal section and runs from (i) to (x). Some sub-points rarely touch a small app — (vii) on SafariViewController, (viii) on compiling personal data from public sources. Five of them account for nearly every indie rejection we see:

This has applied to every app submitted since June 30, 2022, and the rejection is blunt: "The app supports account creation but does not include an option to initiate account deletion." Apple's support page sets out what counts:

Every protected resource your code touches — camera, photos, microphone, location, contacts — needs a usage description in Info.plist. A missing one fails at upload (ITMS-90683), sometimes because an SDK references the API even if you never call it. A vague one fails in review. The rejection developers get reads: "One or more purpose strings in the app do not sufficiently explain the use of protected resources."

• Ask when the feature is used, not at launch. Apple's Human Interface Guidelines say to avoid requesting permission at launch unless the app can't function without it.
• Use system pickers where you can. 5.1.1(iii) prefers the out-of-process photo picker or a share sheet to full library access — and the picker needs no permission at all.
• Pre-permission screens have rules. One button, not labelled "Allow", and no way to dismiss it that tricks a quick tap into consent.
• Never gate the app on consent. 5.1.1(ii) says paid functionality must not depend on granting data access, and 5.1.2(i) bars requiring notifications, location or tracking to use features.

The rejection usually says the app "requires users to register or log in to access features that are not account based." Sign-up walls are common in subscription apps because they make attribution and win-back emails easier — but App Review judges the feature, not your funnel.

1. 01

   Separate account features from everything else

   Sync across devices, sharing and social features need an account. Browsing, logging on one device, or trying the core feature usually don't.

2. 02

   Add a guest path

   Let people use the app locally and offer an account at the moment it adds something — backup, sync, a second device. Guest accounts you create automatically must still be deletable.

3. 03

   Keep purchases account-free where possible

   Apple has rejected apps that required registration before in-app purchases unrelated to account features. StoreKit purchases work without your own login.

4. 04

   Make contact details optional

   5.1.1(x) allows asking for a name and email only if it's optional and nothing depends on it.

Three different artefacts, often confused. Only the first is 5.1.1 itself, but reviewers look at all three together.

A practical rule: every SDK you add — analytics, crash reporting, attribution, a subscription backend — is a third party in your privacy policy and a line in your App Privacy answers. Audit both whenever the dependency list changes.

5.1.1 rejections are usually factual, so the reply should be too: what you changed and exactly where the reviewer can see it.

Hello App Review team,

Thank you for the feedback on Guideline 5.1.1([sub-point]).

Changes in build [number]:
- Account deletion: Settings > Account > Delete Account. Deletion removes the
  account and its data immediately; subscribers are told billing continues
  through Apple until they cancel.
- Purpose strings: the camera string now reads "[new string]".
- Sign-up is now optional. Core features work as a guest; an account is only
  offered for sync across devices.

Demo account (for the account features): [email] / [password]

Thank you,
[Name]