APP STORE GUIDELINE 5.1.1

App Store 5.1.1 隐私拒审整改清单

5.1.1 的核心不是“你有没有放隐私政策”,而是“你收集了什么、为什么收集、什么时候收集,以及用户是否被明确告知”。如果声明和实际行为对不上,审核几乎一定会追问或直接拒绝。

获取 5.1.1 建议查看 iOS 拒审指南

5.1.1 高频触发场景

命中这些情况时,不要只改一份文本,最好把权限、问卷、政策页和实际触发链路一起梳理。

01 问卷与真实行为不一致

App Store Connect 里写“不收集数据”,但 SDK 实际上传设备标识、崩溃日志或用户行为数据。审核和抽检很容易发现这类冲突。

02 权限用途写得太空

相机、相册、定位、麦克风权限只写“优化体验”“提升服务”,没有对应到具体功能场景,审核通常会要求补充说明。

03 ATT 时机不合理

应用一打开就弹 ATT,用户还没理解价值场景,也没有前置说明。即使没有直接违规,也很容易被认为缺少充分告知。

04 隐私政策像模板

政策页只写大而空的条款,没有列清数据类型、收集目的、第三方服务和用户删除路径,审核很难确认你是否真的合规。

图文拆解:审核到底在核对什么

下面两张图可以帮助团队快速理解 5.1.1 的检查重点:不是看你“有没有页面”,而是看“口径是否一致且可验证”。

App Store 5.1.1 隐私风险判断示意图
图 1:审核核对路径。通常会从 App Store Connect 隐私问卷、应用内权限触发、ATT 弹窗、隐私政策四个点交叉检查。任一环节口径不一致,都可能触发 5.1.1。
App Store 5.1.1 整改前后对比图
图 2:整改前后对比。整改后的重点不是“说得更多”,而是“说得更具体”:什么时候收集、收集什么、为了什么、用户如何关闭或删除。

结论摘要

App Store 5.1.1 的实质,是让审核员在极短时间内判断:你的数据收集是否透明、权限是否合理、说明是否可验证。很多团队的问题不在于完全没做,而在于“每个位置都写了一点,但彼此对不上”。比如 App Store Connect 问卷写得很保守,应用内却接入了统计或广告 SDK;或者隐私政策写了定位用途,但应用里实际只在别的功能节点突然索权。只要这种“口径碎片化”存在,被拒概率就会很高。

更稳的做法是把隐私整改视为一次“全链路统一”:先列出实际收集的数据类型和第三方 SDK,再核对 App Store 隐私问卷、权限说明文案、ATT 触发时机、隐私政策正文、账号删除路径是否完全一致。做到这一点后,再在审核备注中写清“改了哪里、怎么验证”,通过率会明显提升。

  • 先梳理真实数据流,再写声明;不要反过来先写一份模板政策。
  • 权限解释要对应具体功能场景,避免用“优化体验”这类空泛表达。
  • ATT、隐私政策、问卷和应用内行为必须四点一致,缺一不可。

8 步操作清单(提交前)

  • 整理一张数据流清单:收集哪些数据、在哪个页面收集、通过哪个 SDK 收集、用途是什么。
  • 对照 App Store Connect 隐私问卷,逐项核验是否与真实行为完全一致。
  • 重写权限说明文案,把“为什么需要权限”写成具体功能场景,而不是抽象收益。
  • 检查 ATT 触发时机,先给前置解释,再在合理页面触发系统弹窗。
  • 补齐隐私政策:数据类型、用途、第三方服务、保存与删除机制、联系方式。
  • 如果提供账号体系,补充账号删除入口或删除申请路径,并确保审核可验证。
  • 把截图、描述和功能流程与隐私声明对齐,避免夸大“不收集”“完全匿名”等表述。
  • 审核备注按“数据说明-权限触发-ATT 时机-验证路径”四段写清楚,帮助审核快速复现。

FAQ

5.1.1 最常见的拒审原因是什么?+
通常是数据声明与实际行为不一致、权限用途写得太笼统、ATT 时机不合理,或隐私政策缺少关键细节。
只补一份隐私政策就能过吗?+
多数情况下不够。审核会同时看隐私问卷、应用内权限触发、ATT 弹窗和你的政策页是否彼此一致。
ATT 应该什么时候弹?+
建议在用户理解功能价值后,再通过前置解释引导触发。太早弹通常缺少合理性,也不利于通过率。
审核备注需要写哪些点?+
写清楚收集什么数据、哪个页面触发哪些权限、ATT 在哪里弹出、隐私政策链接在哪里,以及如何验证本次改动。
如何降低二次因隐私问题被拒?+
一次性统一问卷、权限说明、政策页和实际行为,不要只改其中一处。必要时同步排查第三方 SDK 的数据行为。