App Store Compliance

App Store Guideline 5.1.1 explained: every sub-section, every common rejection

Section 5.1.1 of the App Store Review Guidelines covers privacy policies, permissions, data minimization, account deletion, and six more rules. A complete walkthrough.

By · · 13 min read

App Store Review Guideline 5.1.1 is the most-cited rejection reason on the App Store. It covers everything Apple requires around how your app collects, uses, stores, and lets users control their personal data — and it has ten sub-sections, each with its own enforcement bar. Most developers know about (i) (privacy policy URL) and (v) (account deletion) but get blindsided by (vi), (viii), or (x) on first submission.

This post walks through every sub-section of 5.1.1 with what it actually requires, what App Review checks for, and the rejection patterns that catch teams out. The full guideline text is at developer.apple.com/app-store/review/guidelines/#data-collection-and-storage — bookmark it.

If you’re working through your full submission, see the broader checklist of every URL and file Apple requires for an iOS App Store submission.

What 5.1.1 covers (overview)

Section 5.1.1 sits inside the broader 5.1 Privacy chapter of the App Store Review Guidelines. It’s titled “Data Collection and Storage” and applies to every iOS, iPadOS, macOS, tvOS, visionOS, and watchOS app — including CarPlay-enabled apps (which are technically iOS apps with the CarPlay entitlement, so they inherit all 5.1.1 requirements).

The ten sub-sections, in order:

# Topic Common rejection Required for
5.1.1(i) Privacy policies Missing or generic policy URL All apps
5.1.1(ii) Permission Vague purpose strings Apps using protected APIs
5.1.1(iii) Data Minimization Asking for too much access Apps using contacts/photos/etc.
5.1.1(iv) Access Forcing consent for non-essential data Apps with permission prompts
5.1.1(v) Account Sign-In No in-app account deletion Apps with account creation
5.1.1(vi) Surreptitious credential discovery Hiding what you collect Any app touching passwords
5.1.1(vii) SafariViewController behavior Hiding/tracking in SFVC Apps using SafariViewController
5.1.1(viii) Off-app data aggregation Compiling PII from other sources Data brokers and aggregators
5.1.1(ix) Regulated industries Cannabis app without geo-restriction Banking/health/gambling/cannabis/crypto
5.1.1(x) Optional contact info Conditioning features on contact info Apps that ask for name/email

The rest of this post unpacks each one.

5.1.1(i) — Privacy Policies

Every app needs a privacy policy URL, declared in App Store Connect’s App Information section, that:

  • Identifies the entity collecting the data and contact info.
  • Lists every category of data the app and its third-party SDKs collect.
  • Discloses how each category is used and who it’s shared with.
  • Explains data retention and deletion practices.
  • Provides users a way to revoke consent and request deletion.

App Review’s tooling visits the URL on every submission. If it 404s, has an SSL error, sits behind a login wall, or doesn’t load on iPhone, you’re rejected.

Common rejections under 5.1.1(i):

  • “Privacy policy URL is unavailable” — the URL bounces or is blocked.
  • “Privacy policy is generic” — boilerplate text that doesn’t mention your actual data practices.
  • “Privacy policy doesn’t match your App Privacy details” — what you declared in App Store Connect’s nutrition labels questionnaire conflicts with what the policy says.

For a deep dive on what makes a policy actually pass review, see our iOS privacy policy generator post.

5.1.1(ii) — Permission

Every protected API your app calls (camera, microphone, location, contacts, photos, calendar, reminders, motion, health, HomeKit, Bluetooth, local network, speech recognition, App Tracking Transparency, and others) requires a usage description in your Info.plist — the NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, etc. strings.

Apple’s bar:

  • The string must be clear and specific to the app’s functionality.
  • It must be honest — claiming “for image search features” when the app uploads every photo to your servers gets rejected.
  • The user must be able to revoke consent without losing app functionality entirely (see 5.1.1(iv)).
  • Paid features cannot be conditioned on granting permission — the user gets the same paid features whether they grant or deny.

Common rejections:

  • “Purpose string too vague” — "This app needs your location." is not enough. "To show nearby restaurants" is.
  • “Purpose string doesn’t match observed app behavior” — the app requests Photos access but the actual functionality doesn’t appear to use photos.
  • “Permission gates a feature you’ve already paid for.”

5.1.1(iii) — Data Minimization

Request access to the smallest amount of data needed for the feature. Apple specifically encourages using out-of-process pickers (the system contact picker, system photo picker, system file picker) instead of requesting full access to the underlying database.

If your app needs one photo for a profile picture, use PHPickerViewController, not PHPhotoLibrary with full library access. If it needs one contact, use CNContactPickerViewController, not CNContactStore.requestAccess().

Common rejections:

  • “Requests full Photos access for what appears to be one-photo functionality.”
  • “Requests full Contacts access for what appears to be a single-contact share flow.”
  • “Requests Always Location when the app’s functionality only requires While In Use.”

5.1.1(iv) — Access

