App Store 加急審查：如何向 Apple 申請

加急審查確實存在，但 Apple 只保留給特殊情況，並舉了兩個例子：修正已上架版本的嚴重 bug，或是配合一個與你的 app 直接相關的活動推出新版本。 你要先提交版本，在審查備註（Notes）裡說明急迫性，再送出申請表單。Apple 會逐一審視每份申請，並依人力狀況決定是否加速：這從來都不是保證。

我的 app，Solys、TradaZen 和 Nolera，都是用 Expo 做的。當 bug 出在 JavaScript 程式碼時，修正會透過遠端更新推送，不經過 App Review。所以加急審查對我來說只用在原生 build 上，這也是你在申請前該先問自己的第一個問題。本指南依據 Apple 關於加急審查的說明頁面撰寫，於 2026 年 11 月 6 日重新確認。

Apple 列出的情況，以及不會過的情況

Apple 說的是「特殊情況」，並要求只在真正緊急時才提出申請。它的 App Review 頁面舉了兩個例子，以及各自需要提供的資料。表格中被拒的三列是我對這些頁面的解讀，不是 Apple 的清單。

理由	Apple 的立場	需要提供或理解的事
線上版本有嚴重 bug	列為範例	重現步驟、目前版本
配合活動推出	列為範例	活動名稱、日期、你的 app 與活動的關聯
首次上架進度落後	我認為不行	在 Apple 眼中沒有任何急迫性
行銷日期但沒有活動	我認為不行	行銷活動不等於與 app 相關的活動
等待時間比平常久	我認為不行	正常的審查時間不算緊急

Apple 沒有定義這個詞。實務上，嚴重 bug 指的是在線上版本中，真實使用者遇到 app 閃退、核心功能無法使用，或無法付款。 某個畫面裡的錯字不算。另外，如果活動快到了而你的 app 還在審查中，Apple 也說明你可以因此申請加急。

三步驟申請流程

1. 在 App Store Connect 提交版本。 只有已經送出的提交才能加急。如果有功能需要登入，請在 App Review Information 區塊填寫示範帳號。
2. 提交時填寫 Notes 欄位。 如果是嚴重 bug，描述修正了什麼 bug，以及如何在目前版本重現。如果是活動，寫出活動名稱、日期，以及你的 app 和它的關聯。
3. 送出 Request an Expedited App Review 表單，登入開發者帳號後可從 Apple 的說明頁面進入。在表單中選擇相關的 app 和平台，然後送出。

Apple 審視申請後會回覆你，接著你就在 App Store Connect 追蹤這份提交。如果申請通過，版本會比原本排隊的順序更早進入 In Review。如果被拒，審查會照常進行：你沒有任何損失。

App Store Connect 裡的 Reply to App Review 按鈕不是用來申請加急審查的。App Review 聯絡頁面說明它只用於溝通進行中的提交；加急申請和申訴各有自己的表單。

怎麼寫：兩個範本

App Review 讀的是英文。以下是我隨時準備好的兩段文字，可以改寫後放進 Notes，如果表單有自由填寫欄位也可以用。它們只有五行，因為審查人員必須不用打開 app 就能理解有多急。

線上版本有嚴重 bug：

Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.

配合活動推出：

This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.

這兩段只是範例，不是我真的送出過的申請。寫你自己的版本時有兩個原則。可驗證的事實：版本、系統、步驟、日期、與活動的關聯。只談急迫性：如果你的 build 也包含新功能，用一句話帶過就好，不要替它辯護。

申請之前，先確認你真的需要

Apple 要求只在真正緊急時使用。送出表單前，先問三個問題，再避開一個陷阱。

修正能不能不經審查就推出？ 用 Expo 的話，遠端更新可以直接替換已安裝 app 的 JavaScript 程式碼，不需要新的 build。我修 bug 就是走這條路。但它不涵蓋原生程式碼、權限和原生相依套件：這些都需要 build 和審查。而且內容必須維持在 Apple 已核准的範圍內，正如 EAS Update 介紹所提醒的：遠端更新不能改變 app 的用途。iOS 更新分階段發布這篇指南詳細說明了哪些內容該走哪條路。

等待時間真的不正常嗎？ Apple 表示通常至少 50% 的提交會在 24 小時內審查完畢，90% 在 48 小時內。如果你的版本已經等待審查一天，那還在 App Store 審核時間的正常範圍內。提交狀態追蹤頁面也提到哪些因素會拉長審查：沒有紀錄的第一個 app、需要核實的文件、受規範的主題。

提交內容完整嗎？ 對不完整的提交申請加急，什麼也加速不了。Apple 提醒，不完整的提交會延誤審查或直接失敗。示範帳號、備註、文件：送出表單前全部都要準備好。

最重要的是，不要撤回版本再重新送。 撤回的版本會離開佇列，從頭排起。如果 Apple 在審查中問你問題，請在 App Store Connect 回覆，而不是重新提交，詳見在 Resolution Center 回覆 App Review 這篇指南。

如果 Apple 拒絕加急

你會保留原本的排隊位置：加急被拒不會影響進行中的審查。為了不再碰到這種狀況：

• 排定發布時間。 針對活動，Apple 建議在 App Store Connect 選擇排程發布：版本提前審查，並在你指定的日期上架。版本發布選項在版本頁面的 App Store Version Release 區塊設定。
• 提早提交。 在活動前一週就準備好的版本，有足夠時間走正常審查，甚至被拒後修正也來得及。
• 為 JavaScript 保留一條不經審查的管道。 用 Expo 的話，這正是讓嚴重 bug 變成幾分鐘就能修好的關鍵。

我給審查人員的備註範本、送出前的檢查清單，以及最常見被拒情況的回覆方式，都整理在 Review Kit 裡。如果你想在送出前知道提交還缺什麼，免費診斷會告訴你，並寄給你我的防止 Apple 退件檢查清單。完整的上架步驟請看在 App Store 上架 app。

常見問題

App Store 加急審查要多久？

Apple 沒有給出任何時間。它表示會審視每份申請，並依人力狀況和當下的需求量加速審查。申請通過後，版本會提前進入 In Review，但沒有保證具體時間。

第一個 app 可以申請加急審查嗎？

沒有規定禁止，但 Apple 只把加急保留給真正的緊急情況，並舉了兩個例子：已上架版本的嚴重 bug，或配合特定日期活動推出。首次上架比你的計畫晚，我認為兩者都不符合。

加急審查可以申請幾次？

Apple 沒有公布次數。它只要求在真正緊急時才申請。我認為每一次沒有正當理由的申請，都會讓下一次的可信度降低：把它留給真正影響使用者的 bug。

申請加急前需要先撤回提交嗎？

不用，剛好相反。只有已經送出的提交才能加急，而撤回的版本會失去排隊位置。先提交、填寫 Notes，再送出表單。

加急審查的表單在哪裡？

在 Apple 開發者網站，登入帳號後：加急審查的說明頁面上有 Request an Expedited App Review 連結可以進入。在表單中選擇相關的 app 和平台。

加急審查能保證 app 通過嗎？

不能。它只改變排隊的位置。版本跟其他任何版本一樣必須符合 App Review Guidelines，仍然可能被拒。

可以不經 App Review 修 bug 嗎？

用 Expo 或 React Native 的話，遠端更新可以替換 JavaScript 程式碼，不需要新的 build 也不用審查。原生程式碼、權限和原生相依套件，仍然需要提交 build 給 Apple。