The privacy policy is the most boring required submission asset and the easiest place to get rejected over something avoidable. App Review does not just check that the URL loads — since 2026 it cross-references your policy text against your App Privacy answers in App Store Connect, and any mismatch is a documented rejection reason. Here is exactly what goes in an indie app’s policy, how to map it to Apple’s questionnaire, and the three checks that catch most rejections before you submit.
TL;DR
- Apple requires a working privacy policy URL for every iOS app, and the policy must match your App Privacy questionnaire answers.
- Build a data inventory first (data type, source, purpose, recipient, retention), then write the policy from it.
- Map each row to one of Apple’s 14 data-type categories and answer “linked / not linked” plus “used for tracking” for each.
- “Tracking” has a narrow Apple definition (combining your data with third-party data for ads). For most indie apps the honest answer is “no.”
- Separate from the policy: every app needs a Privacy Manifest (
PrivacyInfo.xcprivacy), enforced at submission since May 1, 2024.
What Apple actually requires
Three separate things, often conflated:
| Requirement | Where it lives | Enforced |
|---|---|---|
| Privacy policy URL | App Store Connect → App Information | Always, all apps |
| App Privacy questionnaire | App Store Connect → App Privacy | Always, all apps |
Privacy Manifest (PrivacyInfo.xcprivacy) | In your Xcode project / SDK bundles | At submission since May 1, 2024 |
The policy must exist at the URL, stay accessible long-term, and honestly describe what you collect. It does not need to be lawyer-drafted for most indie apps — but it must be honest, complete, and consistent with the questionnaire and with what your code actually does. The Privacy Manifest is a separate machine-readable file; App Store Connect rejects builds that use a required-reason API or a listed SDK without one.
When this applies to you
- You are preparing your first App Store submission.
- You collect any user data, even just an email address or anonymous analytics.
- You integrate any third-party SDK (Firebase, Sentry, RevenueCat, OneSignal, and others).
- You are updating an existing app and have added new data collection.
Step 1 — Build a data inventory before writing prose
A single table is enough. Fill one row per distinct data type before you write a sentence of policy:
| Data type | Source | Purpose | Recipient | Retention |
|---------------|------------------|---------------|------------------|-----------|
| Email | sign-up form | account login | Supabase Auth | until delete |
| Device ID | iOS API | crash reports | Sentry | 90 days |
| Usage events | in-app SDK | analytics | Firebase / GA4 | 14 months |
| Crash data | Sentry SDK | diagnostics | Sentry | 90 days |
| Purchase info | StoreKit | entitlement | RevenueCat | indefinite |
| User content | app input | core feature | your server (S3) | until delete |This table is the single source of truth that the policy text, the questionnaire, and your Privacy Manifest all have to agree with.
Step 2 — Write the policy from the inventory
Plain HTML or markdown is fine. This skeleton covers what App Review actually reads:
<h1>Privacy Policy</h1>
<p><strong>Last updated:</strong> 2026-06-01</p>
<h2>1. What we collect</h2>
<p>Account: email address (you provide it). Usage: in-app
events and crash data (collected automatically). Purchases:
transaction ID and entitlement status (via Apple).</p>
<h2>2. Why we collect it</h2>
<p>To run your account, restore purchases, fix crashes, and
measure feature usage. We do not sell personal data and
we do not track you across other apps or websites.</p>
<h2>3. Third-party processors</h2>
<ul>
<li>RevenueCat — purchases (<a href="https://www.revenuecat.com/privacy">policy</a>)</li>
<li>Sentry — crash and diagnostics (<a href="https://sentry.io/privacy/">policy</a>)</li>
<li>Firebase Analytics — usage events (<a href="https://firebase.google.com/support/privacy">policy</a>)</li>
</ul>
<h2>4. Your rights</h2>
<p>You can request export or deletion of your data by emailing
privacy@yourapp.com. Account deletion is also available
in-app at Settings > Account > Delete account.</p>
<h2>5. Contact</h2>
<p>privacy@yourapp.com</p>The “we do not sell / do not track” sentence matters: it sets up the honest “No” you will give to the tracking question in Step 3.
Step 3 — Map every row to Apple’s App Privacy categories
Apple’s questionnaire uses 14 fixed data-type categories. The relevant ones for a typical indie app map like this:
Apple category -> your inventory row(s)
Contact Info / Email Address -> Email
Identifiers / Device ID -> Device ID (Sentry)
Identifiers / User ID -> internal user_id
Usage Data / Product Interaction -> Usage events
Diagnostics / Crash Data -> Crash data (Sentry)
Purchases / Purchase History -> Purchase info
User Content / Other User Content -> User contentA common indie mistake is filing crash reports only under Identifiers. Sentry crash payloads belong under Diagnostics / Crash Data, and the device ID it captures separately under Identifiers / Device ID. Apple’s full list also includes Health & Fitness, Financial Info, Location, Sensitive Info, Contacts, Browsing History, Surroundings, Body, and Other Data — declare only the ones you genuinely touch.
For each category, answer two things:
- Linked to the user, or not linked? Anything tied to an account (email, user ID) is linked.
- Used for tracking? Apple defines tracking narrowly: linking your data to third-party data for targeted advertising or ad measurement, or sharing it with a data broker. If you only run first-party analytics and do not feed an ad network, the honest answer is No — and that means no App Tracking Transparency prompt and no “Data Used to Track You” section on your product page.
Step 4 — Document data deletion (Apple checks this specifically)
Guideline 5.1.1(v) has required in-app account deletion for every app that supports account creation since June 30, 2022. Reviewers actively test for it. Two rules people miss:
- A “deactivate” or “disable” toggle does not satisfy the rule — the user must be able to delete the account and the associated personal data.
- If the account has an auto-renewable subscription, the flow must tell the user that billing continues through Apple and prompt them to cancel the subscription separately.
Even if your entire answer is “delete account from Settings,” write it into the policy. Identity-verification steps (such as confirming a code from email) are allowed before deletion.
Step 5 — Host it on a stable URL
Put the policy at a stable URL on your own domain, for example yourapp.com/privacy. Avoid Notion public pages, Google Docs, and free subdomains — those URLs change or expire and get flagged as unstable. If your marketing site runs on Vercel, Firebase Hosting, or Netlify, a single static page is fine. Keep it version-controlled: bump the last-updated date on every change, commit it, and keep the prior version reachable (for example at /privacy/2025-12-01) so changes are auditable.
Step 6 — Cross-check policy ↔ questionnaire ↔ code
The three artifacts must agree. The fastest way to find a forgotten SDK is to grep the source:
grep -RIn --include='*.swift' -E 'Firebase|Sentry|RevenueCat|OneSignal|Mixpanel|Amplitude|Branch|Adjust|Facebook' .Anything grep finds that is not in your policy and questionnaire goes in before you submit. Then confirm the same SDKs appear in your PrivacyInfo.xcprivacy — Apple publishes a list of commonly used SDKs that require both a manifest and a code signature, and a missing one is an automatic build rejection at upload, before a human reviewer ever sees it.
Common pitfalls
- Copying a generator’s output verbatim. Generated policies routinely list data types you never collect; reviewers and users both notice. Use one as a starting skeleton only.
- Forgetting a third-party SDK. Firebase Analytics counts even if you “do not look at the data.”
- Filing crash data under the wrong category. Crash payloads are Diagnostics, not Usage Data or Identifiers.
- Treating the policy as static. Every new SDK or major data-collecting feature requires a policy update and a questionnaire update.
- Policy/questionnaire mismatch. This is the single most common privacy-related rejection in 2026 — reviewers compare them line by line.
- Skipping the Privacy Manifest. It is separate from the policy and enforced at upload; the policy being perfect will not save a build that lacks
PrivacyInfo.xcprivacy.
FAQ
- Can I use a generated privacy policy?: As a starting skeleton, yes. But you must edit it down to your real data flows. Generic generated policies list categories you do not collect, which creates its own policy-vs-questionnaire mismatch.
- Do I need a lawyer for an indie app?: Usually not for the App Store policy itself, especially with no EU users. If you have EU/UK users, GDPR and UK GDPR compliance (lawful basis, data subject requests) is worth a legal review beyond what Apple checks.
- Is the Privacy Manifest the same as the privacy policy?: No. The policy is human-readable text at a URL; the manifest (
PrivacyInfo.xcprivacy) is a machine-readable plist inside your app and SDKs that declares required-reason API usage. Both are required, and they are checked separately. - What if I add a new SDK after launch?: Update the policy text, the App Privacy questionnaire, and the Privacy Manifest. Changing App Privacy answers does not require a new binary, but the policy URL must reflect the change, and adding a listed SDK does require a new build with the updated manifest.
- Does the policy need to be in multiple languages?: Not required. English is acceptable. Translating for non-English markets helps trust but is not enforced.
For the authoritative wording on data categories and the tracking definition, see Apple’s App Privacy Details and the in-app account deletion rules in Offering account deletion in your app.
Related
- What an Indie Developer Should Prepare Before Launching on the App Store
- App Store Review — the Rejection Reasons You Can Avoid in Advance
- In-App Purchases via RevenueCat — a 30-Minute Intro
- App Store Rule 4.3(b) — What ‘Spam’ Really Means
- App Store Screenshot Design Patterns That Convert (2026)
- In-App Purchase Pricing Strategy for Indie Apps