模板包含什么
发一个 App 不是把代码发到自己的服务器上。什么时候能上线是别人说了算，计划必须把这一点画出来。模板把你能控制的工作和你控制不了的等待分开：
- 版本收敛 — 功能冻结、崩溃与无响应（ANR）问题清理、性能与内存优化、无障碍与机型覆盖测试，以及候选版本打包。里程碑：候选版本就绪。
- 内测 — TestFlight 与 Google Play 内部测试轨道上传、内部测试、外部测试用户招募、外部测试轮次与反馈处理。里程碑：内测出口标准达成。
- 商店素材 — 关键词与分类调研、应用名称与描述、截图与预览视频、图标与图形素材、隐私数据披露和分级问卷。
- 提审与审核 — 提审前合规自查、双商店提交、审核等待，以及为一次被拒和重新提交留出的真实缓冲。里程碑：审核通过待发布。
- 灰度放量 — 按 1%、10%、50% 分步放量，每一步先看崩溃率再决定是否扩大，直到全量。里程碑：全量上线。
- 首日修复与监测 — 崩溃与无响应监测、预留的修复窗口、商店评价回复和第一周的留存数据复盘。
要为"被拒"留预算。首次提审被拒的概率高到足以让一份没有重提缓冲的计划变成一次抛硬币——而且重新提交时排队从零开始。把审核等待和被拒缓冲分成两根横条放到图上，然后把对外宣布的日期定在第二根之后，而不是第一根之后。
如何调整
- 定下提审日期然后往后推，不要往前倒推——审核时长不是你能压缩的。
- 如果 iOS 和 Android 版本节奏不同，把提审和审核的行按商店拆开；两边的审核时长不一样。
- 如果这是首次提审、订阅制应用，或涉及账号注销、健康数据、用户生成内容，把被拒缓冲拉长。
- 按你的平台调整放量比例；Google Play 的分阶段发布和 App Store 的分阶段发布步长并不一致。
- 把首日修复窗口留在图上并写上人名——没有人值守的修复窗口只是一周空白。
- 把候选版本、内测出口、审核通过和全量上线标成里程碑；大家问的就是这四个日期。
排期建议
- 商店素材要早于安装包定稿。截图、描述和隐私披露都可以独立准备和评审，绝不应该成为卡住提审那天的东西。
- 不要把发布日期挂在还没拿到的审核结果上。让市场动作依赖"审核通过"这个里程碑，被拒时活动会自动顺延，而不是让你当众下不来台。
- 每一步放量都要看崩溃率。灰度的意义就在于"能在两步之间停下来"；如果没人排班去看数据，分阶段等于没做。
- 修复窗口要在发布前就预留。能做首日修复的那批人，正是你不预留就会在发布当天派去做下个迭代的那批人。
- 外部测试用户要提前好几周招。凑够有意义数量的真机测试用户，比大多数团队预计的慢，而人数太少的内测什么也测不出来。
- 在候选版本时设定基准。之前的都是估算；之后的进度基本上是别人的排队队列，应当按偏差来跟踪。
相关模板
本模板为中文。尚未翻译的相关页面会以英文打开。
常见问题
应用商店审核要多久？
App Store 大多数审核在一两天内完成，Google Play 往往更快，但首次提审或敏感类目都可能明显更久。模板留了十天再加一段被拒缓冲，这样一次运气不好的审核不会毁掉整个计划。
App 上线发布计划应该包含什么？
版本收敛、内测、商店素材、提审与审核、灰度放量和首日修复窗口。这六项模板里都已预置，并且把审核等待建成了一条依赖关系，而不是一句假设。
它和产品发布计划有什么区别？
这一份是"应用商店形状"的：围绕提审、审核和灰度放量。定价、定位和市场推广这类更大的上市工作，请同时使用产品发布模板。
应该灰度放量还是直接全量？
没有特别理由就灰度。分阶段发布能让你在崩溃率下滑时停在 1%，这比全量之后紧急回滚便宜得多。
这份 App 发布模板免费吗？
免费。可免费下载 Excel、PowerPoint 和 CSV，也可免费在线编辑，无需注册，没有水印。