App Store 准则 2.1 应用完整性被拒：重新提交前的发布版本测试计划（2026）

因准则 2.1“应用完整性”被 App Store 拒绝，意味着审核人员无法像普通用户那样使用你的应用。它可能崩溃了、显示了占位内容、把审核人员挡在登录界面，或者隐藏了某个 App 内购买项目。修复它很少只需改一行代码。重新提交前，请在发布版本（release build）上执行一份简短的测试计划：使用全新安装，并使用你提供给 App Review 的同一套凭据。本文将逐步讲解这份计划，并展示其他开发者是如何解决同样的被拒问题的。

App Store 准则 2.1“应用完整性”检查的是什么？

准则 2.1 检查你提交的构建版本是否是一个已完成、可正常运行的应用。它需要完整的元数据、可用的链接、演示登录账户、在线的后端，以及审核人员能找到并使用的 App 内购买项目。

Apple 的 App 审核指南将 2.1 分为两部分。2.1(a) 规定，提交的内容“应当是包含所有必要元数据和完全可用 URL 的最终版本”，并应删除占位文本和空白网站。它还要求你在设备上测试缺陷和稳定性，并且“如果你的应用包含登录功能，请提供演示账户信息（并开启你的后端服务！）”。Apple “会拒绝不完整的应用包，以及会崩溃或存在明显技术问题的二进制文件”。2.1(b) 规定，App 内购买项目必须“完整、最新、对审核人员可见且功能正常”。如果某个已配置的购买项目在应用中找不到，请在审核备注中说明原因。

这类被拒非常常见。Apple 的准备 App 审核页面写道：“平均而言，超过 40% 的未解决问题与准则 2.1：应用完整性有关，涵盖崩溃、占位内容、信息不完整等情况。”

为什么测试调试版本发现不了 2.1 问题？

调试版本的运行方式与审核人员拿到的副本不同。审核人员会在一台干净的设备上安装经过分发签名的发布版本，没有已保存的会话，也没有任何调试捷径。

你的模拟器早已登录。你的本地 API 可能指向一个永远不会宕机的测试服务器。调试开关会跳过付费墙，功能开关默认处于开启状态。而审核人员什么都没有。Apple 的审核页面还要求你“在运行最新软件的设备上进行全面测试”，所以审核人员使用的 iOS 版本可能比你的测试手机更新。

TestFlight 是最接近审核人员环境的方式。根据 TestFlight 概览，你可以从 App Store Connect 团队中添加最多 100 名内部测试员，以及最多 10,000 名外部测试员。每个构建版本最长可测试 90 天。上传你计划提交的那个构建版本，在一台从未运行过该应用的设备上通过 TestFlight 安装，然后测试这个副本。

重新提交前，发布版本测试计划应该覆盖哪些内容？

发布版本测试计划要检查全新审核人员可能卡住的每一个环节：启动、权限、登录、后端、内容、链接、购买、网络故障和 iPad。请在 TestFlight 构建版本上按顺序执行以下步骤，并记录每一步的结果，以便在审核备注中引用。

1. 在最新 iOS 上全新安装。 删除之前的所有副本，从 TestFlight 安装，在没有任何已保存状态的情况下启动。冷启动三次，确认引导流程不会崩溃。
2. 每个权限请求都拒绝一次。 拒绝通知、定位、相机和跟踪权限。应用仍应能进入可用的界面。同时确认 Info.plist 中为应用及其 SDK 使用的每一项受保护资源都写了用途说明。
3. 使用完全一致的演示凭据登录。 从 App Store Connect 中复制凭据，而不是从你的密码管理器中复制。该账户应带有真实感数据，不需要邮箱验证，也不应使用绑定你本人手机的双重认证。
4. 确认后端是生产环境且在线。 构建版本必须指向生产环境接口。速率限制、IP 白名单和地区封锁都不能把审核人员挡在门外。准则 2.1(a) 明确要求你开启后端服务。
5. 逐一浏览每个标签页和界面。 检查是否有 lorem ipsum 占位文字、“即将推出”页面、没有任何说明的空状态、测试图片以及点击无反应的按钮。
6. 点击每一个链接。 包括隐私政策、支持、条款以及所有网页视图。Apple 规定：“所有应用都必须提供包含最新联系方式的用户支持链接和隐私政策链接。”
7. 打开每一个 App 内购买项目。 以新账户登录。检查随该版本提交的每个产品是否都显示价格、能否在沙盒环境中购买，以及“恢复购买”是否正常工作。
8. 在慢速或中断的网络下测试。 在操作流程进行到一半时开启飞行模式。显示清晰的错误提示没问题；一直转圈的加载动画或崩溃则不行。
9. 如果支持 iPad，请在 iPad 上检查。 如果应用可在 iPad 上运行，请在 iPad 上启动，确保布局不会让用户卡住。

第 3 步中的演示账户，是导致重复被拒最多的一步。我们的 App Store 审核演示账户设置指南介绍了如何搭建一个长期可用的账户。

