A rejection letter that cites Guideline 5.1.1 lands in App Store Connect with one of six subletters attached, and the fix depends entirely on which subletter the reviewer flagged. The label sounds like one rule. In practice it covers six, each with its own remediation pattern.
Short answer
The short answer is that Guideline 5.1.1 is shorthand for six distinct privacy clauses, and the fix has to match the clause Apple cited. According to Apple's App Review Guidelines, 5.1.1 covers privacy policy presence (i), informed consent (ii), data minimization (iii), permission respect (iv), account sign-in and deletion (v), and a prohibition on hidden password harvesting (vi). Read the Resolution Center notice carefully: the subletter is the only signal that tells you which work to do first.
What you should know
- The subletter matters more than the guideline number. Apple uses 5.1.1(i) through 5.1.1(vi) to point at distinct privacy clauses with distinct remediation paths.
- Account deletion has been required since June 30, 2022. Per Apple's account deletion support page, apps that allow account creation must also let users initiate deletion from inside the app.
- Data minimization is enforced more strictly in 2026. Optional fields like birthdate, city, or full name during signup are a common 5.1.1(iii) trigger for AI assistants and utility apps.
- A privacy policy URL in App Store Connect is non-negotiable. Both the metadata field and an in-app link to the same policy are required.
- Apple did not publish 5.1.1-specific rejection rates. Any claim beyond a directional pattern is fabricated.
What does each subletter of 5.1.1 actually cover?
The six subletters are the right lens for any remediation work. Reading them in order saves the second-attempt rejection that comes from fixing the wrong clause.
| Subletter | Topic | Common trigger |
|---|---|---|
| 5.1.1(i) | Privacy policy | No URL in App Store Connect, or the policy omits SDK list, retention, deletion |
| 5.1.1(ii) | User consent | Paid feature gated behind data collection; ATT prompt not configured |
| 5.1.1(iii) | Data minimization | Birthdate, city, full name required at signup without functional reason |
| 5.1.1(iv) | Permission respect | Microphone required to upload photos; no alternative for users who decline |
| 5.1.1(v) | Account sign-in | Mandatory registration before any feature; missing in-app account deletion |
| 5.1.1(vi) | Surreptitious data | Harvesting credentials or hidden capture; account-level enforcement |
A rejection that simply reads "Guideline 5.1.1, Legal, Privacy, Data Collection and Storage" without a subletter is rare in 2026. When it happens, the screenshot Apple attaches points at the actual clause. Open the Resolution Center thread, expand the message body, and look for the parenthetical roman numeral or the specific phrase Apple quoted from the guideline.
How do you fix a 5.1.1(i) privacy policy rejection?
The short answer is that the metadata field has to hold a valid privacy policy URL, and the policy at that URL has to address three named topics: what is collected, who else sees it, and how a user requests deletion. According to Apple's App Review Guidelines, the policy must identify each data category collected, confirm that third parties receive equal protection, and explain retention and deletion mechanics.
The mistake many developers make is pasting a generic template that lists hypothetical SDK categories. Reviewers in 2026 cross-check the policy against the App Privacy questionnaire and the SDKs detected inside the binary. If the questionnaire declares advertising data but the policy omits the advertising clause, the rejection often arrives under 5.1.1(i) rather than under the questionnaire itself.
In practice, this means the policy URL has to live on a stable domain (not a draft preview), the policy has to be linked twice (App Store Connect metadata field and from inside the app), and the body of the policy has to match the actual SDKs in the build. A short policy that names every SDK by vendor is treated more favorably than a long template policy that hedges every clause.
How do you fix a 5.1.1(v) account sign-in or deletion rejection?
The honest answer is that 5.1.1(v) is the highest-volume subletter in 2026 and splits into two distinct patterns. The first is forced registration before non-account features. The second is account creation without an in-app deletion path.
For forced registration, Apple's developer forum guidance confirms the standard rejection language: users should be allowed to access non account-based features before registration and login. The remediation is a guest or anonymous mode that lets users see the core feature without entering anything. Registration is then offered when the user opts into something genuinely account-tied, such as saving progress across devices or making a purchase.
For account deletion, Apple's account deletion guidance sets the rules clearly. The deletion option has to be initiated from inside the app, typically inside an Account or Settings screen. It has to remove the entire record and the associated personal data. Temporary deactivation is not enough. If the actual deletion happens on a server queue, the app has to confirm receipt and inform the user of the expected timeline. A flow that pushes the user to a web form to complete deletion is rejected.
For Sign in with Apple users, the Sign in with Apple REST API revoke endpoint has to be called when the account is deleted. Apple checks this with the test account included in App Review notes; deletion that leaves the Apple token still active is the second-attempt rejection many teams run into.
How do you fix a 5.1.1(iii) data minimization rejection?
The short answer is to remove every field at signup that is not used by a shipping feature. According to Apple's App Review Guidelines, apps should request access only to data relevant to core functionality and should use the share sheet or out-of-process picker where possible instead of asking for blanket Photos or Contacts access.
The common 2026 pattern is an AI assistant or utility app that asks for full name, date of birth, gender, city, and phone number during onboarding while none of those values appear in the experience. Reviewers reading the build can tell because the values never display, never affect personalization, and never appear in any API call. The fix is to delete the fields from the signup form, drop the columns from the backend if they are not used elsewhere, and resubmit. Making the fields optional is sometimes accepted, but a clean removal is faster.
For permission prompts, the parallel fix is to delay the NSXxxUsageDescription request until the user taps the feature that needs it. Asking for Location at app launch when Location is only used on screen three is a frequent 5.1.1(iii) trigger.
How do you fix a 5.1.1(ii) consent rejection?
Guideline 5.1.1(ii) requires user consent for any data collection, even when the data is anonymous at point of capture. According to Apple's App Review Guidelines, paid functionality must not depend on the user granting access to that data, and users must have an accessible way to withdraw consent.
Two patterns dominate the rejections under this subletter. The first is a paywall that activates analytics tracking before the user has agreed, often through an SDK initialized at app launch. The second is a missing or vague App Tracking Transparency prompt when the build links an SDK that performs cross-app tracking (a typical Meta or AppLovin integration). The fix is to delay SDK initialization until consent is captured and to write purpose strings that name the SDK and the data category, not a generic "improve your experience" string.
For external help at the build level, a pre-submission scan can flag the SDKs in the binary against the OWASP MASVS privacy controls. PTKD.com (https://ptkd.com) is one platform that maps the SDK inventory of an uploaded IPA against the privacy clauses Apple reviewers check most often.
What to watch out for
Three patterns trip up the second submission more often than the first.
The first is a fix that addresses one subletter and ignores another the reviewer also flagged. Reviewers sometimes cite 5.1.1 without listing every offending subletter, and a build that lands back in review with one clause fixed and another untouched is rejected the same day.
The second is a privacy policy that drifts from the App Privacy questionnaire. After the questionnaire was tightened in 2023, mismatches between declared data categories and the policy text now generate 5.1.1(i) rejections that look like 5.1.1(iii) at first glance.
The third is the assumption that account deletion can live on a website only. The Apple account deletion guidance is explicit: the deletion has to be initiated from inside the app. A web-only delete form, even one linked from the app, is not enough.
Key takeaways
- Read the subletter first. The remediation tree branches at 5.1.1(i) through 5.1.1(vi), and a fix for the wrong subletter is the most common second-attempt rejection.
- For 5.1.1(v), audit both forced registration and account deletion. A guest mode for non-account features and an in-app initiated deletion are the two checks Apple verifies on resubmit.
- For 5.1.1(i), align the privacy policy with the App Privacy questionnaire and the SDK list inside the binary.
- For 5.1.1(iii), remove unused signup fields and delay permission prompts until the feature that needs them.
- Some teams ship the build through an external scan first. PTKD.com is one of the tools focused on pre-submission privacy and permission analysis aligned with the OWASP MASVS controls Apple reviewers check most often.
