替 Google Play 審核空出一週的上線時程表

從上線日倒著排，會空出一格

先訂下上線日再往回倒著排的時程表，多半只裝得下開發週期，因為那是問開發方就能當場拿到的數字。可是 App 做完了不等於就開得了。Google Play Console 說明寫著，App 的變更從送出到發布需要幾小時到最多七天，少數情況下還會更久。同一份文件建議在送出和公開之間留至少一週。

2026 年八月到九月，落在那個「少數情況」裡的等待在開發者之間接連出現。如果把有固定上線日的 App 發包出去做，這段等待要跟開發週期分開算，單獨佔一格。催開發方也不會讓它變短。

最多七天這個數字帶著條件

Google 並不保證審核時長。發布應用程式的說明裡寫著，為了保護使用者，部分開發者帳號的 App 會被看得更仔細。這時審核最多要七天，少數情況下更久。已經上架的 App 更新也一樣。預設的標準發布會盡快處理更新，但一部分 App 會轉進擴充審查，花掉同樣長的時間。

說明把用新開發者帳號送出的 App 列為可能進入擴充審查的例子。第一次出 App 的業主，把這個數字當成起步值而不是上限，判斷會穩一些。

八月十七日和九月十六日留下的紀錄

2026 年 8 月 17 日，Google Play 商務社群的官方 X 帳號在回覆一位 App 開發者的詢問時表示，目前審核比平常慢，少數情況下會超過七天。那則回覆沒有說是什麼塞住了，也沒有說什麼時候恢復。

一個月後的 9 月 16 日，做 XMPP 通訊 App Conversations 的丹尼爾·古爾奇貼出了主控台截圖。9 月 9 日送出的更新，過了一週還排在審核佇列裡。古爾奇寫道，這個 App 在 Play 上已經超過十二年，一個月才更新一次。他也寫到自己理解審核佇列被 AI 量產的低品質 App 塞住的處境。不過這不是 Google 給出的原因。同一天 Hacker News 上也出現了討論這則貼文的話題。

跑了很多年的 App 同樣沒能繞開排隊。一次更新要一週，那麼上線後馬上發現的錯誤，改好的版本也要一週後才到使用者手上。

新開的個人帳號，前面先加十四天測試

2023 年 11 月 13 日之後建立的個人開發者帳號，App 公開前必須先做封閉測試。申請正式版存取權時，前 14 天內要有 12 名以上測試者持續參與測試。送出申請之後，Google 通常在七天內審完，也可能更久。如果出現測試者不足 12 人這類情況，回來的答覆可能是要你繼續測。

按天數算是這樣。測試 14 天加上存取權審查 7 天，是三週。之後上傳的正式版本，還要再走一遍前面說的那道審核。以業主名義新開一個個人帳號來上架，這些條件就原樣落在你身上。帳號由誰建立、由誰持有，屬於開工之前就要定下的事項。

把核准和公開拆開的管理式發布

打開管理式發布之後，更新照常送審，但通過之後什麼時候公開由開發者自己定。說明裡提到，這個功能適合配合廣告投放或發表活動的日期，在特定時刻推出更新。說明也提到，它對處在擴充審查裡的 App 同樣有用。上線日已經訂死的話，就可以把審核提前過掉，當天只按一下按鈕。

蘋果一天，Google 一週

蘋果開發者網站寫著，平均 90% 的送審會在 24 小時內完成審核。要在兩家商店同一天上線，送出日就得遷就審核更慢的 Google 那邊。Google 在 8 月 17 日承認的延遲，到 9 月 16 日又以一週的等待出現了一次。

我們先把送審日訂下來

Weple 的 App 開發，第一次溝通問的是日期，而不是有幾個畫面。開發者帳號掛誰的名、封閉測試的人從哪裡湊、要不要打開管理式發布，這些都是開工之後再改會很麻煩的決定。所以在寫範圍文件之前，先把審核那一格和帳號那一格擺上日曆，再在上面排畫面清單。工作按什麼單位計，寫在價格說明裡。審核被退件之後該怎麼走，另外寫在退件通知裡已經寫了下一步。如果 App 已經在主控台裡了，帳號類型和最後一次更新的日期，這兩行就夠我們先替你把剩下的等待算出來。