app-store-review

App Store 审核准备

在提交前发现 App Store 被拒风险。将政策、SDK、隐私、授权、支付和元数据检查视为当前版本的证据，而非持久性事实。

常见被拒原因及避免方法
PrivacyInfo.xcprivacy —— 隐私清单要求
数据使用、共享和隐私政策（准则 5.1.2）
应用内购买和 StoreKit 规则（准则 3.1.1）
HIG 合规检查清单
App 跟踪透明度（ATT）
欧盟数字市场法案（DMA）注意事项
授权和功能
提交流程
元数据最佳实践
申诉流程
常见错误
审核检查清单
参考资料

每次审计开始时，获取当前的 App Review Guidelines、Upcoming Requirements、截图规格、必需理由 API 文档以及适用的商店/授权支付规则。在每条发布阻塞项旁记录检查日期和来源。然后归档构建并验证确切的提交，将阻塞项与清理项分开，修复一类证据不匹配，然后对重建的归档重新运行相同的检查。

对于关于关键词、截图说明、产品页面元数据或元数据被拒风险的提示，从合规角度回答，并明确将关键词研究、排名策略、转化优化、截图排序和 A/B 测试委托给 app-store-optimization。将 App Review 元数据指导限制在准确性、字段限制、误导内容风险和截图合规性方面。从当前版本要求加载日期格式、截图和工具链事实。

对于完整的提交就绪审计，将阻塞上传/审核的问题与常规清理分开。交叉检查隐私清单、App Store 隐私营养标签、隐私政策、ATT 状态、运行时网络行为和 SDK 行为；声明和观察到的行为必须一致。

阻塞提交检查

在常规清理之前，将这些升级为阻塞项：

归档缺少当前的 Xcode 或平台 SDK 上传最低版本
未解决的隐私证据不匹配；根据 PrivacyInfo.xcprivacy 要求进行协调
不符合 StoreKit 规则的支付路径
缺少当前 App Store Connect 规范要求的截图集
审核访问不满足以下准则 2.1 完整性证据

常见被拒原因及避免方法

准则风险	发布证据
2.1 完整性	无占位符、无中断/空流程、无仅硬件功能、无登录门控（需提供有效的演示凭据和审核备注）。
2.3 元数据	应用名称、类别、描述、关键词和截图准确代表提交的二进制文件和实际 UI。
4.2 最低功能	应用提供有意义的特定应用价值，而非简单的网站封装或系统行为的琐碎复制。
2.5.1 软件要求	归档使用公共 API，且不下载更改已审核功能的代码（文档记录的例外情况除外）。

根据当前指南和确切归档验证这些内容；不要将版本或截图要求从旧版本检查清单中沿用。

PrivacyInfo.xcprivacy —— 隐私清单要求

当你的应用代码、可执行文件、动态库或第三方 SDK 使用 Apple 的必需理由 API 类别或声明收集数据/跟踪行为时，需要隐私清单。

参见： references/privacy-manifest.md 了解完整结构、理由代码和检查清单。

摘要

必需理由 API 类别包括文件时间戳、系统启动时间、磁盘空间、活动键盘和 UserDefaults；每个类别在使用时需要批准的理由代码。
在最终提交前，重新检查 Apple 当前的必需理由 API 文档，不要选择宽泛、方便或编造的理由代码。
必需理由 API 声明应放在包含使用该 API 的代码的 bundle 中；每个包含清单相关代码的应用 target、可执行文件、动态库、框架或 SDK bundle 都需要匹配的清单声明。
每个收集数据、使用必需理由 API、启用数据收集/跟踪或联系跟踪域名的 SDK、可执行文件或动态库，都需要在其代码所在的 bundle 中进行清单处理；SDK 代码不能依赖宿主应用的清单来报告 SDK 自身的使用情况。
清单声明必须与 App Store 隐私营养标签、SDK 行为以及应用呈现的功能相匹配。

数据使用、共享和隐私政策（准则 5.1.2）

必须在 App Store Connect 中设置隐私政策 URL，并且在应用内可访问
隐私政策必须准确描述你收集哪些数据、如何使用以及共享给谁
App Store 隐私营养标签必须与实际数据收集实践一致
隐私标签、隐私清单、SDK 披露和运行时行为应讲述相同的故事

应用内购买和 StoreKit 规则（准则 3.1.1）

