Devoria
iOS 应用更新发布：App Store 分阶段发布指南
作者：Mehdi Azizi
发布于 ，10分钟
发布 iOS 更新：新建版本、上传新构建版本、填写新内容说明，再选择手动、自动或 7 天分阶段发布。
要发布 iOS 更新，你需要在 App Store Connect 里新建一个版本，版本号要比之前的高。然后给它关联一个新的构建版本（build），写好“What's New”文案，再提交给 App Review。每个新版本都要重新经过 Apple 审核，哪怕只是一个小修复。 提交之前，你要选好通过审核后怎么发布：手动发布、立即发布、不早于某个日期发布，或者在 7 天内分阶段发布。
分阶段发布只影响自动更新：第一天推给其中 1% 的用户，第七天推给全部。你可以暂停，累计最多 30 天，也可以一次性全部放出。本指南依据 Apple 的帮助页面，我在 2026 年 11 月 3 日重新核对过。
我用 Expo 和 EAS 发布自己 iOS 应用的更新，包括 Solys、TradaZen 和 Nolera。下文提到的案例都来自这些版本的发布。
发布 iOS 更新：按顺序走的步骤
App Store Connect 关于新版本的帮助页给出了这个流程：
- 在 Apps 中选择你的应用，然后点击平台旁边的 + 按钮。
- 输入一个比上一个更高的版本号，然后点击 Create。
- 检查元数据：线上版本的元数据会被自动复制过来。
- 上传一个新的构建版本，构建号要递增。
- 在 TestFlight 中测试这个构建版本，把它添加到版本中，然后提交给 App Review。
开始之前有两个条件。线上版本的状态必须是 Ready for Distribution。而且你需要以下角色之一：Account Holder、Admin、App Manager 或 Marketing。
没有回滚这回事。 Apple 在同一页面上写明了：如果某个版本出了问题，你无法退回到上一个版本，只能新建一个版本再提交。
版本号和构建号
版本号是用户在你的产品页上看到的数字。构建号用来标识每一次上传。版本号和构建号的组合必须唯一：相关规则和报错见版本号与构建号。
我的习惯（不是 Apple 的规定）：修复 bug 时最后一位加一，比如 1.4.0 到 1.4.1。新增功能时中间一位加一，比如 1.4.1 到 1.5.0。构建号则只增不减，跨版本也一样。用 Expo 的话，版本号写在 app.json 里，EAS 可以在每次生产构建时自动递增构建号。具体设置见用 EAS 发布 Expo 应用。
“What's New”文案：Apple 的要求
版本信息页面描述了 What's New in This Version 字段：
- 最多 4,000 个字符。
- 首个版本没有这个字段，之后的每个版本都必填。
- 可以为产品页的每种语言分别翻译。
App Review Guidelines 第 2.3.12 条还有一项要求：清楚描述新功能和产品变化。如果只是普通的 bug 修复、安全或性能改进，写一句概括性的话就够了。重大变化必须列出来。 所以，如果一个版本改动了你的订阅或主界面，只写“Bug 修复和改进”是不够的。
Apple 在关于评分和评论的页面上也建议：如果用户在评论里反映过的问题已经修好，就在更新说明里提一下。
下面是三个可以套用的模板，每种版本类型一个。
修复类版本：
修复与稳定性改进。
- [功能]：[之前出问题的地方] 已修复。
- [页面] 加载更快了。
感谢反馈问题的各位。
新功能版本：
新功能：[功能名称，五个字左右]。
[你现在可以做什么，一句话。]
入口：[标签页] > [按钮]。
本版本还包括：
- [可见的改进]。
- Bug 修复。
流程变化的版本：
[页面或流程] 有变化。
- 对你的影响：[具体效果]。
- 保持不变的：[数据、设置、购买]。
有问题？[设置] > [帮助]。
修复模板的最后一行，只有在真的有人反馈过这个问题时才写。永远不要写构建版本里没有的新功能：第 2.3 条要求元数据与应用实际内容一致。
手动发布、自动发布或定时发布
关于发布选项的帮助页提供了三种方式：
| 选项 | Apple 审核通过之后 |
|---|---|
| 手动 | 状态为 Pending Developer Release，你想什么时候发布都行 |
| 自动 | 审核一通过就发布 |
| 自动，但不早于某日期 | 等到你选定的日期，然后自动发布 |
手动发布时，你打开状态为 Pending Developer Release 的版本，点击 Release This Version，然后确认。Apple 提醒说，版本可能最多需要 24 小时才会出现在 App Store 上。版本页面上会有一条提示，提供 Cancel This Release 用来取消。如果版本等待超过 30 天，Apple 会发邮件提醒你。
手动发布的用处是自己挑时机，比如在发布公告当天上线。Solys 2.0.0 带了新版年度订阅，2026 年 9 月底以手动发布的方式提交审核。
日常版本我就选自动发布。Nolera 1.0.2 在 2026 年 10 月 12 日通过审核，根据 iTunes 公开搜索 API 的数据，它在 Apple 邮件发出后不到一分钟就出现在 App Store 上了。这只是一次观察，时间上还是要留足余量。
7 天分阶段发布
Apple 关于分阶段发布的帮助页给出了具体时间表：
| 天数 | 用户比例 |
|---|---|
| 1 | 1% |
| 2 | 2% |
| 3 | 5% |
| 4 | 10% |
| 5 | 20% |
| 6 | 50% |
| 7 | 100% |
更新会推送给开启了自动更新、且设备兼容的用户中的一个随机样本。他们不会被告知自己在样本里。
分阶段发布只限制自动更新。 Apple 明确说明，任何人都可以随时从 App Store 下载新版本。所以，新安装你应用的人，或者在你的产品页上点“Update”的人，第一天就能拿到新版本。这不是在 1% 的用户身上做测试，而是对其他用户踩了一脚刹车。
开启方法：打开版本，往下滚到 Phased Release for Automatic Updates 部分，勾选“Release update over a 7-day period using phased release”，然后保存。需要 Account Holder、Admin 或 App Manager 角色。这个选项在 Pending Developer Release 状态之前都可以设置：即使 Apple 已经审核通过，只要版本还在等你手动发布，你仍然可以开启它。
版本通过审核后，它的 Ready for Distribution 状态旁会显示“Phased Release”。7 天结束时，该应用的 Admin 和 App Manager 会收到通知。
暂停、恢复和全量发布
- 暂停：累计最多 30 天，次数不限。暂停了 10 天，后面就还剩 20 天可用。
- 恢复：从你暂停的那一天接着推进。
- 全量发布：版本页面右上角的 Release to All Users 按钮，会把更新推送给所有开启自动更新的设备。
- 下架：会彻底终止分阶段发布，你的开发者计划会员资格过期时也一样。如果应用重新上架，该版本会一次性对所有人开放。
全量发布之后就什么都不能调了，可编辑属性一览表写得很清楚。
Nolera 1.0.2 发布时没有用分阶段发布。下面是我在这一周里会怎么用它：
| 你看到的情况 | 你的操作 | 结果 |
|---|---|---|
| 出现崩溃或让人担心的评论 | 暂停 | 自动更新停止 |
| 修复已经准备好 | 新版本 | 重新审核，并有自己的分阶段发布 |
| 3 到 4 天后一切正常 | Release to All Users | 所有人都收到更新 |
| 你在等 Apple 的回复 | 暂停，累计 30 天 | 从暂停那天接着推进 |
暂停期间，手动下载照常进行。凡是涉及付费或首次启动的版本，都勾上分阶段发布：这些地方出问题代价最大，而且你没法回滚。
修复很紧急：加急审核
Apple 允许你申请加急审核。它只用于真正的紧急情况：需要修复的严重 bug，或者与某个活动绑定的发布。
- 先提交你的版本。在给审核员的 Notes 字段里描述这个 bug。
- 填写加急审核申请表，选择你的应用和平台。
- Apple 会视情况加快审核，但不作任何保证。
如果是为了活动，在备注里写明活动日期以及你和它的关系。常规审核时长见 App Store 审核需要多久。
哪些改动要重新审核，哪些不用
| 改动 | 需要做什么 |
|---|---|
| 原生代码、权限、SDK 版本 | 新构建版本、新版本、完整审核 |
| 截图、描述、关键词、新内容说明 | 一个新版本，随版本一起审核 |
| 推广文本 | 不需要：无需重新提交即可修改 |
| 暂停、恢复、全量发布 | 不需要：这些是发布设置 |
| iOS 27 产品页头图 | 单独在 Asset Library 中提交，或随版本提交 |
| JavaScript 修复（Expo） | 可以用远程更新 |
根据版本信息页面，推广文本无需重新提交即可修改。用 Expo 的话，远程更新可以修改 JavaScript、文字和图片，不用经过 App Store。Expo 文档给出了两条限制：原生代码、权限和 SDK 版本需要新的二进制包；而且更新必须遵守 App Store 的规则。
我的案例：审核员从没看到的远程修复
2026 年 9 月，Nolera 有个构建版本在排队等审核。我修好了扫描页面的一个缺陷，并在等待期间以远程更新的方式发布了这个修复。结果构建版本还是被拒了，理由正是这个已经修好的缺陷。
原因写在 expo-updates 文档里：默认情况下，应用在启动时下载更新，并在下一次启动时应用。审核员安装应用、启动一次，测试的是构建版本里自带的代码。你的新用户也一样：他们的第一次使用跑的是构建版本里的代码。
从那以后，首页、付费墙或核心功能的任何改动，我都放进新的构建版本。远程更新只服务于已经装了应用的人。
随版本重置评分
每个新版本都有 Reset rating when this version is released 选项。根据 Apple 关于重置评分的帮助页，它对所有国家和地区生效，保留文字评论，并且发布后无法撤销。Apple 建议谨慎使用，因为评分数量很少的产品页可能会劝退用户。
提交更新前的检查清单
- 版本号更高了，构建号也递增了。
- 构建版本已在 TestFlight 中测试过，包括小屏 iPhone，如果应用支持 iPad 也要在 iPad 上测。
- 每种语言的新内容说明都写好了，重大变化已列出。
- 如果界面变了，截图展示的是当前界面。
- 给审核员的备注写清了改了什么、在哪里能找到。
- 发布方式已选好：如果要卡日期就选手动。
- 如果版本涉及付费或首次启动，已勾选分阶段发布。
- 你清楚万一要修复，是可以远程推送，还是需要新的构建版本。
每次更新都顺利过审
每次更新都要重新过 App Review，一次被拒就会卡住你的修复。Review Kit 收录了我的提交前检查清单、我被拒后修复的案例，以及两个 Claude Code skill：它们会检查你的项目和产品页，并在 Apple 拒审时帮你准备回复。完整流程见在 App Store 上发布应用页面。
如果你正在准备第一次上架，来做免费诊断：它会帮你理顺步骤，并把我的 Apple 防拒审检查清单发给你。
常见问题
App Store 分阶段发布要持续多久？
七天：第一天推给 1% 开启自动更新的用户，然后是 2%、5%、10%、20%、50%，第七天达到 100%。你可以暂停，累计最多 30 天，也可以随时用 Release to All Users 结束。
iOS 应用更新需要重新经过 Apple 审核吗？
需要。每个新版本连同它的构建版本和元数据，都要经过 App Review。推广文本和发布设置则不用重新提交就能修改。
App Store 上的应用可以回退到旧版本吗？
不可以。你需要新建一个带修复的版本，然后提交审核。正因为如此，分阶段发布和它的暂停功能才有用。
分阶段发布期间，新用户会拿到更新吗？
会，只要他们是从 App Store 下载应用。分阶段发布只控制自动更新：任何人都可以随时下载新版本。
Apple 审核通过后还能开启分阶段发布吗？
可以，只要版本还处于 Pending Developer Release 状态，也就是选了手动发布、还没上线。版本一旦发布，这个版本就来不及了。
更新的版本说明应该写什么？
清楚列出新功能和重大变化：这是第 2.3.12 条的要求。如果只是普通的 bug、安全或性能修复，写一句概括性的话就够了。该字段最多 4,000 个字符，可以为每种语言分别翻译。
