三個判斷條件決定內購能否單獨送審：商品是否屬於該類型的首個項目、同類型是否已有獲批准商品，以及 App 是否已有獲批准版本。 因此，2026 年進行 App Store Connect 內購提交 時，首次商品仍須與新的 App 版本一起送審；只有在同類型商品已有批准項目，且 App 已存在獲批准版本等條件成立時，後續商品通常才可透過 Add for Review 單獨提交。Apple 官方內購提交說明 已確認這項分界。

這篇文章適合首次加入消耗型、非消耗型內購或訂閱的獨立開發者，也適合已有付費商品、準備增加新價格方案或新訂閱的小團隊。若發布環境放在遠端 Mac，本文也會把簽名、Build 上傳、斷線恢復和審核狀態納入同一條驗收流程。

先在送審前判斷：這個商品屬於哪一種首次提交

內購商品能否脫離 App 版本，不能只看商品頁目前顯示的狀態，也不能因為 Sandbox 購買成功就直接判定符合審核條件。判斷時應先以「商品類型」為單位，而不是以整個 App 是否曾經送審為單位。

  • 消耗型內購：該 App 的第一個消耗型商品，須和新的 App 版本共同送審。另一個非消耗型商品曾獲批准，不能取代消耗型商品的首次提交條件。
  • 非消耗型內購：第一個非消耗型商品同樣需要綁定新的 App 版本；已有其他類型的付費商品，不代表這個類型已經完成首次審核。
  • 自動續期訂閱：首次提交時，除了訂閱商品本身，還要處理 Subscription Group 與 App 版本的關聯，不能只建立一個訂閱價格就期待它獨立送審。
  • 非續期訂閱：第一個非續期訂閱也要按照該類型的首次商品規則處理，不能把自動續期訂閱的審核紀錄視為所有訂閱類型都已獲批准。

第一个內購項目必須和 App 新版本一起提交嗎？
若「第一個」是指該內購類型的首個商品，答案是需要；若只是同一類型中新增的後續商品，且已有同類型商品獲批准、App 也已有獲批准版本，則可依資格使用 Add for Review 單獨提交。Apple 的App 提交要求與內購說明應以目前 App Store Connect 顯示的資格為準。

接著補齊商品資料：測試通過不等於可以送審

建立提交草稿前，應逐項查看商品詳情頁。最容易被忽略的不是 Product ID，而是審核人員實際需要看到的說明、截圖與使用入口。

建議先確認以下內容：

  • 商品名稱、描述與本地化文字已完成，且沒有把測試用語、內部版本代號或未脫敏資料放進審核欄位。
  • 價格、可銷售地區與商品狀態已檢查；如果商品尚未準備銷售，不要把「可測試」誤解為「可正式購買」。
  • 審核截圖能展示商品在 App 內的入口、購買前資訊與完成後的解鎖結果。
  • Review Notes 清楚寫出測試帳號、進入購買畫面的步驟，以及審核人員如何重現商品功能。
  • 訂閱已正確放入 Subscription Group，並且至少有一個訂閱商品與該群組關聯。

Apple 對內購資料與審核資訊的要求，與 StoreKit 實際測試是否成功是兩件事。測試購買成功只能說明目前環境能走通某一段交易流程，不能證明本地化內容、審核截圖、Review Notes 或 App 版本關係已經完整。

新增訂閱為什麼無法單獨送審？
最常見原因是它仍是該訂閱類型的首個商品，或 App 尚未有獲批准版本；另一種情況是訂閱群組、商品關聯或審核資料尚未完整。先回到「同類型是否已有獲批准商品」這個條件，不要只檢查訂閱的 Sandbox 交易結果。

再建立提交草稿：從商品區域加入 Add for Review

App Store Connect 的 Add for Review 在哪裡？
入口不在 Xcode，也不在單純的測試購買畫面，而是在 App Store Connect 的內購或訂閱管理區域。從商品詳情頁選擇加入審核內容，既可以放入現有草稿，也可以建立新的提交草稿；實際可見選項會受商品資格與目前 App 狀態影響。Apple 的提交審核總覽可用來對照目前介面與提交對象。

首次商品的草稿通常應同時包含：

  • 新的 App 版本；
  • 對應的 Build；
  • 對應內購商品，或首次訂閱所需的 Subscription Group；
  • 需要一併審核的訂閱商品；
  • 能讓審核人員實際找到購買入口的 Review Notes。

後續商品則先確認是否已取得獨立提交資格，再從 In-App Purchases 或 Subscriptions 區域加入草稿。不要只看到商品被加入清單，就認為它已經送出；在按下 Submit for Review 前，仍要查看提交草稿中的物件、版本與目前狀態。

提交內容核對清單

  • [ ] 已確認商品屬於消耗型、非消耗型、自動續期訂閱或非續期訂閱中的哪一類。
  • [ ] 已判斷這是否為該類型的第一個商品。
  • [ ] 若是首次商品，已把 App 版本與商品放入同一個提交草稿。
  • [ ] 若要單獨提交，已確認同類型商品已有獲批准項目，且 App 存在獲批准版本。
  • [ ] 商品本地化資料、價格、銷售範圍、截圖與 Review Notes 均已完成。
  • [ ] 訂閱商品已關聯至正確的 Subscription Group。
  • [ ] 已從商品管理區域使用 Add for Review，而不是只完成 Sandbox 測試。
  • [ ] 提交草稿內的 App 版本、商品、訂閱群組與 Build 都是本次要審核的對象。
  • [ ] App 內已有可被審核人員找到的購買入口，並能說明測試路徑。
  • [ ] App 名稱、Product ID、Bundle ID、Team ID、帳號、截圖與日誌均已脫敏。

