Guideline 5.1.1 is a broad privacy rule, so a rejection under it can mean several different things, and the first step is to identify which sub-issue Apple cited before you change anything. The most common are a permission with a missing or vague purpose string, collecting data the feature does not need, forcing sign-in or registration for basic use, allowing account creation without offering in-app account deletion, a missing privacy policy, and privacy disclosures that do not match what your app collects. Read the exact wording in the Resolution Center, match it to the specific sub-cause, and fix that one. Fixing the wrong sub-issue is the main reason a resubmission gets rejected again.
Short answer
A 5.1.1 rejection has several possible causes, so match the Resolution Center wording to the specific one. Per Apple's App Review Guidelines, 5.1.1 covers privacy policies, permission purpose strings, data minimization, and account sign-in, including the requirement to offer account deletion when you allow account creation. If the message names a permission, add a clear purpose string; if it names sign-in, make registration optional or add account deletion; if it names disclosures, align your App Privacy details. Tracking that needs App Tracking Transparency is technically 5.1.2, and per Apple's App Privacy details, your nutrition labels must match what your app and its SDKs actually collect. Fix the cited sub-issue, then resubmit.
What guideline 5.1.1 covers
Guideline 5.1.1, Data Collection and Storage, is the part of Apple's privacy rules that governs how your app asks for, collects, and handles user data. It is not a single requirement but a group of related ones, which is why two apps can both be rejected under 5.1.1 for completely different reasons. It covers having a privacy policy, requesting only the data your app needs with a clear explanation, respecting the user's permission choices, and the rules around requiring sign-in and offering account deletion.
Because it is broad, the label 5.1.1 on its own does not tell you what to fix; the specifics in the rejection do. Apple's message in the Resolution Center will point to the actual problem, whether that is a permission prompt without a reason, a registration screen that blocks basic use, or a missing account-deletion option. Treating 5.1.1 as one thing and guessing at a fix is how developers end up resubmitting into the same rejection. The productive approach is to read the detail and map it to the specific sub-cause below.
Identify which 5.1.1 sub-issue you hit
Start by reading the exact text Apple left in the Resolution Center, because it names the sub-issue even when the guideline number is generic. Look for the concrete noun in the message: a specific permission such as location or contacts points to a purpose-string or over-collection problem, mention of sign-in or registration points to the account rules, and mention of data use or disclosure points to your privacy policy or App Privacy labels. Apple often includes a screenshot or the exact screen, which tells you where to look.
Matching the wording to the cause is the whole game with 5.1.1, because the fixes are different and mostly unrelated. Adding a purpose string does nothing for an account-deletion rejection, and adding account deletion does nothing for a forced-registration rejection. So before touching code, write down which specific sub-issue the message describes, and confirm it against the screen Apple referenced. The sections below cover each common sub-cause and its fix so you can go straight to the one that applies.
Purpose strings and unnecessary data
If the rejection names a permission, the issue is usually a missing or unclear purpose string, or requesting data the app does not need. Every sensitive permission your app requests, such as camera, location, contacts, or the microphone, must have a purpose string in your configuration that clearly and specifically explains why the app needs it. A generic or absent explanation is a common 5.1.1 trigger, because the user cannot make an informed choice.
The fix has two parts. First, add a clear, specific purpose string for each permission that describes the actual feature it supports, rather than a vague line like the app needs access. Second, remove any permission or data request that is not tied to a feature you actually offer, because 5.1.1 requires data collection to be relevant to your app's core functionality. If you request access you do not use, or cannot justify, cut it. A permission with a precise reason and a clear link to a real feature is what passes.
Forced registration and account deletion
If the rejection mentions sign-in, registration, or account deletion, the issue is one of Apple's account rules under 5.1.1. Apps may not require users to register or provide personal information to use features that do not depend on it; if a feature works without an account, users must be able to use it without signing up. A registration wall in front of basic functionality is a frequent rejection, so gate only the parts that genuinely need an account.
Separately, any app that supports account creation must let users delete their account from within the app, not just deactivate it or email support. This is a specific, enforced requirement, and a missing in-app deletion path is a common 5.1.1 rejection on its own. The fix is to add an accessible account-deletion option inside the app that removes the account and associated data. If your rejection cites account deletion, that in-app path is what Apple is looking for, and adding it is the direct resolution.
Privacy policy, labels, and tracking
If the rejection points to data use or disclosure, the issue is your privacy policy, your App Privacy labels, or tracking. Every app must include a link to a privacy policy, both in App Store Connect and, where relevant, in the app, so a missing or broken privacy policy link is a straightforward 5.1.1 cause with a straightforward fix: add a working, accurate policy. This is one of the simplest sub-issues to resolve once identified.
On nutrition labels, the App Privacy details you complete in App Store Connect must accurately reflect what your app and its third-party SDKs actually collect, and a mismatch, where your labels say you collect nothing but an analytics or ad SDK collects data, can draw a privacy rejection. Review and correct the labels to match reality, including SDK behavior. App Tracking Transparency is a related but distinct rule: if your app tracks users across other companies' apps and sites, you must present the ATT prompt and use the framework, which falls under guideline 5.1.2. If tracking is the cited concern, implement ATT and disclose it in your labels.
Sub-causes and fixes
Matching the rejection wording to the fix is the core of resolving 5.1.1. The table below routes each symptom to its cause and fix.
| Rejection detail mentions | Sub-issue | Fix |
|---|---|---|
| A permission with no or vague reason | Purpose string | Add a clear, specific purpose string |
| Data or access the feature does not need | Over-collection | Remove the permission or data request |
| Forced sign-up for basic features | Account sign-in | Make registration optional for those features |
| Account creation without deletion | Account deletion | Add an in-app account-deletion path |
| No privacy policy link | Privacy policy | Add a working, accurate privacy policy |
| Disclosures or tracking not handled | Privacy labels or ATT | Align App Privacy labels; add ATT if tracking |
Read the table by the noun in your rejection: the specific word Apple used points to the row, and each row has a different, unrelated fix.
Resubmission and appeal
Once you have fixed the specific sub-issue, resubmit, and if Apple used the Resolution Center, reply there explaining exactly what you changed, referencing the sub-issue and your fix. A clear reply that maps your change to the cited concern helps the reviewer confirm the fix quickly. Fix only the cited sub-issue rather than making broad, unrelated changes, since that keeps the review focused and avoids introducing new problems.
If you believe the rejection was a mistake, for example the reviewer flagged a permission you do not actually request, you can use the appeal path rather than change the app, stating factually why the app complies. Choose between fixing and appealing based on the facts: most 5.1.1 rejections point to a real, fixable disclosure or permission issue, so fixing is usually faster, while a genuine misread is worth a factual appeal. Either way, address the specific sub-cause, because a resubmission that ignores it will be rejected again.
Fix checklist
Working through each sub-area confirms your app meets 5.1.1 before you resubmit. The checklist below covers them.
| Check | Action | Done? |
|---|---|---|
| Purpose strings | Every permission has a clear, specific reason | [ ] |
| Data minimization | Request only what a real feature needs | [ ] |
| Optional sign-in | No forced registration for basic features | [ ] |
| Account deletion | In-app deletion available if you allow sign-up | [ ] |
| Privacy policy | Linked and accurate in App Store Connect | [ ] |
| Labels and tracking | App Privacy labels match reality; ATT if tracking | [ ] |
The row that most often decides a resubmission is the one matching your specific rejection, so confirm you fixed the cited sub-issue rather than assuming a general privacy cleanup covers it.
Check what your app actually collects
Several 5.1.1 sub-issues, over-collection, inaccurate labels, and undisclosed tracking, come down to a gap between what your app actually does with data and what you declared, and that gap is hard to see by reading your own code, especially when a third-party SDK collects data you never intended to.
A scanner like PTKD.com analyzes your build and reports issues such as risky third-party code, over-broad permissions, and data-handling problems by severity, mapped to OWASP MASVS, so you can see what your app and its SDKs actually access before you complete your privacy labels or answer a 5.1.1 rejection. To be clear about the boundary: PTKD does not write your purpose strings, fill in your App Privacy labels, or submit your appeal. It shows you what your app collects so your disclosures and permissions match reality.
What to take away
- Guideline 5.1.1 is a group of privacy requirements, so a rejection under it can mean several different things; identify the specific sub-issue before fixing.
- Read the Resolution Center wording and match the concrete noun, a permission, sign-in, or disclosure, to the sub-cause, since each has a different, unrelated fix.
- Common causes are vague purpose strings, over-collection, forced registration, missing in-app account deletion, a missing privacy policy, and inaccurate App Privacy labels.
- App Tracking Transparency is a related rule under 5.1.2, required when you track users across other apps and sites, and your nutrition labels must match what your app and SDKs collect.
- Fix only the cited sub-issue, explain it in your resubmission, and use a tool like PTKD.com to confirm what your app actually collects.
