Guideline 5.1.1 rejection: data collection and storage

What the rejection means

Guideline 5.1.1 (Data Collection and Storage) is part of the Legal section of the App Store Review Guidelines. The rejection text usually quotes a sub-point, such as (i) privacy policy, (ii) permission, (iii) data minimization, (iv) access, or (v) account sign-in and deletion.

Why it usually happens

• Permission prompts like "This app needs your location" with no reason.
• Sign-up required before users can see anything that doesn't need an account.
• Asking for contacts, location or photos when the feature works without them.
• Privacy policy link missing in the app or in App Store Connect.
• Account creation without a way to delete the account in the app.

How to fix it

1. Rewrite every purpose string (NSCameraUsageDescription and others) to say what the data is used for, with an example.
2. Let users browse non-account features without signing in.
3. Remove permissions you don't use, including ones requested by SDKs.
4. Add a privacy policy link inside the app and in App Store Connect.
5. Add in-app account deletion; see 5.1.1(v).
6. Check your App Privacy details match the build (Apple: App privacy details).

What to tell the reviewer

Reply in App Store Connect with what you changed, where the reviewer can see it (screen and steps), and the updated build number. Keep it short and factual. Appeal only if the reviewer clearly misread the feature.

How to avoid it next time

Review purpose strings and the privacy manifest whenever you add an SDK, and test the first-run flow as a new user who declines every permission.

How to fix a 5.1.1 rejection, step by step

Follow these steps in order. Each one is something we do on client work.

1. Find the sub-section. 5.1.1 has parts for privacy policies, permission, data minimisation, access and account sign-in. Match the message to one.
2. Link the privacy policy. 5.1.1(i) requires a link in App Store Connect and inside the app.
3. Rewrite purpose strings. Explain why you need the permission and how the user benefits.
4. Drop forced personal data. Apps may not require users to enter personal information to function, except where directly relevant.
5. Let people in without login when possible. 5.1.1(v) says apps without significant account features should allow use without login.
6. Reply per sub-section. One line per fix.

Worked example (hypothetical)

This example is illustrative. The app is made up, and so are any numbers in it.

Say NoteNest asks for contacts on first launch with the purpose string "Needed for app". We'd move the request to the share screen, rewrite it as "Allow contacts so you can share a note with a friend", and add the privacy policy link to Settings.

The guidelines behind most rejections

Every row below is quoted or summarised from Apple's current App Review Guidelines. Check the numbers in your rejection message against it.

Common mistakes

• Vague purpose strings. "Needed for app" isn't an explanation.
• Asking for everything at launch. Ask in context.
• Policy link only on the website. It must be in the app too.
• Forced sign-up for a simple app. See 5.1.1(v).

Checklist

Copy this list into your release notes or ticket and tick each item off before you ship.

• Sub-section identified
• Privacy policy linked in ASC and app
• Purpose strings explain benefit
• Permissions requested in context
• No forced personal data
• Reply per sub-section

Sources

• Apple: App Review Guidelines (accessed 26 October 2026)
• Apple: Privacy manifest files (accessed 26 October 2026)
• Apple: Offering account deletion in your app (accessed 26 October 2026)
• Apple App Store Connect Help: App information (accessed 26 October 2026)