需要新版本時：完成 Xcode 26 Build 與遠端 Mac 驗收

如果首次商品必須和新版本一起送審，商品頁的操作只是其中一段，還需要先上傳可供正式審核的 Build，再到 App 版本中選取正確的 Build。Build 處理完成不代表內購已經提交，也不代表審核已完成；Apple 對Build 上傳狀態與 App 提交狀態有分開定義。

截至 2026 年 8 月 29 日，應把 Xcode 26 視為正式分發鏈路的驗收基準。Xcode 27 beta 6 目前可用於 TestFlight 內部與外部測試，但不能因為測試上傳成功，就宣稱該 Beta Build 已獲准用於正式 App Store 客戶分發；版本支援狀況應以App Store Connect 發布說明及 Apple 的目前文件為準。

遠端 Mac 發布時，還要額外驗證下列實際問題：

  1. Apple Developer 帳號、憑證、Provisioning Profile 與 Bundle ID 是否屬於正確團隊。
  2. Xcode 26 是否能在該環境完成 Archive，而不是只完成 Debug Run。
  3. 上傳憑據是否具有必要權限，並且沒有把發布金鑰直接散落在日常開發帳號中。
  4. Build 上傳後，能否在 App Store Connect 看到處理完成，而不是停留在處理中或失敗狀態。
  5. 斷線後重新連入遠端 Mac，是否能取得原有 Archive、上傳紀錄與錯誤日誌，避免重複執行可能已成功的上傳。
  6. 正確 Build 是否已在 App 版本中被選取，且商品入口在該 Build 內確實可使用。

若團隊目前沒有穩定的常駐 Mac，可以先參考 RUVCLOUD 的遠端 Mac 方案，把「能否上傳」與「能否在斷線後恢復發布」分開驗收，而不是只以一次成功登入作為發布環境合格標準。

送出後按物件追蹤：不要只看 Build 已處理

提交後至少要分開追蹤 App 版本、內購商品、Subscription Group 與審核提交本身。這些物件可能處於不同狀態，因此「Build 已處理」只能說明上傳處理完成，不能說明商品已獲批准或 App 已可正式銷售。需要核對時，可參考 Apple 的App 與提交狀態定義。

內購被拒後要不要重新上傳 App Build？
不一定。若拒絕原因只涉及商品名稱、描述、本地化內容、截圖、Review Notes 或商品設定，通常應先在對應物件的 Messages 中修正，再使用 Update Review 和 Resubmit；未發生變更的二進位檔不應為了形式而重新上傳。只有拒絕原因明確指向 App 功能、購買入口、版本內容或需要修正的程式碼時，才應評估重新建置並上傳新的 Build。

處理多個物件共同提交的拒絕時，可以按以下順序定位阻塞點：

  • 先看 Messages 指向的是 App 版本、內購商品、訂閱群組還是提交整體。
  • 再確認被拒物件是否已完成修改，而不是只修改了另一個商品。
  • 若商品資料已更新但 App 版本仍被拒，檢查審核人員實際使用的 Build 與入口。
  • 重新提交前，確認草稿中沒有意外加入尚未完成的其他商品。
  • 最後查看 Resubmit 後各物件的新狀態，避免把舊的拒絕狀態當成最新結果。

帳號角色也可能造成按鈕不可見或無法送審。發布前應依照Apple 帳號角色與權限說明確認操作者具備相應權限，並把提交權限與日常開發權限分開管理。

最後固化流程：讓下一次內購發布可重複

一次成功提交之後，團隊仍應建立商品類型登記表，至少記錄商品類型、是否已有同類型首個獲批准商品、關聯 App 版本、Subscription Group、審核截圖位置與最近一次 Review Notes。這份紀錄能避免新成員把「已有其他類型商品」誤當成「本類型已完成首次提交」。

發布流程也應拆成三個權責區段：

  • 建置區段：由開發者負責版本號、Archive、簽名與 Build 上傳。
  • 提交前檢查區段：由發布負責人核對商品資料、購買入口、審核說明與草稿物件。
  • 憑據與恢復區段：由具備適當權限的人管理發布金鑰、遠端 Mac 存取與斷線後恢復。

下一次新增後續商品時，可把它當作真實演練：先不更動沒有必要變更的 App Build，確認商品能否獨立加入 Add for Review，再記錄被拒、修改、Update Review 和 Resubmit 的完整路徑。這比只在 Sandbox 反覆購買更能證明團隊已具備獨立提交、失敗定位與遠端恢復能力。

對於長期使用 Windows 或 Linux 的開發者，臨時借用本機 Mac 可以完成某次操作，但常見限制包括 Xcode 工具鏈不一致、簽名憑據需要重新整理、Build 檔案散落在不同裝置，以及斷線後難以恢復未完成的上傳。若團隊每次發布都要重新尋找可用 Mac，審核時間線就會被環境問題打斷。此時可查看 RUVCLOUD 的租用選擇，先以一次內購發版驗收 Xcode、簽名、上傳與恢復，再決定是否需要較長租期；若工作是長期高負載編譯、必須接觸實體 USB 裝置，或需要永久控制硬體，購買並自主管理 Mac 仍可能更合適。

因此，App Store Connect 內購提交的關鍵不是「商品是否測試成功」，而是能否正確判斷首次或後續商品，並在同一條時間線上完成商品資料、App 版本、Build、Add for Review、狀態追蹤與重提。若目前缺少可穩定執行 Xcode 26 的常駐 Mac，RUVCLOUD 的遠端 Mac 可作為下一次真實內購發布的測試環境；先驗收完整流程，再依團隊的發布頻率選擇短期或較長期租用方式。