Guideline 5.1.1 rejection app store submissions almost always trace back to one of six sub-clauses buried inside a single umbrella guideline — and Apple's rejection email rarely tells you which one. You get a boilerplate paragraph, a reference to "Legal - Privacy - Data Collection and Storage," and maybe a screenshot. The actual clause that tripped your app — missing privacy policy link, weak consent flow, over-broad data collection, a permission prompt with no purpose string, no account deletion path, or a login screen that looks like credential phishing — is left for you to guess.
That guesswork costs time you don't have during a review cycle. Every day spent re-reading the guideline text instead of shipping a fix is a day your resubmission sits in the queue.
Here's the pattern worth knowing: 5.1.1 is consistently one of the most common Legal-Privacy rejections indie developers hit, mostly because it covers six genuinely different requirements crammed under one guideline number. A rejection for 5.1.1(i) (no privacy policy) needs a completely different fix than 5.1.1(v) (no account deletion). Treating them as the same problem is why developers resubmit and get rejected again for the same guideline number, different clause.
This article maps each of the six sub-clauses — (i) through (vi) — to the exact text Apple uses, what reviewers are actually checking, and the specific fix that resolves it. If you want to see what a full pre-submission check for these issues looks like before you rely on a human reviewer to catch it, the Sample Report shows the format the App Store Preflight Kit produces.
Key takeaways
- Guideline 5.1.1 splits into six distinct sub-clauses (i–vi), and Apple's rejection email typically only cites the umbrella number without specifying which one applies.
- The three most common 5.1.1 rejection triggers are a missing or broken privacy policy link, permission prompts with vague purpose strings, and the absence of an in-app account deletion path.
- Under 5.1.1(v), Apple requires a genuine in-app account deletion flow that removes the user's data — deactivation, sign-out, or a "contact support to delete" workaround does not satisfy the guideline.
- Permission rejections under 5.1.1(iii)/(iv) are usually fixed by removing unused Info.plist usage-description keys and rewriting purpose strings to state the specific feature-level reason for each request.
- A resubmission note that cites the exact sub-clause (e.g. "Guideline 5.1.1(v)") and names the precise screen path where the fix lives resolves reviews faster than a generic "we fixed the issue" statement.
What Guideline 5.1.1 Actually Covers (Apple's 6 Sub-Clauses)
Guideline 5.1.1 is Apple's Legal - Privacy - Data Collection and Storage requirement: apps that collect user data must be transparent about what they collect, get proper consent, and give users control over their own data and accounts. It splits into six sub-clauses, labeled (i) through (vi) in Apple's own guideline text — match the letter in your rejection email to the section below.
5.1.1(i) — Privacy Policy
Every app must link to a working privacy policy, both in its App Store Connect metadata and inside the app itself, before any data collection happens. Reviewers check that the link resolves (not a 404, not a placeholder page) and that the policy actually names what your app collects, not generic boilerplate. A privacy policy that doesn't match your app's real data usage — copied from a template and never edited — triggers this rejection just as often as a missing link.
5.1.1(ii) — Informed Consent
If your app collects data beyond what's needed for basic functionality, you need to ask for consent at the point of collection, not bury it in a terms-of-service checkbox at signup. Apple wants a clear, in-context prompt: what you're collecting, why, and an actual choice to decline. Pre-checked consent boxes or consent bundled with an unrelated "accept to continue" gate both fail here.
5.1.1(iii) — Data Minimization
Apps should only request data relevant to the app's core functionality. A flashlight app asking for contacts, or a note-taking app requiring precise location, gets flagged under this clause. If a reviewer can't map a requested data type to a feature they can see in your app, expect a rejection — and expect to justify each one in your App Privacy nutrition label, not just your code.
5.1.1(iv) — Permission Respect
If a user declines a permission request (camera, location, notifications), your app has to keep working, or fail gracefully with a clear explanation — not nag repeatedly, not silently break, not gate core features behind a permission with no fallback. This is also where vague or missing purpose strings (the NSCameraUsageDescription-style text shown in the system prompt) get caught. If you're on Expo and unsure how specific your permission strings need to be, see Expo App Store Permission Description for the exact wording Apple expects.
5.1.1(v) — Account Sign-In and Deletion
If your app lets users create an account, it must let them delete that account — not just log out, not just email support, an actual in-app deletion path that removes their data. This has been a frequent rejection point since Apple tightened enforcement, especially for apps built on Expo/React Native where account deletion is easy to leave out of the initial build. Full walkthrough here: App Store Account Deletion Expo. This sub-clause also shows up when RevenueCat-powered subscription apps ship without deletion — see RevenueCat Missing Metadata App Store if your rejection mentions subscription or purchase metadata alongside 5.1.1(v).
5.1.1(vi) — No Hidden Password Harvesting
Apps can't collect passwords for other services (email, banking, other apps) outside of Apple's own Sign in with Apple or standard OAuth flows. This clause targets apps that ask users to type in third-party credentials directly into a custom form — even for legitimate integrations, that pattern reads as credential harvesting to a reviewer and gets an automatic flag.
Guideline 5.1.1 Rejection: Why Apple Flagged Your App Store Submission (and How to Fix It)
Why Apple Flags Indie Apps for This So Often
5.1.1 rejections cluster around small teams for structural reasons, not bad luck. Four patterns show up over and over.
First, boilerplate privacy policies. A solo developer grabs a free generator template, swaps in the app name, and ships it. The policy describes data practices in the abstract — "we may collect information you provide" — instead of what the app actually does. Reviewers cross-check the policy against the app's actual data collection behavior, and generic boilerplate rarely matches reality closely enough to pass.
Second, permission prompts copy-pasted from tutorials. Most iOS developers learn camera, location, and photo library access from Stack Overflow answers or YouTube walkthroughs. Those examples ship with placeholder purpose strings like "This app needs access to your camera" — technically present, functionally meaningless. Apple's guideline requires the string to explain why, and a copied placeholder almost never does.
Third, cross-platform frameworks requesting capabilities the app doesn't use. Expo and React Native pull in native modules with broad default permission sets. A team using expo-image-picker for a single avatar-upload feature can end up with a compiled binary that still requests full photo library access, background location, or microphone entitlements inherited from a dependency they never directly touch. Reviewers see a permission request with no corresponding feature in the app and flag it as over-collection. This is a known failure mode for Expo builds specifically — see Expo App Store permission description for the exact strings that pass review.
Fourth, and tying the first three together: App Review increasingly tests runtime behavior against declared behavior. Reviewers tap through the app, trigger permission prompts, and check whether the declared data use in App Privacy details matches what the binary actually does. A mismatch — declared vs. observed — is an instant flag regardless of intent.
None of this is randomness. It's the predictable byproduct of shipping fast with default tooling. Every one of these failure modes is visible before submission if you know where to look — which is the whole premise of a preflight check.
The 3 Most Common 5.1.1 Rejection Triggers, Ranked
Based on patterns in App Review rejection language, three failure modes account for the overwhelming majority of 5.1.1 rejections for indie apps. Ranked by frequency:
Missing or broken privacy policy link
The single most common trigger. Apple requires a working, publicly accessible privacy policy URL in App Store Connect metadata — not just embedded in the app. The typical failure: the URL 404s because it pointed to a staging domain, a Notion page that got taken private, or a route that was never deployed to production. A close second: the policy loads fine but was never updated after a RevenueCat or analytics SDK was added, so it no longer discloses data the app actually collects — a specific version of the missing-metadata problem covered in RevenueCat missing metadata on the App Store. Diagnostic: does your privacy policy URL load in a private browser window right now, and does it mention every SDK currently in your build?
Permission prompts without a clear purpose string
The second most common trigger, and the one most directly tied to copy-pasted code. Apple's guideline requires each NS*UsageDescription string to state the specific reason the app needs that data — not just that it needs it. A prompt reading "MyApp needs your location" gets flagged; "MyApp uses your location to show nearby stores" generally doesn't. This is especially common in Expo/React Native apps where the purpose string was left at its scaffold default. Diagnostic: if you read your purpose string out loud with no other context, does it explain what feature breaks without the permission?
No in-app account deletion path
The third most common trigger, and the one Apple has been enforcing more aggressively since account deletion became an explicit 5.1.1(v) requirement. If your app lets a user create an account, it must let them delete it — from inside the app, not just via an email to support or a web form buried in settings. Apps that offload deletion to "contact us to delete your account" get rejected outright. Expo/React Native apps built on template auth flows are frequent offenders here, since starter kits rarely ship deletion UI by default — the fix pattern is covered in App Store account deletion for Expo apps. Diagnostic: can a reviewer, starting from a fresh account, delete it entirely without leaving the app?
How to Fix a 5.1.1(v) Account Deletion Rejection
Apple's fix here is narrow and non-negotiable: if your app supports account creation, it must support account deletion from inside the app, not just a "contact us to delete your account" workaround. A support email, a web form, or a "deletion requires 30 days, email support@yourapp.com" screen will all get flagged again on resubmission. Reviewers are checking for a specific, tappable path — not a promise that deletion happens eventually.
The fix has three parts. First, build the actual flow: a "Delete Account" action inside Settings or the profile screen that triggers permanent deletion of the user's account and personal data, not just a local sign-out. Deactivation, hiding the account, or disabling login without removing data does not satisfy 5.1.1(v) — Apple has rejected apps for exactly this substitution. If you have a legitimate reason to retain some data (unresolved transactions, fraud prevention, legal hold), you're allowed a brief confirmation or cooling-off step, but the request itself must be initiated in-app.
Second, make it discoverable. "Discoverable" means a reviewer using the app cold, with no prior knowledge of your product, can find the deletion option within a reasonable number of taps from account settings — typically two or three. Burying it under a nested support menu, a "manage subscription" dead end, or an external link counts as not discoverable even if the feature technically exists. If your app requires sign-in to functionally test anything, the deletion entry point needs to sit somewhere a reviewer would naturally look first: Settings > Account, or Profile > Account.
Third, if your account creation happens through a third-party login (Sign in with Apple, Google, etc.), the deletion flow still needs to remove the user's data from your systems, not just revoke the OAuth token.
Once you've built it, your resubmission note should state the fix plainly, not generally. Something like: "We've added an in-app account deletion flow at Settings > Account > Delete Account. Tapping it permanently deletes the user's account and associated data after a confirmation prompt. No external steps are required." Reviewers move faster when they don't have to hunt for what changed — name the exact screen path.
If you're shipping on Expo/React Native, the implementation details (handling Supabase/Firebase auth teardown, EAS build considerations, confirmation UX patterns that won't trip 5.1.1 a second time) are covered step-by-step in our Expo account deletion guide — worth reading before you touch the settings screen if you're on that stack.
How to Fix a 5.1.1(iii)/(iv) Data Minimization or Permission Rejection
This rejection means Apple's reviewer requested a permission — camera, location, contacts, microphone, tracking — and either couldn't find a matching feature in the app, or your purpose string didn't explain why the app needs it. The fix starts with an audit, not a rewrite of your privacy policy.
Open Info.plist and list every usage description key present: NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, NSContactsUsageDescription, NSMicrophoneUsageDescription, NSUserTrackingUsageDescription, and so on. For each one, ask a blunt question: does a reviewer testing this app on a fresh install actually hit a feature that triggers this permission prompt? If the answer is no — the key was left over from a template, a library dependency you no longer use, or a feature you cut — remove it. Apple's reviewers test permission prompts by using the app normally; an unused key that fires a permission dialog with no visible corresponding feature reads as either sloppy or deceptive, and either one gets you flagged under 5.1.1(iii)/(iv) for requesting access beyond what the app needs.
For the keys you keep, the purpose string itself matters more than developers expect. "This app needs camera access" fails — it's circular and tells the reviewer nothing. Write the actual user-facing reason: "SubmitPreflight needs camera access to scan your App Store screenshots for compliance issues" is specific, ties directly to a feature, and gives the reviewer something to go verify. Match the string to what the feature actually does — if you request NSLocationAlwaysUsageDescription but only use location in the foreground, Apple will ask why you didn't request the more limited "when in use" variant, since Guideline 5.1.1 explicitly requires requesting the minimum access necessary.
Also check timing: request permission at the point of use, not on app launch. A location prompt firing before the user has touched a location-dependent feature is a common trigger for this rejection because the reviewer has no context for why it's asking.
If you're on Expo, this is where teams get bitten hardest — Expo config plugins (expo-camera, expo-location, expo-contacts, etc.) auto-inject generic, boilerplate purpose strings into Info.plist unless you override them explicitly in app.json, and those defaults are exactly the kind of vague, feature-mismatched strings that draw a 5.1.1 flag. Our Expo permission description guide walks through the config overrides for each common plugin, with strings that have passed review. Before resubmitting, run a fresh install and confirm every permission prompt you trigger maps to a purpose string that reads like a reason, not a label — our sample report shows what that audit looks like when the Preflight Kit runs it end to end.
Writing a Resubmission Note Apple Reviewers Actually Accept
Apple reviewers see thousands of resubmissions. "We fixed the issue" tells them nothing and often triggers a second rejection — the reviewer has to go hunting for what changed, and when they can't find it fast, they reject again on the same clause just to be safe. Your resubmission note has one job: let the reviewer verify the fix in under thirty seconds.
Use this structure in the Notes for Review field:
- Cite the exact sub-clause. Say "Guideline 5.1.1(v)" or "5.1.1(iii)," not "the account deletion issue" or "the privacy thing." Reviewers work off the same rejection template you received — matching their language gets your note read, not skimmed.
- State what changed, in plain terms. One or two sentences. What was missing, what you added, where to find it. No adjectives, no justification for why the original submission was fine.
- Point to the exact location. Screen name, menu path, or settings row. If the fix is account deletion, say where the delete option lives. If it's a permission prompt, name the screen that triggers it.
- Stop there. Don't re-argue the original rejection, don't explain your architecture, don't ask the reviewer to reconsider. Extra context reads as pushback, and pushback invites a closer second look — the opposite of what you want.
Example note:
Fixed Guideline 5.1.1(v). Added in-app account deletion under Settings > Account > Delete Account. This permanently removes the user's account and associated data without requiring an external website or support contact. Confirmed the flow works on iOS 18 in this build.
That's it. No preamble, no "thank you for your feedback," no restating the guideline text back at them.
If you fixed more than one sub-clause in the same build, list each on its own line with its own citation — don't merge them into one paragraph. A reviewer scanning multiple fixes needs to check each one off independently, and a wall of text makes them re-read the whole rejection to figure out what maps to what.
The underlying pattern: your resubmission note is not marketing copy and it's not an apology. It's a changelog entry written for someone whose only goal is to close the ticket. Give them the fastest possible path to doing that.
Pre-Submission Checklist: Catch 5.1.1 Before Apple Does
Run this before every submission, not just after a rejection. Most 5.1.1 issues are cheap to catch in five minutes and expensive to catch in a two-week review cycle.
Account & data lifecycle
- If the app supports account creation, it offers in-app account deletion — not just deactivation, not a support-email workaround (5.1.1(v))
- Deletion actually removes the account and personal data server-side, not just signs the user out
- Sign-in options match what's required — if you offer third-party login, you're not silently missing the parity requirements reviewers check for
Data collection & permissions
- Every permission prompt (camera, location, contacts, notifications, tracking) has a purpose string that explains the specific reason your app needs it — not a generic template string (5.1.1(iii)/(iv))
- You only request permissions the current build actually uses — dead permission entries from removed features are a common self-inflicted flag
- Sensitive data (health, financial, biometric) has a visible in-app explanation of use before the prompt fires, not just in a linked privacy policy
Metadata and privacy-label consistency
- Your App Privacy questionnaire answers match what the binary actually does — reviewers cross-reference declared data types against observed network calls and SDK behavior, and a mismatch here is one of the fastest routes to a 5.1.1 flag even when your permission strings are fine
- Third-party SDKs (analytics, ads, payment) are accounted for in the privacy label — if you're using RevenueCat or a similar service, check our RevenueCat metadata guide for the specific fields reviewers flag most often
- Your privacy policy URL resolves, loads on mobile, and actually describes the data practices you declared
Legal & support surface
- Terms and privacy policy links in the app and in App Store Connect are live and current — treat your own Terms and Privacy pages as the baseline for what these should cover
- Support URL and contact info are functional, not placeholders
If you want to see what a full audit output looks like before you submit — every clause checked, every flag explained with a fix — the sample report shows a real preflight run end to end. Running this checklist yourself catches most issues; a full preflight catches the ones you're too close to the app to see.
Run Your Build Through a 5.1.1 Preflight Check Before You Resubmit
Here's the mistake that costs indie developers a second rejection: fixing the exact clause Apple cited and resubmitting immediately. Apple's review notes tell you what they found, not everything that's wrong. If your build has an account deletion gap under 5.1.1(v), there's a decent chance it also has a permission string that's too vague for 5.1.1(iii) or a data collection flow that hasn't been disclosed properly under 5.1.1(iv). Reviewers don't audit exhaustively on the first pass — they stop at the first blocker they hit. Fix that one thing and resubmit blind, and you're rolling the dice on whether the next reviewer digs further.
The fix is to treat 5.1.1 as six sub-clauses to check, not one line item to patch. Before you hit resubmit, walk your build against all six: third-party sign-in requirements, account creation gates, data collection disclosure, permission request minimalism, purpose strings, and account deletion. That's the same audit the Sample Report walks through — it shows exactly what a full pass looks like against a real build, not just the clause that got flagged.
This is what the App Store Preflight Kit is built for: a systematic, Markdown-first checklist that runs against your app before Apple does, covering metadata, screenshots, privacy disclosures, and IAP config alongside the 5.1.1 sub-clauses. If you're on Expo or use RevenueCat for subscriptions, the permission string and metadata gaps that trip up 5.1.1 reviews tend to be stack-specific — worth checking against your actual setup rather than a generic list.
A second rejection costs you another review cycle, sometimes another week. Running the full check once, before you resubmit, is cheaper than finding out the hard way.
Frequently asked questions
What is Guideline 5.1.1 on the App Store?
Guideline 5.1.1 is Apple's Data Collection and Storage rule under App Store Review Guideline 5, Legal. It covers how you ask for consent, what you collect, and whether you're upfront about it before collection happens. It has five sub-clauses (i–v): Privacy Policies, Data Collection and Storage, Data Minimization, Account Sign-In, and Health and Health Research. A rejection citing 5.1.1 without a sub-clause usually means the reviewer flagged your privacy policy link, your consent flow, or unclear data usage disclosure — check the rejection message for which clause they mean.
Why did Apple reject my app under Guideline 5.1.1 if I already have a privacy policy?
Having a privacy policy isn't enough — it has to be accessible from your App Store listing metadata, reachable inside the app without login, and it must actually match what your app collects. Common triggers: a broken or placeholder link, a policy that doesn't mention third-party SDKs (analytics, ads, crash reporting) you ship, or consent screens that collect data before the user agrees. Reviewers test the link directly. Read the rejection text for "privacy policy" versus "data collection" — they point to different fixes.
How long does it take to fix a 5.1.1 rejection and get approved on resubmission?
Most 5.1.1 fixes take a few hours: update your privacy policy text, fix the URL in App Store Connect, or adjust your consent screen copy. The bottleneck isn't the fix — it's Apple's review queue, which typically runs 24–48 hours for a resubmission, sometimes faster if you reply in Resolution Center instead of submitting a new build. If your fix only touches metadata (policy URL, description), you can often update it without a new binary, which skips the build processing step entirely.
Does Guideline 5.1.1 apply to apps that don't require account sign-in?
Yes. 5.1.1(i) requires a privacy policy for every app, regardless of sign-in. Account sign-in specifically falls under 5.1.1(iv), a separate sub-clause about not forcing account creation for core functionality that doesn't need it. If your app collects any data — analytics, crash logs, device identifiers, location — you need a compliant privacy policy link in App Store Connect and in-app, even with zero accounts. Apps with literally no data collection still need a policy stating that.
What's the difference between Guideline 5.1.1 and Guideline 5.1.2?
5.1.1 covers what you collect, how you disclose it, and consent mechanics — privacy policy, data minimization, sign-in requirements. 5.1.2 covers Data Use and Sharing: what you do with data after you've collected it, including third-party sharing, tracking without App Tracking Transparency permission, and using data for purposes users didn't agree to. In short: 5.1.1 is about collection and disclosure, 5.1.2 is about downstream use. Rejections citing ATT or SDK data-sharing behavior are 5.1.2, not 5.1.1.
Can Apple reject the same app twice under 5.1.1 for a different sub-clause?
Yes, and it happens often. Fixing 5.1.1(i) — your privacy policy link — doesn't clear 5.1.1(ii) data collection disclosure or 5.1.1(v) health data handling if those issues exist independently. Reviewers generally flag the first violation they find, not every one. Before resubmitting, audit all five sub-clauses against your actual app behavior, not just the one line in the rejection message, or expect a second round-trip through App Review for the clause nobody checked.