Devoria
iOS App 更新上架：7 天分階段發布教學
作者：Mehdi Azizi
發布於 ，10 分鐘
發布 iOS 更新：建立新版本、新建置版本、撰寫新功能說明，再選擇手動、自動或 7 天分階段發布。
要發布 iOS 更新，你要在 App Store Connect 建立一個版本號更高的新版本。接著附上新的建置版本（build），撰寫「新功能」說明，再送交 App Review。每個新版本都要重新經過 Apple 審查，就算只是小修正也一樣。 送出前，你要先選好通過審查後怎麼發布：手動、立即發布、不早於某個日期，或用 7 天分階段發布。
分階段發布只影響自動更新：第一天 1% 的這類使用者，第七天全部。你可以暫停，總計最多 30 天，也可以一次全部發布。本指南依據 Apple 的說明頁面，於 2026 年 11 月 3 日重新核對。
我用 Expo 和 EAS 發布我的 iOS app 更新，包括 Solys、TradaZen 和 Nolera。下面提到的案例都來自這些發布。
發布 iOS 更新：依序的步驟
App Store Connect 關於新版本的說明給出這個流程：
- 在 Apps 中選擇你的 app，然後點平台旁邊的 + 按鈕。
- 輸入比上一版更高的版本號，然後點 Create。
- 檢查中繼資料：線上版本的資料會自動複製過來。
- 上傳新的建置版本，建置號碼要遞增。
- 在 TestFlight 測試這個建置版本，把它加到版本中，再送交 App Review。
開始前有兩個條件。線上版本必須是 Ready for Distribution 狀態。而且你需要以下其中一個角色：Account Holder、Admin、App Manager 或 Marketing。
沒有回滾這回事。 Apple 在同一頁寫得很清楚：如果某個版本出問題，你無法退回上一版。你必須建立並送審一個新版本。
版本號與建置號碼
版本號是使用者在你的商品頁面上看到的號碼。建置號碼用來識別每一次上傳。版本號加建置號碼的組合必須是唯一的：相關規則與錯誤請看版本號與建置號碼。
我的習慣（不是 Apple 的規定）：修正問題時最後一碼加一，從 1.4.0 到 1.4.1。新增功能時中間那碼加一，從 1.4.1 到 1.5.0。建置號碼則只會往上加，跨版本也一樣。用 Expo 的話，版本號寫在 app.json，EAS 可以在每次正式版編譯時自動遞增建置號碼。設定方式請看用 EAS 發布 Expo app。
「新功能」說明：Apple 的要求
版本資訊頁面描述了 What's New in This Version 欄位：
- 最多 4,000 個字元。
- 第一個版本沒有這個欄位，之後每個版本都必填。
- 可以翻譯成商品頁面的每一種語言。
App Review Guidelines 第 2.3.12 條多加了一項要求：清楚描述新功能與產品變更。單純的錯誤、安全性或效能修正，用概括的說法就夠了。重要的變更必須列出來。 所以當某個版本改了你的訂閱或主畫面，只寫「錯誤修正與改進」是不夠的。
Apple 在評分與評論的專頁也建議，在說明中提到使用者曾在評論裡回報、現在已修正的問題。
以下三個範本可依需求調整，每種版本一個。
修正版本：
修正與穩定性。
- [功能]：[原本無法正常運作的地方] 已修正。
- [畫面] 載入更快了。
感謝回報問題的每一位。
新功能版本：
新功能：[功能，用幾個字說明]。
[你現在可以做什麼，一句話。]
在哪裡：[分頁] > [按鈕]。
這個版本還有：
- [看得到的改進]。
- 錯誤修正。
流程變更版本：
[畫面或流程] 有所改變。
- 對你的影響：[具體效果]。
- 保留的部分：[資料、設定、購買項目]。
有問題嗎？[設定] > [說明]。
修正範本的最後一行，只有在真的有人回報問題時才寫。絕對不要寫建置版本裡沒有的新功能：第 2.3 條要求中繼資料必須忠於 app。
手動、自動或指定日期發布
發布選項的說明提供三種：
| 選項 | 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 下載新版本。所以安裝你 app 的人，或在你的商品頁面點「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 天結束時，該 app 的 Admin 和 App Manager 會收到通知。
暫停、繼續與全部發布
- 暫停：總計最多 30 天，次數不限。暫停 10 天後，之後還剩 20 天可用。
- 繼續：分階段發布會從你暫停的那一天接著進行。
- 全部發布：版本右上角的 Release to All Users 按鈕，會把更新推送給所有開啟自動更新的裝置。
- 下架：會永久停止分階段發布，包括你的開發者計畫會員資格到期的情況。如果 app 重新上架，該版本會一次對所有人開放。
可編輯屬性表指出，全部發布之後，就沒有任何東西可以調整了。
Nolera 1.0.2 沒有用分階段發布。以下是我在那一週會怎麼用它：
| 你看到的情況 | 你要做的 | 結果 |
|---|---|---|
| 當機或令人擔心的評論 | 暫停 | 自動更新停止 |
| 修正版準備好了 | 新版本 | 重新送審，有自己的分階段發布 |
| 3 到 4 天後沒有異常 | Release to All Users | 所有人都會收到 |
| 你在等 Apple 的回覆 | 暫停，總計 30 天 | 從你停下的那天繼續 |
暫停期間，手動下載照常進行。只要版本涉及付款或首次啟動，就勾選分階段發布：那是缺陷代價最高的地方，而且你無法退回。
修正很緊急時：加速審查
Apple 允許申請加速審查。它只保留給真正的緊急情況：需要修正的嚴重錯誤，或配合某個活動的發布。
- 先送審你的版本。在給審查人員的 Notes 欄位描述錯誤。
- 填寫加速審查申請表，再選擇你的 app 和平台。
- Apple 會視人力加速審查。不保證一定會。
如果是配合活動，請在說明中寫上活動日期以及你和活動的關係。一般的審查時間請看 App Store 審查要多久。
哪些要重新審查，哪些不用
| 變更 | 需要做的 |
|---|---|
| 原生程式碼、權限、SDK 版本 | 新建置版本、新版本、完整審查 |
| 截圖、描述、關鍵字、新功能說明 | 一個新版本，一起審查 |
| 推廣文字 | 不用：不必重新送審就能修改 |
| 暫停、繼續、全部發布 | 不用：這些是發布設定 |
| iOS 27 商品頁面頁首 | 單獨在 Asset Library，或隨版本送出 |
| JavaScript 修正（使用 Expo） | 可以用遠端更新 |
根據版本資訊頁面，推廣文字不必重新送審就能修改。用 Expo 的話，遠端更新可以修改 JavaScript、文字和圖片，不必經過 App Store。Expo 文件設下兩個限制：原生程式碼、權限和 SDK 版本需要新的二進位檔，而且更新必須遵守 App Store 的規則。
我的案例：審查人員從沒看到的遠端修正
2026 年 9 月，Nolera 有個建置版本在等審查。我修好了掃描畫面的一個缺陷，並在等待期間用遠端更新發布了這個修正。結果這個建置版本還是被拒了，理由就是那個已經修好的缺陷。
原因寫在 expo-updates 文件裡：預設情況下，app 在啟動時下載更新，在下一次啟動時才套用。審查人員安裝 app、啟動一次，測試的是建置版本內建的程式碼。你的新使用者也一樣：他們的第一次使用跑的是建置版本的程式碼。
從那之後，首頁、付費牆或主要功能的任何變更，我都放進新的建置版本。遠端更新只服務已經裝了 app 的人。
用新版本重設評分
每個新版本都有 Reset rating when this version is released 選項。根據 Apple 關於重設評分的說明，它適用所有國家，會保留文字評論，而且發布後無法取消。Apple 建議謹慎使用，因為評分很少的商品頁面可能會讓人卻步。
送審更新前的檢查清單
- 版本號更高，建置號碼已遞增。
- 建置版本已在 TestFlight 測試過，包括小尺寸 iPhone，如果你的 app 支援 iPad 也要測。
- 每種語言的新功能說明都寫好了，重要變更都有列出。
- 如果介面有改，截圖要呈現目前的介面。
- 給審查人員的說明寫清楚改了什麼、在哪裡找到。
- 發布選項已選好：如果要配合某個日期就選手動。
- 如果版本涉及付款或首次啟動，已勾選分階段發布。
- 你知道之後可能的修正能否用遠端更新，還是需要新的建置版本。
每次更新都順利通過審查
每次更新都要重新經過 App Review，一次被拒就會卡住你的修正。Review Kit 收錄了我的送審前檢查清單、我被拒後修正的案例，以及兩個 Claude Code skill：它們會檢查你的專案和商品頁面，並在 Apple 拒絕時幫你準備回覆。完整流程請看在 App Store 上架 app 這一頁。
如果你正在準備第一次上架，來做免費診斷：它會幫你把步驟排好順序，並寄給你我的 Apple 防拒檢查清單。
常見問題
App Store 分階段發布要多久？
七天：第一天 1% 開啟自動更新的使用者，接著 2%、5%、10%、20%、50%，第七天 100%。你可以暫停，總計最多 30 天，也可以隨時用 Release to All Users 結束。
iOS app 更新需要重新經過 Apple 審查嗎？
需要。每個新版本，連同它的建置版本和中繼資料，都要經過 App Review。推廣文字和發布設定則不必重新送審就能修改。
App Store 上的 app 可以退回舊版本嗎？
不行。你必須建立一個含有修正的新版本，再送審。這就是分階段發布和它的暫停功能有用的原因。
分階段發布期間，新使用者會拿到更新嗎？
會，只要他們是從 App Store 下載 app。分階段發布只控制自動更新：任何人隨時都可以下載新版本。
Apple 核准後還能啟用分階段發布嗎？
可以，只要版本還在 Pending Developer Release 狀態，也就是選了手動發布且尚未發布。版本一旦發布，這個版本就來不及了。
更新的版本說明該寫什麼？
清楚列出新功能和重要變更：這是第 2.3.12 條的規定。單純的錯誤、安全性或效能修正，用概括的說法就夠了。這個欄位最多 4,000 個字元，可以翻譯成每一種語言。