如何把 2.1 被拒消息对应到具体修复？

要把 2.1 被拒消息对应到修复方法，请阅读准则编号后面的那句话。它指出了具体症状，而每个症状都对应测试计划中的某一步。

假设一个习惯追踪应用被拒，消息为“我们无法审核该应用，因为它在启动时崩溃。”另一条备注说审核人员无法找到 App 内购买项目。下表将常见症状与原因、测试和修复方法一一对应。

关于解读任何被拒消息的更通用方法，请参阅 App Store 被拒：逐条准则的修复方法。

其他开发者遇到的 2.1 被拒是什么样的？

公开的 2.1 案例都遵循同样的模式：应用在开发者的环境中运行正常，却在审核人员那里失败，原因是某些只有全新安装或陌生人登录才会暴露的问题。

• 缺少用途说明导致崩溃。 在 Solar2D 论坛上，一位开发者收到反馈：“我们无法审核该应用，因为它在启动时崩溃”，设备是运行 iOS 18.3.2 的 iPhone 13 mini，尽管该应用在 TestFlight 中运行正常。另一位成员在附带的崩溃日志中发现：“此应用已崩溃，因为它试图在没有用途说明的情况下访问隐私敏感数据。”该开发者反馈：“添加 NSUserTrackingUsageDescription 后通过了。”
• 审核人员无法使用社交账号登录。 Apple 开发者论坛上，一位开发者反映因审核人员“无法使用社交账号登录”而多次被以 2.1 拒绝。他们提供了 Apple 和 Google 演示账户，但 Apple ID 登录需要发送到开发者手机上的验证码。Apple 工作人员回复称 App Review 会直接联系他们。帖子中没有公开的解决方案。
• App 内购买项目“在提交的二进制文件中找不到”。 在 RevenueCat 社区帖子中，一位开发者因月度订阅方案在二进制文件中找不到而被拒，尽管沙盒购买可以正常进行。一位热心成员表示，类似的被拒问题曾通过回复详细的操作演示和通往付费墙所有路径的截图得到解决。RevenueCat 工作人员建议在默认付费墙上展示每个已提交的产品，并确保 Archive scheme 中不包含 StoreKit 测试文件。

在这三个案例中，开发者自己的测试都通过了。问题只有从审核人员的起点出发才会出现：没有接收双重认证的手机、没有之前的会话、也不知道付费墙在哪里。上面的测试计划正是在重现这个起点。

2.1 被拒后，App Review 备注应该写什么？

2.1 被拒后的审核备注应提供可用的演示凭据，列出自被拒构建版本以来的变更，并准确说明在哪里能找到 App 内购买项目及任何不明显的功能。

Apple 的审核页面要求将账户信息和特殊配置填写在“App 审核信息”部分。如果某项功能需要难以搭建的硬件或环境，“请准备好提供演示视频或硬件”。准则 2.3.1(a) 还补充道，新功能必须在审核备注中“具体”描述，并且“泛泛的描述将被拒绝”。一份简短、结构清晰的备注效果很好（Apple 审核人员通常阅读英文，下面的模板保持英文原样）：

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

如果法律或安全方面的义务导致无法提供演示账户，准则 2.1(a) 允许使用内置演示模式，但必须事先获得 Apple 批准，且该模式必须展示应用的全部特性和功能。未获批准前，请不要改用演示模式。

如何重新提交或申诉 2.1 被拒？

2.1 被拒后重新提交：上传或选择你测试过的构建版本，在 App Store Connect 中回复 App Review 说明你做了哪些修改，更新审核备注，然后再次提交。只有在你认为审核人员误解了应用时才提出申诉。

1. 确认 App Store Connect 中该版本关联的构建版本号，与你测试过的 TestFlight 构建版本一致。
2. 回复被拒消息，简要说明每项修复。如果是购买或导航问题，请附上分步操作说明和截图。
3. 在“App 审核信息”部分更新为最新的凭据和备注。
4. 提交审核。截至 2026 年 10 月，Apple 表示通常会“在 24 小时内审核至少 50% 的提交，在 48 小时内审核 90% 的提交”。

如果你认为 Apple 判断有误，可以通过 App 审核页面向 App 审核委员会提出申诉。请给出应用合规的具体理由，并且“每个未通过审核的提交只能申诉一次”。不过对于 2.1 被拒，在干净的设备上复现问题通常比争辩更快。如果你希望把重新提交交给别人处理，我们的 App Store 提交服务覆盖两大应用商店的审核准备和被拒反馈处理，价格为 $599，开发者账户费用另计。

2.1 问题常常会在后续更新中再次出现：新的功能开关、轮换过的 API 密钥或过期的演示账户。请把这份测试计划和 App Store 提交清单一起纳入你的发布流程。对于更新，分阶段发布可以限制漏掉的缺陷影响到的用户数量。如需对被拒的构建版本听听第二意见，请将被拒消息发送至 yagyeshsrbobde@gmail.com。