Guideline 5.1.1 Rejection: How to Fix Data Collection Issues and Resubmit
Guideline 5.1.1 — Legal: Privacy — Data Collection and Storage — is the second most common App Store rejection. It covers how your app asks for and justifies access to user data: the purpose strings behind iOS permission prompts, whether registration is really necessary, whether users can delete their account, and whether your privacy policy actually exists and matches reality. Most 5.1.1 rejections are precise and fixable in a day — the guideline names the exact permission or flow at fault.
What Apple's rejection email says
"Guideline 5.1.1 — Legal — Privacy — Data Collection and Storage. We noticed that your app requests the user's consent to access the camera but does not sufficiently explain the use of the camera in the applicable purpose string. To resolve this issue, please revise the purpose string in your app's Info.plist file to specify why the app needs access and provide an example of how the data will be used."
Another frequent variant: "Your app supports account creation but does not include an option to initiate account deletion within the app."
Typical App Review wording for Guideline 5.1.1. Exact text varies per app.
Why apps get rejected under 5.1.1
- Missing or vague purpose strings. Every privacy-sensitive permission needs a specific
Info.plistusage description:NSCameraUsageDescription,NSMicrophoneUsageDescription,NSPhotoLibraryUsageDescription,NSLocationWhenInUseUsageDescription,NSContactsUsageDescription,NSFaceIDUsageDescription, and friends. Boilerplate like "This app needs camera access" gets rejected — Apple wants the why: "Scan documents to attach them to invoices." - Requesting permissions you don't visibly use. If the reviewer can't find the feature that needs location, the request itself is the violation. This is often a leftover from an SDK or an abandoned feature.
- Forced registration. Requiring an account before the user can do anything, when core features would work without one. Registration may only be required for features that genuinely depend on it (account-based content, sync).
- No account deletion. Since June 2022, any app that supports account creation must let users initiate account deletion inside the app — not just deactivation, and not only via a support email. A link to a web flow is acceptable if it's direct and straightforward.
- Privacy policy problems. Missing privacy policy URL in App Store Connect, a dead link, or a policy that doesn't cover what the app actually collects (including third-party SDKs).
- Data collection not matching the privacy label. Your App Privacy questionnaire answers in App Store Connect must reflect real collection, SDKs included.
Step-by-step fix
- Fix the purpose strings in Info.plist. In Xcode, open your target's Info tab (or
Info.plistdirectly) and write specific, user-facing sentences for each flagged key. Formula: what feature + what the data enables. Example forNSPhotoLibraryUsageDescription: "Choose photos from your library to add them to your listings." - Remove permission requests you don't need. Delete unused usage-description keys and the code paths (or SDK features) that trigger the prompts. Requesting less is the cleanest fix.
- Gate registration correctly. Let users reach non-account features without signing up. If everything genuinely requires an account (e.g. a messaging app), be ready to justify that in reviewer notes.
- Add in-app account deletion. A "Delete account" entry in settings that actually initiates deletion of the account and associated data. If deletion happens on the backend, the in-app flow must start it directly; if you link to a web page, the link must go straight to the deletion flow, not a generic help center. Update your Sign in with Apple handling too (revoke tokens via the REST API when the account is deleted).
- Fix the privacy policy and label. App Store Connect → App Privacy: confirm the policy URL loads, covers all collected data (including analytics/ads SDKs), and that the privacy questionnaire answers match. The policy URL is edited under App Information / App Privacy.
- Rebuild if you touched Info.plist or code. Purpose strings live in the binary, so those fixes ship in a new build.
How to resubmit
Purpose-string and account-deletion fixes require a new build: bump the build number, upload, select it and submit for review, noting in the reviewer notes exactly what changed ("revised NSCameraUsageDescription; added Settings → Delete Account"). Privacy-policy-URL or privacy-label fixes are metadata and can be corrected without a binary, followed by a reply in the App Review thread. Skip the appeal unless Apple misread your app — roughly 85% of appeals are denied, and 5.1.1 fixes are usually one focused day of work.
How AscAuto handles 5.1.1 rejections
5.1.1 rejections split cleanly for AscAuto. Metadata-side issues (privacy policy URL, App Privacy label mismatches) can be prepared and applied through the App Store Connect API after your approval. Code-side issues — the common case — get a precise diagnosis naming the exact Info.plist keys or missing flows, and with GitHub connected, a pull request proposing the new purpose strings or the account-deletion settings entry. You review, merge and approve; AscAuto resubmits and tracks the review.
FAQ
What makes a purpose string "good enough" for Apple?
Specificity. Name the feature and what the access enables: "Record voice notes to attach to tasks" passes; "This app needs microphone access" doesn't. If you can't write a specific sentence, that's a sign you may not need the permission.
Is account deletion really mandatory?
Yes — since June 30, 2022, every app that supports account creation must let users initiate account deletion within the app. Deactivation isn't enough, and "email support to delete" isn't either. A direct link to a web-based deletion flow is acceptable.
Can I require sign-up before users try my app?
Only if the app's core functionality genuinely depends on an account (messaging, banking, sync-centric products). Otherwise let users experience non-account features first and prompt for registration when they hit a feature that needs it.
The flagged permission comes from a third-party SDK. Whose problem is it?
Yours — the prompt appears under your app's name. Either configure the SDK so it doesn't trigger the permission, remove it, or provide a purpose string honestly describing that use. Your privacy label must also declare data the SDK collects.