截至 2026 年 10 月 25 日，Apple 列出的適用系統為 iOS 27、iPadOS 27、macOS 27 或 tvOS 27 及更高版本，並要求使用 StoreKit 2；資格與申請條件見 Apple Bundles 與 Suites 官方說明。因此，本週先按「訂閱能否單獨購買」及「權益涵蓋一個還是多個 App」選方向：仍保留單項訂閱、只是增加組合銷售，優先評估 Bundle；多個 App 必須合為一套服務，才評估 Suite。跨開發者合作則看多開發者 Bundle，並把 Apple 申請與後續配置列為上線門檻。
適合只有一個 App、但提供多項訂閱服務的獨立開發者：確認組合銷售是否比只提供單項方案更符合產品設計。
適合維護多個 App 的開發者：核對使用者購買後需要解鎖單一 App，還是跨 App 的整套服務。
適合準備與其他開發者合作的團隊：先釐清參與方的訂閱、權益與責任，再評估多開發者 Bundle。
最後更新於 2026 年 10 月 25 日；系統資格、StoreKit 2 要求及申請流程核實自 Apple Bundles 與 Suites 官方文件、Apple Developer 資訊及 WWDC 2026 說明。
iOS 27 StoreKit Bundles 和 Suites 怎麼選：先看產品邊界
不要因為 SKU 多，就直接選 Bundle；也不要因為 App 多，就直接選 Suite。這兩種方案的判斷重點，是訂閱是否仍能獨立購買，以及你要交付的是單項訂閱的組合，還是跨 App 的整套服務。Apple 說明涵蓋 Bundles、Suites 與多開發者合作，但資格和申請仍須分別核實。
| 產品現況 | 優先評估 | 你要確認的事 |
|---|---|---|
| 單一 App 有多項訂閱，單項仍有獨立價值 | Bundle | 使用者能否繼續單買，組合購買增加了什麼權益 |
| 多個 App 共同構成一套服務 | Suite | 使用者購買後是否需要跨 App 解鎖，權益如何保持一致 |
| 不同開發者希望共同提供訂閱組合 | 多開發者 Bundle | 各方訂閱、權利歸屬、合作責任及 Apple 申請資料 |
| 只想把多個 App 一起展示或銷售 | 先檢查傳統 App Bundle | 不要把 App Bundle 與訂閱 Bundles 當成同一功能 |
傳統 App Bundle 是 App Store Connect 中建立與提交 App 組合的流程，和本文討論的訂閱 Bundles、Suites 不應混為一談。若你只需要組合銷售多個 App，應先對照 Apple 的 App Bundle 建立與提交說明；若要組合的是自動續訂訂閱，則要按訂閱產品及權益關係設計。
單一 App：保留單買，還是改成整套服務
只有一個 iOS App，不代表一定適合 Bundle，也不代表 Suite 一定不適用。先把每個 SKU 的功能、可單獨購買與否、到期後權益，以及同一帳戶下的權益驗證方式列清楚，再判斷組合銷售是否仍保留合理的單項選擇。
- 若每項訂閱仍能獨立滿足一類使用需求，而且你打算保留單項購買，優先評估 Bundle。
- 若多項訂閱實際上只服務同一套產品體驗，且不打算分開銷售，先確認 Suite 是否符合你的產品與 App 結構。
- 若組合後的權益、續訂狀態或退款處理還無法清楚描述，暫緩設定新組合，先整理權益判斷與客服處理規則。
單 App 開發者常忽略的成本，不是新增一個商店選項而已。你還要檢查購買頁如何呈現單項與組合、既有訂閱者如何識別權益，以及 StoreKit 交易結果如何映射到 App 內功能。Apple 的自動續訂訂閱配置說明可用來核對訂閱產品設定；但你的 App 仍需自行驗證實際權益，不應只看購買成功提示。
多個 App：同一開發者與跨開發者的界線
維護多個 App 時，先從使用者購買後的體驗倒推產品結構。若每個 App 仍有獨立訂閱，只是希望提供組合選擇，評估 Bundle；若使用者需要把多個 App 當成一項整合服務，才進一步評估 Suite。App 數量只是盤點條件，不是選擇結論。
| 合作與權益情境 | 初步判斷 | 配置前要解決的問題 |
|---|---|---|
| 同一團隊維護多個 App，訂閱仍可分開購買 | 評估 Bundle | 各 App 的單項方案是否保留，組合是否有清楚的附加價值 |
| 多個 App 必須共同提供一套服務 | 評估 Suite | 各 App 如何確認訂閱狀態，使用者跨 App 的權益是否一致 |
| 不同開發者共同納入訂閱組合 | 評估多開發者 Bundle | 參與方權利、責任、訂閱資料及合作條款是否可落實 |
跨開發者合作不是把各方商品放在同一頁就完成。要逐項記錄哪些訂閱由哪一方提供、哪些權益由哪個 App 兌現，以及合作關係變更時如何處理使用者。Apple 將多開發者組合列入 Bundles 與 Suites 的相關說明，但你仍須依其申請與資料要求辦理；提交申請不代表一定獲准，也不代表商店設定已完成。
舊訂閱流程：先估遷移範圍，不必先重寫 App
若現有訂閱仍使用舊實作，先查明購買、交易驗證與權益更新實際由哪些程式碼負責，再確認是否已採用 StoreKit 2。Apple 將 StoreKit 2 列為 Bundles 與 Suites 的要求，並列出 iOS 27、iPadOS 27、macOS 27 或 tvOS 27 及更高版本的系統條件；你還要對照 App 的部署目標和使用者支援範圍。
這不等於每個 App 都必須整體重寫。可以先按功能拆分遷移評估：產品識別與交易處理是否要改、目前的權益資料能否銜接、退款或訂閱狀態變更如何反映，以及舊訂閱者是否仍能正常使用原有權益。若某一部分尚未釐清，就先把它標為阻擋項目，不要把「新方案可在本機測試」當成「現有訂閱已完成遷移」。
申請到發布：以里程碑拆開配置與驗收
Apple 的申請、確認、補交訂閱資料、商店配置與實際發布是不同階段。你可以按以下順序建立驗收紀錄，避免把 API 測試通過誤當成商品已可購買。
- 盤點現況：列出現有 SKU、提供訂閱的 App、權益內容、是否保留單項購買，以及各項權益的負責團隊。
- 選擇產品模型：依單項銷售與跨 App 服務邊界，初篩 Bundle、Suite 或多開發者 Bundle；若產品責任尚未定義，先不送審。
- 核對技術資格：確認實作採用 StoreKit 2，並檢查目標系統是否符合 Apple 公布的適用條件。
- 提交申請並等候確認：保存提交內容與 Apple 回覆。未收到確認前，不把申請狀態標記為已批准。
- 補齊訂閱資料並完成配置：按 Apple 後續要求提供資料，在 App Store Connect 完成對應設定；將商店設定完成視為獨立里程碑。
- 分層測試：用 Xcode 的 StoreKit 測試環境驗證 API 與交易處理，再按 Apple 的StoreKit 分階段測試指引安排 Sandbox 等後續驗證。
- 發布前逐項驗收：檢查 App 內訂閱呈現、購買結果，以及每個 App 是否正確兌現對應權益；保留測試紀錄與商店配置狀態。
Xcode StoreKit 本機測試設定文件說明如何建立本機測試環境；Apple 在 WWDC 2026 的應用程式內購買講解亦介紹 Bundles 與 Suites。兩者可協助你驗證程式行為與理解功能，但本機測試不會替你完成申請、App Store Connect 配置或正式購買驗收。
常見問題
Bundle 與 Suite 的差異，應先看哪一項？
先看訂閱是否仍要分開購買。Bundle 的初篩方向是把仍可單獨購買的訂閱組合銷售；Suite 則要看多個 App 是否共同提供一套服務。最後還要核對 Apple 公布的申請資格與配置流程，不能只按 SKU 數量決定。
只有一個 App 的獨立開發者，該從哪裡開始？
先逐項列出訂閱名稱、獨立權益與是否保留單項購買。若單項訂閱仍有用途，而組合是額外選擇，就先評估 Bundle；若產品並非多 App 服務，不要只因為想簡化價格頁就直接套用 Suite。
不同開發者可以一起提供訂閱 Bundle 嗎？
Apple 官方說明涵蓋多開發者 Bundle。合作團隊要先定義參與方各自提供的訂閱、權益與責任，再按流程申請及補交所需資料。收到確認、完成配置與實際可發布是不同狀態，不能以合作協議或本機測試代替商店批准。
StoreKit Bundles 的系統要求是什麼？
Apple 公布的條件為 iOS 27、iPadOS 27、macOS 27 或 tvOS 27 及更高版本，並要求使用 StoreKit 2。你還要確認 App 的目標系統、現有訂閱流程與權益驗證是否符合需求；具體資格與功能狀態應以 Apple 最新官方文件為準。
若你已定好訂閱方案，下一步應先在 Xcode 驗證 StoreKit 流程，再把 App Store Connect 配置與正式購買路徑分開驗收。若手邊沒有可用的 macOS 環境，本機 Mac 可免除遠端連線與環境交接，但會占用本機硬碟空間，也要自行維護；非 Mac 環境則不能直接取代 Xcode 工具鏈。若只是階段性測試或需要暫時的打包與驗收環境，VMSPIN 提供遠端真實 Mac，能透過 VNC、SSH 或網頁控制台連線；你可先比較方案與費用，確認符合目前工作週期後，再查看遠端 Mac 方案。