If a user denies a permission, the app must continue to function — at minimum, the parts that don’t depend on that permission. The app cannot:

  • Repeatedly re-prompt for the same permission after denial.
  • Use dark patterns to trick users into granting consent.
  • Disable unrelated features as punishment for declining.

Common rejections:

  • “App becomes unusable after declining a non-essential permission.”
  • “App repeatedly prompts for permission already declined.”
  • “Permission prompt copy implies the app won’t work without it (when it can).”

5.1.1(v) — Account Sign-In

Two requirements bundled into one sub-section:

A. Account creation must be optional — if the app’s core functionality doesn’t require an account, users must be able to use the app without creating one. A weather app that demands a sign-up is a 5.1.1(v) rejection.

B. Account deletion must be in-app — as of June 30, 2022, any app that supports account creation must support account deletion initiated from within the app. Email-the-developer or visit-our-website-only flows don’t satisfy this anymore.

Apple’s Offering account deletion in your app support page details exactly what counts as compliant deletion: easy to find, complete (not just deactivation), reasonable timeline, and — if you use Sign in with Apple — proper revocation via the Sign in with Apple REST API.

For implementation specifics, see our account deletion flow guide.

Common rejections under 5.1.1(v):

  • Account creation required for browsing-only functionality.
  • Deletion only available via support email, not in the app.
  • Deletion “deactivates” the account but keeps the data.
  • App uses Sign in with Apple but doesn’t revoke the Apple-issued tokens.

5.1.1(vi) — Surreptitious credential discovery

A short but absolute rule: developers who attempt to surreptitiously discover passwords, private data, or other forms of credentials will be removed from the Apple Developer Program. This is the “we will ban you” sub-section.

Most apps don’t intentionally do this. The way it bites legitimate teams is when a third-party SDK does it for them — older versions of certain ad networks were caught harvesting clipboard contents on app foreground, which iOS 14 specifically added a system warning for. If your app gets flagged because of an SDK behavior you didn’t audit, you’re still on the hook.

Common rejection signals:

  • iOS clipboard-access toast appears repeatedly when your app launches.
  • Your app reads from UIPasteboard.general.string without an obvious user-initiated paste action.
  • A third-party SDK ships with telemetry that exfiltrates form-field values.

Audit every SDK’s privacy manifest before shipping. Apple’s list of commonly-used SDKs that must provide manifests is the starting point.

5.1.1(vii) — SafariViewController

If your app uses SFSafariViewController (the in-app Safari browser), it must:

  • Be visibly presented to the user — not hidden, not zero-sized, not behind another view.
  • Not be used to track users across sites without their knowledge and explicit consent.
  • Not be used to render web content as if it’s app content — users should know they’re in Safari.

Common rejections:

  • App uses SFSafariViewController to render an in-app web view that looks like native UI.
  • App pre-loads SFSafariViewController off-screen to track cookies.

5.1.1(viii) — Off-app data aggregation

Apps cannot aggregate personal information from sources outside the app (data broker feeds, scraped public databases, leaked credential dumps) without the user’s explicit consent for that specific aggregation. This is aimed at apps that build profiles by combining data from places the user hasn’t directly given them access to.

Common rejections:

  • “People search” apps that build profiles from public-records scraping.
  • Reverse phone lookup, email enrichment, “find my high school classmates” without consent.
  • Marketing apps that augment the user’s contact list with third-party demographic data.

5.1.1(ix) — Regulated industries

Apps in highly regulated fields — banking, healthcare, gambling, cannabis, cryptocurrency, securities trading — should be submitted by legal entities (not individuals), and must comply with local laws. Cannabis-related apps specifically must be geo-restricted to jurisdictions where cannabis is legal.

Apple has been more conservative here in the past two years; expect a longer review for any app in these categories. Often a Reviewer will request your business registration documents and operating licenses upfront.

5.1.1(x) — Optional contact info

The app may request basic contact information — name, email, phone — as long as:

  • The request is optional.
  • Features are not conditioned on the user providing it.
  • The information is used for the stated purpose only.

Common rejections:

  • “Subscribe to our newsletter” gating the actual app’s functionality.
  • Email required to “save your progress” when local storage would suffice.
  • Phone number required for an app that doesn’t need to send SMS.

How OrbitKit covers the web side of 5.1.1

The sub-sections that touch web infrastructure — (i) privacy policies, (v) account deletion’s public deletion URL, and the data category disclosures that flow into nutrition labels — are exactly what OrbitKit’s hosted pages cover:

  • Hosted privacy policy page matching Apple’s 14-category × 7-purpose taxonomy.
  • Hosted account deletion page with the in-app/email/web-form options Apple expects.
  • Privacy manifest generator for PrivacyInfo.xcprivacy so your declared categories stay consistent across the policy, the App Store Connect questionnaire, and your binary.

Pricing is $5/mo per app, no setup fees. Generate your privacy policy free or see the full features list.

For the bigger picture beyond just 5.1.1, see every URL and file Apple requires for iOS and macOS App Store submission. And specifically for the 5.1.1(v) deletion implementation, our account deletion flow guide walks through the in-app UX.