Guideline 5.1.1 — Data Collection and Storage — is one of the most common rejection categories on the App Store, and it's almost always triggered by a mismatch between what your app actually does and what your privacy policy says it does. This guide walks through the three most common 5.1.1 sub-rejections, explains the exact remediation steps for each, and shows what language Apple's reviewers look for when they re-review after resubmission.
Guideline 5.1.1 is Apple's umbrella rule for 'we need your users to know and consent to what you're doing with their data.' It splits into sub-rules: 5.1.1(i) requires you to collect data only with consent; 5.1.1(ii) requires a privacy policy; 5.1.1(iii) requires that policy to accurately match what the app does. Most 5.1.1 rejections cite (ii) or (iii).
A 5.1.1 rejection message usually includes a specific callout — something like 'your app collects device identifiers but the privacy policy does not disclose this.' Read the citation carefully; it tells you exactly which sub-rule Apple thinks you violated.
You'll see this when the Privacy Policy URL field in App Store Connect is blank, points to a dead page, or points to something that isn't actually a privacy policy (like a company homepage). Fix: generate and host a real privacy policy page, then paste the URL into App Store Connect under App Information → Privacy Policy URL.
After updating the URL, go to the rejected version and click 'Reply to Review' — briefly confirm that the policy is now live and resubmit. You don't need a new binary.
This happens when Apple's reviewers find a data category in your app that isn't disclosed in your policy, or vice versa. Fix: open your privacy policy and make sure every category checked in the App Privacy questionnaire is mentioned by name in the policy. If your app uses analytics, the policy must mention analytics. If it uses location, the policy must mention location. Crashlytics, RevenueCat, AdMob, Firebase — all of them collect data in categories that have to appear somewhere in the policy text.
A common variant: the App Privacy questionnaire is out of date because you added a new SDK in the latest version and forgot to update it. Fix both the questionnaire and the policy — Apple compares them directly.
This is triggered when you access sensitive data (photos, contacts, location, microphone, camera) without showing a runtime permission prompt that explains why. Fix: add a usage description string to your Info.plist for each permission (e.g. NSLocationWhenInUseUsageDescription) and make the text describe why your app needs access. 'To show your location on the map' is fine; 'Access location' is not.
If you use App Tracking Transparency (ATT) for ads or analytics, the pre-ATT prompt and the ATT prompt must both explain the tracking honestly. Misleading or manipulative ATT language is its own rejection path.
BaseTerms generates a privacy policy that's pre-written to cover the standard data categories (analytics, location, accounts, ads, payments). You toggle on the categories your app actually uses and the policy language updates to match — which is exactly what Apple cross-references against your App Privacy answers. The output is hosted at yourapp.baseterms.com/privacy and ready to paste back into App Store Connect.
Ready to ship?
Privacy Policy, Terms, Support, and Data Deletion — all 4 pages, ready to paste into App Store Connect and Google Play Console. Copy the raw Markdown free or host on a custom subdomain for $9 one-time.
One-time payment. No subscription. No renewal fees.