App Store 分阶段发布会在七天内把版本更新推送给越来越多开启了自动更新的用户：第一天从 1% 开始，第七天达到 100%。如果你每天检查崩溃数据和客服邮件，一发现异常就立即暂停，那么有问题的构建只会影响一小部分用户，而不是你的全部用户。不过，分阶段发布有一个重大限制：它只控制自动更新。任何人仍然可以手动下载新版本。
App Store 分阶段发布能控制什么，不能控制什么？
分阶段发布只控制开启了自动更新的用户中，哪些人在什么时候收到你的版本更新。它不会对手动下载隐藏新版本，也不会让已经安装新版本的用户回退。
根据 Apple 的 App Store Connect 帮助文档：“在符合条件的设备上开启了自动更新的用户中，将随机抽取一部分用户接收更新，他们不会收到任何关于参与分阶段发布的通知。”该功能适用于 iOS、macOS 和 tvOS 的版本更新，因此不能用于 App 的首次发布。设置该功能需要账户持有人（Account Holder）、管理（Admin）或 App 管理（App Manager）角色。Apple 还指出：“处于分阶段发布中的 App 和 App 更新，任何人都可以随时从 App Store 手动下载。”
| 问题 | 分阶段发布的答案 |
|---|---|
| 谁会自动收到更新？ | 开启了自动更新的用户中，随机且逐步扩大的一部分 |
| 用户能手动下载吗？ | 可以，随时都行，与当前处于哪个阶段无关 |
| 暂停会撤回更新吗？ | 不会。它只停止后续的自动推送，已经收到更新的用户会保留该版本 |
| 最长可以暂停多久？ | 累计 30 天，暂停次数不限 |
| 可以跳过剩余阶段吗？ | 可以，使用“发布给所有用户”（Release to All Users） |
App Store 分阶段发布的节奏是怎样的？
截至 2026 年 11 月，节奏固定为七天内依次 1%、2%、5%、10%、20%、50% 和 100%，且无法修改。你能控制的是何时暂停，以及何时直接跳到 100%。
把每一天都当作一个检查点，最后只做一个决定：继续，还是暂停。
| 天数 | 用户比例 | 进入下一阶段前要检查什么 |
|---|---|---|
| 1 | 1% | 无崩溃会话率、启动错误、登录和购买成功率 |
| 2 | 2% | 客服收件箱、提及此次更新的新一星评价 |
| 3 | 5% | 后端错误率以及新客户端带来的 API 负载 |
| 4 | 10% | 与上一版本相比的转化率和留存率 |
| 5 | 20% | 按设备和系统版本聚集的崩溃 |
| 6 | 50% | 高峰期服务器容量，以及任何缓慢显现的数据问题 |
| 7 | 100% | 推送完成；Apple 会通知拥有管理（Admin）和 App 管理（App Manager）角色的用户 |
如何在 App Store Connect 中开启分阶段发布？
分阶段发布在版本页面的“自动更新的分阶段发布”（Phased Release for Automatic Updates）中开启，在更新上线前的任何时候都可以设置。你不必在提交审核前就做出决定。
当版本处于以下状态时，Apple 允许开启：准备提交（Prepare for Submission）、等待审核（Waiting for Review）、正在审核（In Review）、等待出口合规（Waiting for Export Compliance）、等待开发者发布（Pending Developer Release）、开发者已拒绝（Developer Rejected）、已被拒绝（Rejected）或元数据被拒绝（Metadata Rejected）。
- 在“App”中选择你的 App，然后在侧边栏点击你要提交的版本。
- 滚动到 自动更新的分阶段发布（Phased Release for Automatic Updates）。
- 选择 使用分阶段发布在 7 天内发布更新（Release update over a 7-day period using phased release）。
- 点击 存储（Save）。审核通过后，状态会显示为“可供分发”（Ready for Distribution），旁边标注“分阶段发布”（Phased Release）。
你也可以通过 App Store Connect API 管理分阶段发布；如果你的发布流程已经脚本化，这会很方便。
什么时候应该暂停分阶段发布？30 天上限如何计算？
一旦触发了你事先约定的任何一个暂停条件，就立即暂停。暂停时间累计最多 30 天；恢复后，推送会从暂停时所在的那一天继续。
在发布日之前就把暂停条件写下来，这样就不会在用户遇到 bug 时还在争论要不要暂停。好的暂停条件要具体：无崩溃会话率低于上一版本的基线、结账或登录失败达到可衡量的比例，或者多名用户报告了同一个 bug。
要暂停，打开处于“可供分发”状态的版本，选择 暂停分阶段发布（Pause Phased Release） 并点击存储。要恢复，选择 使用分阶段发布（Use Phased Release）。Apple 给出的例子是：如果你暂停 10 天后恢复，那么你还剩 20 天可以暂停。在这个总时长内，你可以暂停任意多次。要跳过剩余阶段，点击版本页面右上角的 发布给所有用户（Release to All Users）。
出现 bug 时，分阶段发布的实际流程是怎样的？
出现 bug 时，你需要暂停、修复，然后再次开启分阶段发布来推送新版本。在你修复期间，仍在等待自动更新的用户会停留在上一个版本。
假设 3.4 版本替换了你的同步引擎。第一天，1% 的自动更新用户收到了它，你检查了两次崩溃报告工具和同步错误日志。第三天，在 5% 阶段，某个较旧的 iOS 版本上出现了一批同步失败。你立即暂停。受影响的用户远少于全员推送的情况，而尚未收到更新的自动更新用户仍停留在 3.3。
接下来，修复 bug，并在开启分阶段发布的情况下提交 3.4.1。要在 release 构建中测试修复，而不仅仅是在 debug 构建中测试；我们的 release 构建测试计划 介绍了这一步。在 3.4.1 的版本说明中明确写出同步问题已修复；我们的 版本说明示例 展示了写法。如果修复很紧急且你对它有信心，审核通过后可以直接使用 发布给所有用户（Release to All Users），而不必再等一周。
再加一道保险：把新的同步引擎放在服务端开关后面。暂停能阻止更新继续扩散，而开关能为已经安装了 3.4 的用户关闭高风险代码。两者配合使用效果最好。
其他开发者在暂停分阶段发布时遇到过哪些问题？
公开讨论中反复出现同一种情况：开发者暂停了有 bug 的版本，却不确定后续的分阶段发布对已经收到旧版本的用户意味着什么。Apple 的文档没有回答这个问题，所以请按照“修复版本需要单独完整推送一轮”来做计划。
- 一位开发者在 Apple Developer Forums 上表示，他们“发现了一个崩溃，暂停了更新推送，修补了 App，上传后又开始了一轮新的分阶段发布”，当时使用有问题构建的用户不到 10%。他们询问新一轮推送是否会覆盖同一批用户。该帖子始终没有得到官方答复；有一条回复说，8.0 的用户“应该会在 8.1 一发布就收到有 8.1 可更新的提示”。
- 在 另一个论坛帖子 中，一位开发者说，由于一个严重 bug，他们在 15.0.1 版本上“停在了 1%”，并希望 15.0.2 也分阶段推送，期望 15.0.1 能“对大多数用户来说基本被跳过”。该帖中较早的一条回复建议，在有 bug 的版本暂停期间申请加急审核，甚至可以考虑将 App 下架，“这样就不会有新用户下载到有问题的版本”。在这样做之前，请记住上面提醒框中关于下架的规则。
- 发布工具团队在 Tramline 的 store-quirks 笔记 中记录：开始一次新的发布“会直接取消现有的推送”，旧版本会变为
REPLACED_WITH_NEW_VERSION，其分阶段发布被标记为COMPLETE。同一份笔记还指出，暂停“对已经收到更新的用户无能为力”。
这三个案例的共同点是：暂停只能争取时间。真正的修复总是一个新版本，而且没有人能确定同一批用户会最先收到更新。这就是为什么服务端开关和一个能快速发布的热修复分支，比暂停按钮更重要。
Google Play 的分阶段发布有何不同？
Google Play 的分阶段发布使用你自己选择并手动调高的百分比。暂停后恢复，覆盖的仍是同一批用户。两个商店的推送计划要分开制定。
根据 Play 管理中心帮助，“你的应用的分阶段发布百分比不会自动增加”，并且分阶段发布“只能用于应用更新，不能在首次发布应用时使用”。暂停后，已经收到该版本的用户会保留它；Google 建议发布一个包含修复后 bundle 的新版本，而不是恢复一个有问题的版本。正式版推送可以限定在特定国家/地区，但一旦开始，就无法移除国家/地区。如果你的下一个 Android 更新还需要满足新的目标 SDK 要求，请参阅我们关于 Google Play 目标 API 级别 36 的指南。
| 功能 | App Store 分阶段发布 | Google Play 分阶段发布 |
|---|---|---|
| 推送节奏 | 固定的 7 天曲线 | 由你设定并调高百分比 |
| 停止控制 | 暂停，累计 30 天 | 暂停，然后恢复或替换 |
| 覆盖对象 | 开启了自动更新的随机用户 | 随机的新用户和现有用户 |
| 首次发布 | 不可用 | 不可用 |
| 按国家/地区定向 | 不属于该功能 | 正式版发布可用 |
开始分阶段发布前应该检查什么？
在推送开始前，确保版本上已保存分阶段发布设置，基线和暂停条件已经写下来，并且修复版本可以快速发布。使用以下清单：
- 已在版本页面选择并保存分阶段发布
- 已收藏崩溃报告和后端错误看板，并记录上一版本的基线数据
- 已写下暂停条件，并得到所有有权按下暂停按钮的人同意
- 高风险功能已放在服务端开关后面
- 7 天中每天都有指定负责人检查指标
- 热修复分支已准备就绪，后续构建可配合我们的 App Store 提交检查清单
- 商店页面的改动暂缓，直到推送覆盖所有用户
如果你更希望把发布工作本身交给别人，我们的 App Store 提交服务 涵盖 App Store Connect 和 Play 管理中心的设置、审核准备以及两个商店的发布，费用为 $599（开发者账号费用另计）。如果你想为一次高风险更新听听第二意见，请发送邮件至 yagyeshsrbobde@gmail.com，附上你的 App 以及此次更新的改动内容。
常见问题
在 App Store 分阶段发布期间，新用户会拿到新版本吗？
会。分阶段发布只限制现有用户的自动更新。Apple 的 App Store Connect 帮助文档指出，处于分阶段发布中的 App 和 App 更新，任何人都可以随时从 App Store 手动下载。打开你的 App Store 页面并点击“更新”或“获取”的用户会收到新构建，即使是在第一天或推送暂停期间也是如此。
可以在 App Store 上回滚 iOS App 更新吗？
不可以。App Store Connect 没有回滚功能。暂停分阶段发布会停止后续的自动更新，但已经安装该版本的用户会保留它。要补救，请提交修复后的版本，最好再次开启分阶段发布；如果 bug 很严重，可以申请加急审核。服务端功能开关可以为已经更新的用户关闭出问题的代码。
可以修改 App Store 分阶段发布的百分比吗？
不可以。截至 2026 年 11 月，Apple 使用固定曲线：七天内依次为 1%、2%、5%、10%、20%、50% 和 100%。你唯一能做的是暂停、恢复，以及使用“发布给所有用户”（Release to All Users），这会立即把更新推送给所有开启了自动更新的用户。如果你需要自己设定百分比，那是 Google Play 分阶段发布的机制，而不是 Apple 的。
App 的第一个版本可以使用分阶段发布吗？
不可以。Apple 只在你提交 iOS、macOS 或 tvOS 的版本更新时提供分阶段发布。Google Play 也有同样的限制：分阶段发布只能用于应用更新，不能在首次发布应用时使用。对于首次上线，请在发布前使用 TestFlight 或封闭测试来降低风险。
分阶段发布完成时，Apple 会通知我吗？
会。分阶段发布完成后，App Store Connect 会通知所有拥有该 App 访问权限、且角色为管理（Admin）或 App 管理（App Manager）的用户。Apple 的文档没有把账户持有人（Account Holder）列为会收到通知的角色，所以如果只有账户持有人在关注发布情况，请给一位团队成员分配上述角色之一，或者自己检查版本状态。
来源与延伸阅读
政策会变化。提交前请查阅官方文档。
- 分阶段发布版本更新 – App Store Connect 帮助 ↗核查于 2026年11月1日
- 通过分阶段发布来发布应用更新 – Play 管理中心帮助 ↗核查于 2026年11月1日
- 在分阶段发布中途更新时会覆盖同一批用户吗？– Apple Developer Forums ↗核查于 2026年11月1日
- 在分阶段发布暂停期间更新 – Apple Developer Forums ↗核查于 2026年11月1日
- tramlinehq/store-quirks：向 App Store 和 Play 商店发布应用的常见问题与坑 – GitHub ↗核查于 2026年11月1日
