AI AI Tools Guidebook
Indie Dev & Website Building

App Privacy Policy — What You Actually Need

A 2026 practical privacy policy checklist for indie iOS apps — what to include, where to host it, and how it maps to App Store Connect privacy details.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

A privacy policy is the most boring required submission asset and the easiest place to mess up. Here is what actually goes in one for an indie app, and what does not.

Background

Apple requires a privacy policy URL for every app. The policy must actually exist at that URL, stay accessible long-term, and accurately describe what data your app collects. In 2026 Apple cross-references the policy against your App Privacy questionnaire in App Store Connect — inconsistencies are a common rejection. The privacy policy itself does not need to be a legal document drafted by a lawyer for most indie apps, but it does need to be honest and complete.

How to tell

  • You are preparing your first App Store submission.
  • You collect any user data — even an email address, even just analytics.
  • You integrate any third-party SDK (Firebase, Sentry, RevenueCat, OneSignal, etc.).
  • You are updating an existing app and have added new data collection.

Step by step

  1. Build a data inventory before writing prose. A simple table is enough:
| 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 |
| Purchase info | StoreKit         | entitlement   | RevenueCat       | indefinite |
| User content  | app input        | core feature  | your server (S3) | until delete |
  1. Write the policy as plain HTML/markdown using this skeleton — it covers what App Review actually looks for:
<h1>Privacy Policy</h1>
<p><strong>Last updated:</strong> 2026-05-22</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.</p>

<h2>3. Third-party processors</h2>
<ul>
  <li>RevenueCat — purchases (<a href="https://www.revenuecat.com/privacy">policy</a>)</li>
  <li>Sentry — crash reports (<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>
  1. Map every row in your data inventory to the App Privacy questionnaire in App Store Connect. The Apple categories you will see:
Apple category            -> your row(s)
Contact Info / Email      -> Email
Identifiers / Device ID   -> Device ID (Sentry)
Identifiers / User ID     -> internal user_id
Usage Data / Product Int. -> Usage events
Purchases / Purchase Hist.-> Purchase info
User Content / Other      -> User content

For each: declare “linked to user” or “not linked”, and whether it is used for tracking. Tracking has a specific Apple definition (cross-app/site) — for most indie apps the honest answer is “no”.

  1. Describe how users can request data deletion. Even if “delete account from settings” is your full answer, write it down — App Review specifically checks for this since the account-deletion-in-app requirement.

  2. Include the policy’s last-updated date and a contact email. The contact must be real and monitored — Apple’s reviewer may email it.

  3. Host the policy at a stable URL on your own domain (e.g., yourapp.com/privacy). Avoid Notion public pages, Google Docs, or free subdomains — those URLs are flagged as unstable. If your site is on Vercel/Netlify, a single static page is fine.

  4. Cross-check policy ↔ App Privacy answers ↔ what your code actually does. A quick grep across the app source can surface forgotten SDKs:

grep -RIn --include='*.swift' -E 'Firebase|Sentry|RevenueCat|OneSignal|Mixpanel|Amplitude|Branch' .

If grep finds an SDK that is not in your policy, add it before you submit.

  1. Keep the policy version-controlled. When you update it, increment the date and commit; keep the prior version reachable at /privacy/2025-12-01 or in git history so anyone can audit changes.

Common pitfalls

  • Copying a generic template without removing sections that do not apply. Reviewers and savvy users notice.
  • Forgetting to list a third-party SDK. Firebase Analytics counts even if you “do not use the data.”
  • Hosting the policy on a different domain from your app marketing site. Allowed, but creates avoidable confusion.
  • Treating the policy as static. Every SDK addition or major feature requires an update.
  • Mismatching the policy and the App Privacy questionnaire. Reviewers actively look for inconsistencies.
  • Using legal language so dense that the user cannot tell what you actually collect. Apple specifically wants plain language.

Who this is for

Solo iOS developers submitting an app for the first time, or updating an app after adding new SDKs or features.

When to skip this

Apps that do not collect any data at all (extremely rare in 2026) — but you still need a policy stating that.

FAQ

  • Can I use a generated privacy policy?: Generators are fine as a starting point, but you must edit them to match your actual data flows. Generic generated policies often list data types you do not collect, which is its own problem.
  • Do I need a lawyer for an indie app?: Usually not for the App Store privacy policy itself, especially for non-EU users. If you have EU users, GDPR compliance benefits from legal review.
  • What if I add a new SDK after launch?: Update both the policy and the App Privacy questionnaire in App Store Connect. Updates to App Privacy do not require a new app submission, but the policy URL must reflect the change.
  • Does the policy need to be in multiple languages?: Not strictly required. English is acceptable. For non-English markets, translating helps but is not enforced.

Tags: #Indie dev #App Store #Privacy policy #App review

Related Articles