隐私政策是最无聊的提审必备资产，却也是最容易因为小事被拒的地方。App Review 不只是检查 URL 能不能打开——从 2026 年起，它会拿你的政策正文和 App Store Connect 里的 App Privacy 问卷答案交叉比对，任何对不上都是被官方写进文档的拒审理由。这篇讲清楚独立 App 的隐私政策到底要写什么、怎么映射到 Apple 的问卷，以及提审前能挡掉大多数拒审的三个检查。
一句话总结
- Apple 要求每个 iOS App 都有一个可访问的隐私政策 URL，且政策必须和 App Privacy 问卷答案对得上。
- 先建数据清单（数据类型、来源、用途、接收方、保存期），再照着写政策。
- 把每一行映射到 Apple 的 14 个数据类目，逐个回答「linked / not linked」和「是否用于 tracking」。
- 「Tracking」在 Apple 这里定义很窄（把你的数据和第三方数据拼起来做广告）。大多数独立 App 诚实答案就是「不」。
- 和政策无关的另一件事：每个 App 都要有 Privacy Manifest（
PrivacyInfo.xcprivacy），自 2024 年 5 月 1 日起在提审时强制检查。
Apple 到底要什么
三件经常被混为一谈的事：
| 要求 | 在哪 | 强制程度 |
|---|---|---|
| 隐私政策 URL | App Store Connect → App 信息 | 一直要，所有 App |
| App Privacy 问卷 | App Store Connect → App Privacy | 一直要，所有 App |
Privacy Manifest（PrivacyInfo.xcprivacy） | 在 Xcode 工程 / SDK bundle 里 | 2024 年 5 月 1 日起提审检查 |
政策必须真实挂在那个 URL、长期可访问、如实描述你收什么。对大多数独立 App 来说不必律师起草——但必须诚实、完整，且和问卷、和代码的实际行为一致。Privacy Manifest 是另一份机器可读文件；只要用到 required-reason API 或某个被列入清单的 SDK 却没带它，App Store Connect 会直接拒掉这个 build。
什么情况下要看这篇
- 准备第一次提审。
- 收集任何用户数据，哪怕只是一个邮箱或匿名 analytics。
- 集成了任何第三方 SDK（Firebase、Sentry、RevenueCat、OneSignal 等）。
- 在更新已上线 App 并新增了数据收集。
第 1 步 — 写正文前先建数据清单
一张表就够。在写任何政策文字之前，每种数据填一行：
| 数据类型 | 来源 | 用途 | 接收方 | 保存期 |
|--------------|-----------------|-------------|------------------|-----------|
| 邮箱 | 注册表单 | 账号登录 | Supabase Auth | 删号前 |
| 设备 ID | iOS API | 崩溃上报 | Sentry | 90 天 |
| 使用事件 | 应用内 SDK | 数据分析 | Firebase / GA4 | 14 个月 |
| 崩溃数据 | Sentry SDK | 诊断 | Sentry | 90 天 |
| 购买信息 | StoreKit | 权益校验 | RevenueCat | 长期 |
| 用户内容 | 应用内输入 | 核心功能 | 你的服务器 (S3) | 删号前 |这张表就是唯一的事实来源——政策正文、问卷、Privacy Manifest 都要和它对上。
第 2 步 — 照着清单写政策
纯 HTML 或 markdown 都行。下面这个骨架覆盖了 App Review 实际会读的点：
<h1>隐私政策</h1>
<p><strong>最后更新：</strong>2026-06-01</p>
<h2>1. 我们收集什么</h2>
<p>账号：邮箱（你主动填）。使用：应用内事件和崩溃数据
（自动收集）。购买：交易 ID 和权益状态（经由 Apple）。</p>
<h2>2. 为什么收</h2>
<p>用于运行账号、恢复购买、修复崩溃、衡量功能使用。
不出售个人数据，也不会跨其他 App 或网站追踪你。</p>
<h2>3. 第三方处理者</h2>
<ul>
<li>RevenueCat — 购买记录（<a href="https://www.revenuecat.com/privacy">政策</a>）</li>
<li>Sentry — 崩溃与诊断（<a href="https://sentry.io/privacy/">政策</a>）</li>
<li>Firebase Analytics — 使用事件（<a href="https://firebase.google.com/support/privacy">政策</a>）</li>
</ul>
<h2>4. 你的权利</h2>
<p>发邮件到 privacy@yourapp.com 可申请导出或删除数据。
App 内也可在「设置 > 账号 > 删除账号」删号。</p>
<h2>5. 联系</h2>
<p>privacy@yourapp.com</p>「不出售 / 不追踪」这句很关键：它为你在第 3 步对 tracking 问题给出诚实的「No」做铺垫。
第 3 步 — 把每一行映射到 Apple 的 App Privacy 类目
Apple 问卷有 14 个固定的数据类目。典型独立 App 相关的几个映射如下：
Apple 类目 -> 你的清单行
Contact Info / Email Address -> 邮箱
Identifiers / Device ID -> 设备 ID (Sentry)
Identifiers / User ID -> 内部 user_id
Usage Data / Product Interaction -> 使用事件
Diagnostics / Crash Data -> 崩溃数据 (Sentry)
Purchases / Purchase History -> 购买信息
User Content / Other User Content -> 用户内容独立开发者常犯的一个错：把崩溃上报只归到 Identifiers。Sentry 的崩溃负载应归在 Diagnostics / Crash Data，它顺带采集的设备 ID 才单独归 Identifiers / Device ID。Apple 的完整清单还包括 Health & Fitness、Financial Info、Location、Sensitive Info、Contacts、Browsing History、Surroundings、Body、Other Data——只勾你真正用到的。
每个类目回答两件事：
- linked to user 还是 not linked？ 凡是绑到账号的（邮箱、user ID）都算 linked。
- 是否用于 tracking？ Apple 对 tracking 的定义很窄：把你的数据和第三方数据拼起来做定向广告或广告衡量，或把数据卖给 data broker。如果你只做第一方 analytics、不喂任何广告网络，诚实答案就是 No——意味着不弹 App Tracking Transparency 授权框，产品页上也不会出现「Data Used to Track You」那一栏。
第 4 步 — 写清楚数据删除（Apple 会专门查）
Guideline 5.1.1(v) 自 2022 年 6 月 30 日起就要求：凡是支持注册账号的 App 都必须支持应用内删号。审核员会真的去测。两条常被漏掉的规则：
- 「停用」或「禁用」开关不算合规——用户必须能删除账号以及关联的个人数据。
- 如果账号带自动续费订阅，删号流程必须告知用户「扣费会继续经由 Apple 进行」，并提示先单独取消订阅。
哪怕你的全部答案就是「在设置里删账号」，也要写进政策。删除前加身份核验步骤（比如确认邮件里的验证码）是允许的。
第 5 步 — 挂在稳定 URL 上
把政策挂在你自己域名的稳定 URL，比如 yourapp.com/privacy。别用 Notion 公开页、Google Docs、免费二级域名——这类 URL 会变或会过期，会被标记为不稳定。营销站跑在 Vercel、Firebase Hosting 或 Netlify 上，一个静态页就够。纳入版本管理：每次改都更新「最后更新日期」并提交 git，旧版本保留可访问（比如挂在 /privacy/2025-12-01），方便任何人审计变更。
第 6 步 — 政策 ↔ 问卷 ↔ 代码三方对齐
这三份东西必须一致。找漏掉的 SDK 最快的办法是 grep 源码：
grep -RIn --include='*.swift' -E 'Firebase|Sentry|RevenueCat|OneSignal|Mixpanel|Amplitude|Branch|Adjust|Facebook' .grep 出来、政策和问卷里没写的，提审前都得补上。然后确认这些 SDK 也出现在你的 PrivacyInfo.xcprivacy 里——Apple 发布了一份「常用 SDK 清单」，清单里的 SDK 既要带 manifest 也要带代码签名，缺一个就在上传时自动拒掉这个 build，根本轮不到人工审核看到。
容易踩的坑
- 直接照搬生成器的输出。 生成的政策动不动列一堆你根本不收的数据类型；审核员和用户都看得出来。只当骨架用。
- 漏了某个第三方 SDK。 Firebase Analytics 不管你「看不看那些数据」都算。
- 崩溃数据归错类目。 崩溃负载属于 Diagnostics，不是 Usage Data，也不是 Identifiers。
- 把政策当静态文件。 每加一个 SDK 或一个会收数据的大功能，都要同时更新政策和问卷。
- 政策和问卷对不上。 这是 2026 年最常见的隐私相关拒审——审核员会逐条对比。
- 跳过 Privacy Manifest。 它和政策是两回事，且在上传环节就检查；政策写得再完美，也救不了一个缺
PrivacyInfo.xcprivacy的 build。
FAQ
- 能用生成器生成的隐私政策吗: 当骨架可以，但必须改成符合你真实数据流的版本。通用生成政策会列你根本不收的类目，这本身就制造了「政策对不上问卷」。
- 独立 App 要不要找律师: App Store 政策本身一般不用，尤其是没欧盟用户的话。有欧盟 / 英国用户的话，GDPR 和 UK GDPR 合规（合法性基础、数据主体请求）值得让律师过一遍，这超出了 Apple 会查的范围。
- Privacy Manifest 和隐私政策是一回事吗: 不是。政策是挂在 URL 上的人读文本；manifest（
PrivacyInfo.xcprivacy）是 App 和 SDK 里一份机器读的 plist，声明 required-reason API 的用途。两者都要，且分开检查。 - 上线后加了新 SDK 怎么办: 同时更新政策正文、App Privacy 问卷和 Privacy Manifest。改 App Privacy 答案不需要重新出 binary，但政策 URL 必须反映变化，而加了清单里的 SDK 确实需要带更新后 manifest 的新 build。
- 政策要做多语言吗: 不强制，英文就够。非英语市场翻译能增加信任，但不是要求。
数据类目和 tracking 定义的权威措辞，见 Apple 的 App Privacy Details；应用内删号规则见 Offering account deletion in your app。
相关阅读
- 独立开发者上线 App 前要准备什么
- App Store 审核常见问题
- IAP / RevenueCat 入门
- App Store 4.3(b) 是什么
- App Store 截图设计转化模式（2026）
- 独立 App 内购定价：买断 vs 订阅、价格梯度怎么定
标签: #独立开发 #App Store #隐私政策 #App 审核