数字商品、功能、订阅、虚拟货币、去广告和数字小费通常需要 IAP，除非当前指南例外、商店规则或批准的授权适用。实物商品和现实世界服务使用其常规支付流程。购买前显示价格、时长、续订/试用条款、计费频率和取消条款；验证产品分类、恢复、授权验证、延迟/中断购买和 Ask to Buy。加载 storekit 以获取实现细节，并在标记路径合规前重新检查当前区域/外部链接规则。

HIG 合规检查清单

从 review-checklists.md 加载完整的 HIG 检查，包括导航、模态、小组件、系统功能、启动屏幕和空状态。

App 跟踪透明度（ATT）

何时需要 ATT

如果你的应用跨其他公司的应用或网站跟踪用户，你必须：

在任何跨应用或跨网站跟踪发生之前，通过 ATTrackingManager.requestTrackingAuthorization 请求权限，包括具有跟踪能力的 SDK 行为
尊重用户的选择 —— 如果用户拒绝权限，则禁用跨应用和跨网站跟踪
不要将应用功能与跟踪同意绑定（“接受跟踪否则无法使用此应用”会被拒绝）
在 NSUserTrackingUsageDescription 中提供清晰的目的字符串，解释跟踪的用途

何时不需要 ATT

如果你不跨应用或网站跟踪用户，则不要显示 ATT 提示。Apple 会拒绝不必要的 ATT 提示。

ATT 实现

import AppTrackingTransparency

@MainActor
func requestTrackingPermission() async {
    let status = await ATTrackingManager.requestTrackingAuthorization()
    switch status {
    case .authorized:
        // 启用跟踪，初始化带跟踪的广告 SDK
        break
    case .denied, .restricted:
        // 使用非个性化广告，禁用跨应用/跨网站跟踪
        break
    case .notDetermined:
        // 请求后不应出现，优雅处理
        break
    @unknown default:
        break
    }
}

时机： 在应用激活且用户了解为何请求跟踪后，再请求 ATT 权限。不要在首次启动时立即显示提示，也不要与其他系统权限提示叠加。

欧盟数字市场法案（DMA）注意事项

替代分发、浏览器引擎、公证和外部支付路径是特定区域和授权的。重新检查当前商店规则，并将不支持的路由视为阻塞项。

授权和功能

每个授权都需要一个活动功能、一个适用的使用描述（如适用）以及匹配的归档行为。使用授权和使用描述中的表格和有效的属性列表示例。

提交流程

提交前步骤

在 Xcode 中归档。 Product > Archive（需要 Distribution 签名身份）。验证归档在 Release 配置下构建干净且零警告。
上传到 App Store Connect。 使用 Organizer 窗口（Distribute App > App Store Connect）或 xcodebuild -exportArchive。通过 altool 或 Transporter 自动上传也可行。
TestFlight 内部测试。 构建在处理后几分钟内可供内部测试人员（你的团队）使用。在至少两种设备尺寸上遍历每个屏幕和流程。
TestFlight 外部测试。 外部组在首次外部分发前需要 Beta App Review。在完整提交前使用此功能与真实用户验证。
提交 App Review。 在 App Store Connect 中，选择构建，填写所有元数据字段，附加截图，然后点击提交审核。审核时间不定；为拒绝、申诉和元数据修复预留缓冲。

加急审核请求

仅在 Apple 记录的严重或时间敏感情况下请求加急审核，在 App Store Connect 的 Contact Us 表单中使用简洁的事实理由。

分阶段发布

使用分阶段发布计划了解发布百分比和 App Store Connect 控制。

元数据最佳实践

确保名称、副标题、关键词、截图和预览与提交的二进制文件和实际 UI 准确一致。不要使用价格、竞争对手术语或误导性声明。应用元数据合规检查清单中的字段限制和媒体规则，并将研究、排名、转化、截图排序和 A/B 测试委托给 app-store-optimization。

申诉流程

在 App Store Connect 的 Resolution Center 中回复，提供简洁的证据链：

[ ] 将拒绝映射到引用的指南和确切的提交行为。
[ ] 如果已修复，指出具体更改并重新提交；如果存在争议，解释提交如何满足每个相关要求。
[ ] 附上重现合规所需的证据，例如有效的演示凭据、截图或重点视频演示。
[ ] 如果交流仍未解决，通过 Resolution Center 或 App Store Contact 表单（App Review > Appeal）请求 App Review Board 升级，包括完整的提交历史和支持证据。

Board 的决定对该提交是最终的；修改应用并重新提交仍然可用。