垂直产品用演示视频补足背景

通用计时器和相机的使用方式容易理解，连接专业数据库、企业流程或专用设备的应用需要更多说明。简短演示视频可以让审核员先看到正确路径，再对照 App 操作。^[1]

视频适合包含：

• 产品服务的用户和任务；
• 当前审核 Build；
• 从冷启动到登录的过程；
• 权限、授权和外部服务前提；
• 核心操作的完整输入与输出；
• 应用内购买出现的位置；
• 审核问题对应的修改结果；
• 录制设备和系统版本。

视频不应剪掉错误或用开发专用环境伪造成功。若凭证、客户数据、后台标识或通知内容进入画面，先使用专用样本并脱敏。附件只提供完成审核所需的信息，保留期限和访问权限也要受控。^[2]

数据披露要从真实数据流开始

App Store Connect 的 App Privacy 问题、商店隐私标签、应用内 Privacy Policy 和代码中的 Privacy Manifest 处在不同位置，必须共同描述同一套真实行为。

先画一张数据表：

表格需要覆盖开发者自己的代码，也包括广告、分析、身份、崩溃、模型、支付和其他第三方 SDK。Apple 当前要求 App Privacy 回答准确反映 App 与第三方伙伴的数据实践，并在实践变化时及时更新。所有 App 都需要在指定位置提供 Privacy Policy URL；政策还要在应用内易于访问，说明收集、用途、共享、保留、删除和用户选择。^[2][3]

平台表单只解决商店披露，不能自动证明符合所有适用法律。应用仍需按实际地区、用户和数据类型核对合法基础、同意、儿童、医疗、金融、跨境和删除要求。^[2]

Privacy Manifest 与 Required Reason API 要逐项核对

Privacy Manifest 文件名为 PrivacyInfo.xcprivacy，用于描述 App 或第三方 SDK 收集的数据、跟踪域名和 Required Reason API 的使用理由。Apple 当前文档要求相关 Bundle 分别报告自己使用的 API 类别和允许理由；无效 Manifest 或未声明适用 Required Reason API 会影响 App Store Connect 接收提交。^[3]

提交前可以完成：

• 用当前 Xcode 生成隐私报告；
• 检查 App 目标和每个相关 SDK 的 Manifest；
• 清理未使用但仍引入 API 或域名的 SDK；
• 将 API 用途对应到 Apple 允许的具体理由；
• 核对 Manifest、App Privacy 回答和 Privacy Policy；
• 对升级 SDK 后新增的数据和域名重新检查；
• 不把「SDK 自己收集」当作开发者无需负责。

Required Reason API 的范围和允许理由会更新，不应从旧项目复制一份 Manifest 长期使用。

登录、账号删除和购买是三条独立路径

登录服务

如果应用使用第三方或社交登录来创建或认证主要账号，Apple 当前 Guideline 4.8 通常要求同时提供一种满足数据最小化、隐藏邮箱和未经同意不作广告跟踪等条件的等价登录方式，并列出企业、教育、政府身份和特定第三方客户端等例外。^[4]

这不能简化成「所有有登录的 App 都必须提供 Sign in with Apple」。团队要按照当前登录实现和例外逐项判断，并在 Review Notes 里说明为什么适用或不适用。无论使用哪种登录方式，按钮、回调、关联域、取消和错误路径都要在全新设备测试。

账号删除

Apple 当前要求，支持在 App 内创建账号的应用也让用户在 App 内发起账号删除。只提供停用或冻结通常不够；删除流程要容易找到，说明需要多久、哪些数据因法律义务必须保留，并处理订阅和计费提示。若允许转到网页完成，应直接链接到删除页面，而非让用户自己寻找。^[3]

删除功能还需要真的穿过身份、业务数据库、文件、营销、分析和供应商系统。商店里出现一个「Delete Account」按钮，却没有后端删除链，只会把披露与实际行为进一步拉开。

In-App Purchase

如果在 App 内解锁数字功能、内容、订阅或虚拟项目，当前 Guidelines 通常要求使用 In-App Purchase。准备提交的商品应完整、可见、可购买并能恢复；若某个配置项目无法在当前 Build 中找到，要在 Review Notes 解释。商业模式不明显时，也应在元数据和审核说明中讲清楚。^[4]

App 版本、订阅和 IAP 可以作为同一 submission 的项目进入审核。所有项目都被接受后，整组提交才能完成；若部分项目有问题，可以按 App Store Connect 当前流程修改、移除或重新提交。^[4]

设备与平台声明决定审核范围

提交前检查 Xcode、App Store Connect 和产品页面中声明的每个平台、设备和系统版本。无意中支持 iPad、Apple Silicon Mac 或其他平台，会增加布局、输入、权限和功能路径。^[1]

即使产品主要面向 iPhone，也要根据实际兼容声明检查 iPad 上的运行表现。关键验收包括：

• 登录和授权按钮可见且可点击；
• Sheet、Popover、键盘和旋转不遮挡操作；
• 动态字体与系统缩放后仍能完成任务；
• 手势有可发现的替代操作；
• 空状态、加载、错误和完成状态清楚；
• 网络变化后不进入无法退出的死循环；
• 系统组件和自定义控件具备一致反馈；
• VoiceOver 标签、对比和焦点顺序可用。

原生组件可以降低基础交互和适配风险，却不能保证审核通过。第三方 UI 组件还要检查许可证、系统适配、可访问性、隐私依赖和维护状态。^[5]

提交前建立一份冻结清单

正式发送 App Review 前，先冻结一个候选 Build。继续开发可以在其他分支或版本进行，审核材料只能指向当前提交内容。

产品

• 核心流程完整；
• 无占位、崩溃、空链接和隐藏实验入口；
• 后台、账号、邮件、支付和外部服务可用；
• 错误可恢复；
• 支持入口有人响应。

Build

• Version、Build 和 Bundle ID 正确；
• Entitlements 与使用能力一致；
• 支持设备、平台和最低系统正确；
• 第三方 SDK 与许可证已检查；
• Archive 与提交 Build 一致。

元数据

• 名称、描述、截图和功能一致；
• Support URL 与 Privacy Policy URL 有效；
• 年龄分级、分类和地区准确；
• 新功能具体写明；
• IAP、订阅和协议信息完整。

审核信息

• 联系人可达；
• Demo Account 有效；
• Review Notes 可独立复现；
• 视频、样本和附件已脱敏；
• 所有前置条件已说明。

数据与权限

• App Privacy 与真实数据流一致；
• Privacy Manifest 和 Required Reason API 已核对；
• 第三方 SDK 的收集和共享已纳入；
• ATT 与系统权限在适用时正确实现；
• 账号删除、保留和供应商删除链可用。