给 Google Play 审核留出一周的上线时间表

从上线日倒着排，会空出一格

先定下上线日再往回倒着排的时间表，多半只装得下开发周期，因为那是问开发方就能当场拿到的数字。可是应用做完了并不等于就开得了。Google Play Console 帮助写着，应用的变更从提交到发布需要几小时到最多七天，少数情况下还会更久。同一份文档建议在提交和公开之间留出至少一周。

2026 年八月到九月，落在那个“少数情况”里的等待在开发者之间接连出现。如果把有固定上线日的应用交给外包做，这段等待要和开发周期分开算，单独占一格。催开发方也不会让它变短。

最多七天这个数字带着条件

谷歌并不承诺审核时长。发布应用的帮助里写着，出于保护用户的考虑，部分开发者账号的应用会被更仔细地审。这时审核最多要七天，少数情况下更久。已经上架的应用更新也一样。默认的标准发布会尽快处理更新，但一部分应用会转入扩展审核，花掉同样长的时间。

帮助把用新开发者账号提交的应用列为可能进入扩展审核的例子。第一次出应用的甲方，把这个数字当成起步值而不是上限，判断会稳一些。

八月十七日和九月十六日留下的记录

2026 年 8 月 17 日，Google Play 商务社区的官方 X 账号在回复一位应用开发者的询问时表示，眼下审核比平时慢，少数情况下会超过七天。那条回复里没有说是什么堵住了，也没有说什么时候恢复。

一个月后的 9 月 16 日，做 XMPP 通讯应用 Conversations 的丹尼尔·古尔奇贴出了控制台截图。9 月 9 日提交的更新，过了一周还排在审核队列里。古尔奇写道，这个应用在 Play 上已经超过十二年，一个月才更新一次。他还写道，自己理解审核队列被 AI 批量产出的低质量应用堵住的处境。不过这不是谷歌给出的原因。同一天 Hacker News 上也出现了讨论这条帖子的话题。

跑了很多年的应用同样没能绕开排队。一次更新要一周，那么上线后马上发现的错误，改好的版本也要一周后才到用户手上。

新开的个人账号，前面先加十四天测试

2023 年 11 月 13 日之后创建的个人开发者账号，应用公开前必须先做封闭测试。申请正式版访问权限时，前 14 天内要有 12 名以上测试者持续参与测试。提交申请之后，谷歌通常在七天内审完，也可能更久。如果出现测试者不足 12 人这类情况，回来的答复可能是让你继续测。

按天数算是这样。测试 14 天加上访问权限审核 7 天，是三周。之后上传的正式版本，还要再走一遍前面说的那道审核。以甲方名义新开一个个人账号来上架，这些条件就原样落在你身上。账号由谁创建、由谁持有，属于开工之前就要定下的事项。

把批准和公开拆开的托管发布

打开托管发布之后，更新照常送审，但通过之后什么时候公开由开发者自己定。帮助里说，这个功能适合配合广告投放或发布活动的日期，在特定时刻推出更新。帮助还说，它对处在扩展审核里的应用同样有用。上线日已经定死的话，就可以把审核提前过掉，当天只按一下按钮。

苹果一天，谷歌一周

苹果开发者网站写着，平均 90% 的提交会在 24 小时内完成审核。要在两家商店同一天上线，提交日就得迁就审核更慢的谷歌那边。谷歌在 8 月 17 日承认的延迟，到 9 月 16 日又以一周的等待出现了一次。

我们先把提交日定下来

Weple 的应用开发，第一次沟通问的是日期，而不是有几个界面。开发者账号挂谁的名、封闭测试的人从哪里凑、要不要打开托管发布，这些都是开工之后再改会很麻烦的决定。所以在写范围文档之前，先把审核那一格和账号那一格摆上日历，再在上面排界面清单。工作按什么单位计，写在价格说明里。审核被驳回之后该怎么走，另外写在驳回邮件里已经写了下一步。如果应用已经在控制台里了，账号类型和最后一次更新的日期，这两行就够我们先替你把剩下的等待算出来。