If your build came back with Resolution Center text citing Guideline 5.1.1(i) Data Collection and Storage, App Review is usually pointing at two related issues in the same submission: the privacy disclosure side, and a registration flow that gathers personal data without a clear core-feature reason. The reviewer is reading the policy, the App Privacy questionnaire, and the signup form against each other.
Short answer
The 5.1.1(i) clause requires a privacy policy URL in App Store Connect and inside the app that lists every category of data collected, every third party that receives it, and how a user can request deletion. Most rejections cite this clause when the policy is missing, vague, or out of step with the App Privacy questionnaire, or when the signup form asks for fields (birthdate, city, gender) that the core feature does not actually use.
What you should know
- 5.1.1(i) is the privacy-policy disclosure clause inside the broader Data Collection and Storage rule. The full text appears in the App Review Guidelines.
- The privacy policy must name every third party that receives user data, including analytics tools, ad networks, and SDKs bundled inside plugins or frameworks the developer did not install directly.
- The App Privacy questionnaire in App Store Connect must match the policy and the build; mismatches between the three are the most common 5.1.1(i) trigger reported by developers.
- Apps cannot force signup for features that do not need an account, per the related 5.1.1(v) clause; the two clauses are often cited together in the same rejection.
- The reviewer opens the policy on a fresh device and looks for the in-app link, not only the App Store Connect URL.
What does Guideline 5.1.1(i) actually require?
The clause requires every app to include a link to its privacy policy in the App Store Connect metadata field and inside the app in a place that is easy to reach. The policy must do three things explicitly: identify what data is collected and how it is used, confirm that every third party with access to that data offers the same protection, and explain retention, deletion, and consent withdrawal.
The wording matters. Apple's Data Collection and Storage guideline text requires the policy to be clear and explicit about the categories of data. A generic boilerplate policy from a template generator that says the developer may collect information without naming categories or third-party recipients does not meet the clause.
In practice, the reviewer compares three things during a 5.1.1(i) test: the policy URL, the App Privacy questionnaire answered in App Store Connect, and the actual SDKs that show up when the build is opened. If the policy lists analytics but the build also calls a crash reporter that is not disclosed, the rejection cites 5.1.1(i).
Why does Apple reject apps for over-collecting personal data?
The over-collection trap sits at the seam between 5.1.1(i) and 5.1.1(v). Section 5.1.1(v) says apps cannot require users to enter personal information to function except when directly relevant to the core feature or required by law. A signup form that demands birthdate, city, gender, and phone number for a flashlight app or a recipe browser fails this test, and reviewers usually cite both subclauses in the same Resolution Center reply.
Patterns reported on the Apple Developer Forums between 2024 and 2026 show a recurring sentence: your app requires users to register before they can access non-account-based features. The companion sentence in the same rejection usually flags the privacy policy for failing to disclose those fields. The reviewer is reading the form against the policy at the same time.
The mistake many developers make is assuming that listing a field in the privacy policy is enough to justify collecting it. The two clauses operate independently. Disclosure under 5.1.1(i) is required for what you do collect; necessity under 5.1.1(v) decides whether you are allowed to collect it in the first place for that feature.
Which fields trigger a 5.1.1(i) rejection in 2026?
The table below summarises the fields that come up most often in 5.1.1 Resolution Center replies, the trigger condition, and the pattern that has cleared review in recent submissions.
| Field | Triggers rejection when | Safer pattern |
|---|---|---|
| Birthdate | Required at signup for content with no legal age gate | Optional, requested only for an age-restricted feature |
| Full legal name | Required for a browse-only or content app | Optional, requested at order, booking, or invoice |
| Phone number | Required to access app content | Optional 2FA after account creation |
| Home address | Required before checkout or booking | Requested only at the checkout step itself |
| Gender | Required for any app outside health or fitness | Optional, with a prefer-not-to-say option |
| Government ID | Required outside KYC or age-verified categories | Only when a regulator requires it |
| Social network login | Forced as the only signup path | Offered alongside Sign in with Apple |
The pattern across the right column is that the field is moved behind the action that actually needs it, or made optional. The trigger column on the left is what App Review reads as the app gating non-account-based features behind personal data collection.
How do I rewrite my privacy policy to clear 5.1.1(i)?
The policy rewrite is usually shorter work than developers expect, because Apple has already published the taxonomy the reviewer uses. The App Privacy details page on developer.apple.com lists the data type categories (Contact Info, Health and Fitness, Financial Info, Location, Sensitive Info, Identifiers, Usage Data, Diagnostics, and so on) and the purposes (App Functionality, Analytics, Product Personalisation, Developer Advertising, Third-Party Advertising).
A policy that clears 5.1.1(i) usually has these blocks, in roughly this order:
- The legal entity behind the app, the contact email, and the effective date.
- A table or list of data categories collected, mapped to the App Privacy taxonomy, with the purpose for each.
- Named third parties that receive any of those data categories (Firebase, Mixpanel, Sentry, Amplitude, RevenueCat, OneSignal), each with a one-line note on what they receive.
- The retention period or a statement that data is held until the user requests deletion.
- The mechanism for revoking consent, requesting export, and requesting deletion, including the in-app account-deletion path required by the related 5.1.1(v) clause.
- A jurisdiction and dispute clause, when applicable.
For builders who want an external automated read of a build before resubmission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning of compiled APK, AAB, and IPA files for undisclosed SDKs, missing Privacy Manifest entries, and the over-collection patterns that trip 5.1.1(i).
The most useful test after the rewrite is to open the policy on the same browser the reviewer would use, then open App Store Connect side by side, and check that every category in the policy has a matching answer in the questionnaire, and every category in the questionnaire has matching text in the policy.
What changes to the signup flow will pass review?
The signup-flow fix is structural. The goal is that a fresh-device launch can reach the main feature without a registration step, except where the feature itself requires an account.
- Remove every field that is not strictly required for the immediate first action the user takes.
- Move age, address, and ID collection behind the action that legally requires them (a checkout, a booking, an age-restricted screen).
- Allow guest browse: the first launch screen reaches the main feature without a login or signup prompt.
- If the app has accounts, offer Sign in with Apple alongside any other authentication method, per the related 4.8 clause.
- Add a persistent in-app privacy policy link in Settings and on every screen that asks for personal data.
Apps that follow this pattern often pass 5.1.1 review on the next submission even when the privacy policy itself only changed in wording. The reviewer's primary test is whether the core feature can be reached without entering personal information.
What to watch out for
The biggest trap on 5.1.1(i) resubmissions is the App Privacy questionnaire drifting out of sync with the policy. A privacy policy that lists Firebase, Mixpanel, and Sentry while the questionnaire answers say no data is collected for analytics will fail the comparison, even if the policy itself is detailed.
A second trap is SDKs bundled inside a plugin or framework the developer did not install directly. A React Native push library that pulls in Firebase as a sub-dependency, or a payment SDK that bundles a crash reporter, both show up to App Review's scanner the same way as if the developer added them directly. The disclosure has to cover them.
A related issue is the Privacy Manifest file. Apple's PrivacyInfo.xcprivacy documentation requires a manifest for every SDK on the published required-reason list since 2024. A missing manifest is a separate 5.1.2 rejection, but the same review pass often surfaces both clauses in one Resolution Center reply.
The OWASP MASVS PRIVACY chapter covers the disclosure and data-minimisation patterns reviewers check during a 5.1.1 test (collecting only what is needed, storing only as long as required, naming third parties). None of this is App Review specific, but the same internal floor catches issues that would otherwise surface as separate rejections later in the cycle.
Key takeaways
- 5.1.1(i) is enforced as a comparison between the privacy policy, the App Privacy questionnaire, and the SDKs the binary actually loads; mismatches between the three are the most common trigger.
- Over-collection of personal data trips 5.1.1(i) when the policy does not justify the fields, and 5.1.1(v) when the fields are not necessary for the core feature; rejections usually cite both clauses together.
- A signup form that asks for birthdate, city, gender, or phone number for non-account-based features fails the necessity test in 2026 review practice, regardless of how the policy is worded.
- The privacy policy must list third-party SDKs by name, including ones bundled inside plugins; vague "we may share with partners" language no longer passes the 5.1.1(i) reading.
- Some teams outsource pre-submission scanning to platforms like PTKD.com (https://ptkd.com) to detect undisclosed SDKs, signup-flow over-collection patterns, and Privacy Manifest gaps before the build reaches App Review.
