App Store Rejection 5.1.1: How to Fix Privacy Rejections Before You Submit

Quick answer: Guideline 5.1.1 (Data Collection and Storage) is one of the most common reasons apps get rejected. The usual triggers are a permission requested without a clear purpose string, asking for data the app does not actually use, or forcing account sign-in for features that do not need an account. Apps that allow account creation must also offer in-app account deletion. Most of these are visible in the binary before you submit. Here is what the rule covers and a pre-submission checklist.

A 5.1.1 rejection is frustrating because the app usually works fine. The problem is not a crash, it is how the app asks for and handles personal data. The good news is that most 5.1.1 triggers are mechanical, and you can catch them before you ever upload.

What does Guideline 5.1.1 cover?

Guideline 5.1.1 is the "Data Collection and Storage" part of the App Store Review Guidelines. The sub-points that cause the most rejections are:

• 5.1.1(i) Privacy policies and permission: request access through a clear, specific purpose string, and only request data that is relevant to your app's core functionality.
• 5.1.1(ii) Permission: do not repurpose data the user provided for one feature into something else without consent.
• 5.1.1(iii) Data minimization: request only the data you need to function.
• 5.1.1(v) Account sign-in: if your app does not include significant account-based features, let people use it without forcing them to register. Apps that do support account creation must let users initiate account deletion from inside the app.

The most common 5.1.1 triggers

The rejections cluster around a short list of issues:

• Missing or vague purpose strings. Every sensitive permission needs an Info.plist usage description (for example NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, NSContactsUsageDescription). A prompt with no explanation, or a generic "we need this," is a frequent reject.
• Permissions the app never uses. Leftover permissions from a template or an SDK that you do not actually exercise look like over-collection.
• Forced registration. Requiring sign-in to use basic features that do not depend on an account violates 5.1.1(v).
• No account deletion. If users can create an account, they must be able to delete it from within the app.
• A privacy label that does not match. If your App Privacy label says one thing and the binary collects another, that mismatch is a rejection and a trust problem.

Common 5.1.1 triggers and their fixes

Trigger	Sub-point	Signal in the build	Fix
Permission without a purpose string	5.1.1(i)	Declared permission, missing Info.plist usage key	Add a specific usage description
Unused permission	5.1.1(iii)	Permission declared but never called	Remove it, or the SDK that adds it
Forced sign-in	5.1.1(v)	Sign-in gate before any non-account feature	Allow use without registration
No account deletion	5.1.1(v)	Account creation present, no delete path	Add in-app account deletion
Label does not match collection	5.1.1(i)	App Privacy label differs from binary evidence	Reconcile the label with reality

How to clear 5.1.1 before submitting (checklist)

1. List every permission the build declares and confirm each has a clear, specific purpose string.
2. Remove any permission the app does not actually use, including ones pulled in by an SDK.
3. Confirm that basic, non-account features work without forcing the user to register.
4. If the app supports account creation, add a working in-app account deletion flow.
5. Reconcile your App Privacy label with the data the binary really collects and shares.
6. Provide a working demo account and clear review notes so the reviewer can reach your features.

Where a pre-submission check helps

5.1.1 is largely a binary-and-metadata question, which is where a pre-submission scan earns its keep. A scan can read the declared permissions and their purpose strings, surface permissions added by SDKs that your own code never uses, and flag where your App Privacy label does not match the binary. For the related privacy-manifest mechanics, see privacy manifest validation and fixing NSPrivacyAccessedAPITypes violations. For the full pre-flight, see the iOS app submission checklist.

Frequently asked questions

Why is my app rejected under 5.1.1 even though I have a privacy policy?

A privacy policy is necessary but not sufficient. 5.1.1 also covers how you request data in the app. The common cause is a permission requested without a clear purpose string, or a permission the app does not actually use, rather than the policy text itself.

Does Apple require account deletion?

Yes. Under 5.1.1(v), apps that let users create an account must also let them initiate account deletion from within the app. A link to email support is not enough on its own.

Can I require sign-in to use my app?

Only if the app's core features are account-based. If people can get value without an account, 5.1.1(v) says you must let them use those features without forcing registration.

What is a purpose string?

A purpose string is the Info.plist usage description (such as NSCameraUsageDescription) shown in the system permission prompt. It must clearly explain why the app needs that data. A missing or vague string is a frequent 5.1.1 trigger.