iOS 27 Bundles 和 Suites 怎麼選？2026 獨立開發者指南

iOS 27 Bundles 和 Suites 怎麼選：單一 App 要組合多項訂閱，先評估 Bundles；同一開發者要讓一項訂閱覆蓋旗下多款 App，先評估 Suites。 Apple Developer 在 2026 年 9 月 16 日公布相關說明；跨開發者合作雖屬 Bundles 的適用方向，仍應先核實申請和配置資格，再投入開發。Apple 發布說明｜Bundles 與 Suites 官方要求

適合對象：只有一款 iOS App、正在規劃多個訂閱選項的獨立開發者，可先判斷 Bundles 是否符合商品設計。
經營多款 App 的小型工作室，可比較 Suites 與 Bundles 的產品邊界。
計劃與其他開發者合作的團隊，應先釐清資格及發布驗收路徑。

最後更新於 2026 年 9 月 24 日；資料核對自 Apple Developer 的 Bundles 與 Suites 說明、發布消息及 App Store Connect 相關文件。資格和配置是否開放，仍以 Apple 最新公告及開發者帳號實際狀態為準。

iOS 27 Bundles 和 Suites 怎麼選：先看產品歸屬

不要先從購買頁面或 StoreKit 2 程式碼開始選方案。先確認訂閱要賣給誰、涵蓋哪些 App，以及交易完成後要解鎖什麼。

Apple 將 Bundles 和 Suites 分別對應至訂閱組合及同一開發者旗下多款 App 的使用情境；這是產品方向，不代表每個帳號已能配置。開始排期前，應把官方條件與帳號狀態分開確認。

按條件分流

• 若只有一款 App，而且購買者要一次取得多項訂閱，先評估 Bundles；若只是提供不同單項方案，則把現有商品設計一併納入比較。
• 若同一開發者旗下有多款 App，且目標是共用訂閱，先評估 Suites；若各 App 的權益和訂閱仍各自獨立，不要只為了減少商品數量而改組。
• 若參與者包括不同開發者，先查申請要求、協議和資料準備情況；拿不到帳號實際資格確認時，暫不把 Bundles 配置排入正式發布依賴。
• 若跨 App 解鎖是必要條件，先定義每款 App 要驗證的權益與失敗處理；不能由購買畫面顯示成功，直接推論所有 App 都已授權。

單一 App 獨立開發者：組合訂閱不等於合併權益

一款 App 有多種付費選項，不一定就需要 Bundles。先把現有商品和使用者取得的功能列清楚：哪些權益互相獨立，哪些重疊，訂閱週期又是否一致。Apple 的方案頁列有適用條件與週期要求，應依該頁核對，不要從其他平台的慣例推導可用設定。Apple 訂閱方案條件

比較時，至少回答以下問題：

• 一次購買究竟包含哪些商品或服務？清單能否直接對應到 App 內的實際權益？
• 現有單項訂閱是否仍需保留？組合方案會不會讓使用者重複購買相同內容？
• 訂閱週期是否符合 Apple 公布的要求？若不同週期無法按預期組合，需否維持單項方案？
• 使用者取消、續訂或恢復購買後，App 內應顯示什麼權益狀態？

這份盤點也能避免把「商品如何組合」誤當成「權益如何授予」。前者是訂閱方案設計，後者要由 App 驗證交易並落實授權；兩者需要分別驗收。

多 App 工作室：共享訂閱要先畫出權益邊界

Suites 的評估重點是同一開發者旗下多款 App 的訂閱使用情境，並非把不同 App 的商品名稱放進同一份清單就完成共用。工作室應先列出每款 App 對應的訂閱、解鎖內容、使用者帳號關聯方式，以及訂閱失效時如何撤回權益。

Apple 另有跨 App 提供訂閱的技術說明，可用來確認方案與實作的關係；但技術文件不會自動替團隊決定授權策略。Apple 跨 App 訂閱技術說明

實務上，容易漏掉的是 App 之間的權益落差。例如，某項訂閱在一款 App 解鎖進階功能，在另一款 App 卻只提供部分內容。此時要先決定各 App 的權益映射和使用者體驗，再評估共用方案是否簡化管理；不能假設訂閱商品相同，就代表不同 App 的功能也應完全相同。

跨開發者合作：先核實資格，再估算工作量

多位開發者共同提供訂閱，不能單靠 StoreKit 2 程式碼推定已符合 Bundles 配置條件。Apple 公布的說明涉及申請、協議及資料要求，團隊應逐項對照；如果帳號中尚無可用配置入口，應把狀態記為待 Apple 確認，而不是視為已開放。

建議在立項前完成以下核驗：

• 確認參與方與開發者帳號的歸屬，以及誰負責訂閱商品和發布。
• 依官方說明整理需要的申請資料與協議狀態。
• 登入相關帳號確認實際配置入口，不以程式碼已能處理交易代替資格確認。
• 將 Apple 尚未確認的申請結果、開放範圍或流程，列為發布風險與待辦事項。

提醒：資格、帳號配置與 App 端交易處理是不同結果。某一項已完成，不等於整個跨開發者訂閱流程已可供使用者購買。

StoreKit 2 開發者：分開驗收交易與權益

Apple 說明 Bundles 與 Suites 使用 StoreKit 2。StoreKit 2 提供交易及訂閱相關 API，但實際產品仍要把交易驗證、權益映射、跨 App 存取和恢復購買分開測試。StoreKit 2 官方介紹

Transaction 用於處理交易資料；Transaction.currentEntitlements 可供 App 檢查目前權益。這些 API 是驗收的技術依據，不是未經測試的跨 App 授權保證。Transaction 說明｜currentEntitlements 說明

可以先建立一份權益映射，再在程式中逐筆處理已驗證的交易：

for await result in Transaction.currentEntitlements {
    guard case .verified(let transaction) = result else {
        continue
    }

    // 依 productID 對照此 App 的權益規則
}

這段程式只呈現檢查權益的方向。每款 App 仍需定義自己的商品對照與授權結果；跨 App 的帳號關聯、狀態同步及錯誤處理，必須按實際架構驗證。

測試時分開記錄四種結果：

• 交易處理：交易是否經過驗證，失敗或未驗證時是否安全處理。
• 權益映射：每個商品是否解鎖正確內容，訂閱狀態變化後是否更新。
• 跨 App 存取：若方案涉及多款 App，各 App 是否按各自規則驗證及顯示權益。
• 恢復購買：重新安裝或切換裝置後，使用者能否恢復應有權益。

Apple 提供以 Xcode 和 Sandbox 測試內購的指南，也列出 TestFlight 訂閱測試資訊。測試環境中的購買流程能否走通，與正式環境的資格、配置和跨 App 授權是否全部成立，必須分開判定。Xcode 與 Sandbox 測試指南｜TestFlight 訂閱測試說明

發布負責人：用構建和測試結果完成閉環

發布驗收不是只看 App Store Connect 是否出現新設定。應把配置資格、Xcode 構建、購買測試及 App 內權益結果分別留存，再按順序核對：

• 在 App Store Connect 檢查帳號和訂閱方案的實際配置狀態；尚未確認可用時，不將其記為已完成。
• 依目前專案和方案需求執行 Xcode 構建，確認設定能進入預期建置產物。
• 在對應的測試環境驗證購買、交易處理與恢復購買；記錄使用的環境和測試結果。
• 對涉及多款 App 的方案，逐款驗證權益，不以一款 App 的購買成功代替其他 App 的驗收。
• 發布前重新核對 Apple 最新文件和帳號狀態，將資格、構建、購買及授權分成不同檢查結果。

發布記錄可用簡單命令保留構建資訊，再附上各項測試證據：

xcodebuild -version
git rev-parse HEAD

輸出範本（以實際執行結果填寫，不應當作已驗收證明）：

Xcode: <實際版本輸出>
Commit: <實際提交識別>
App Store Connect 資格: <已確認 / 待確認>
購買與權益測試: <通過項目及未通過項目>

這樣可避免把 Xcode 構建成功誤當成訂閱配置已開放，也避免把測試購買成功誤當成跨 App 權益已完成。若團隊正在安排發布機器或測試環境，可先參考SFTPMAC 的 Mac 方案資訊；具體環境是否符合專案需求，仍要按實際配置確認。

FAQ：按團隊情境釐清方案邊界

Bundles 和 Suites 的差異要看什麼？

先看購買目標和 App 歸屬。Bundles 著重多項訂閱的組合購買；Suites 面向同一開發者旗下多款 App 共用訂閱的情境。Apple 的產品說明界定適用方向，但不代表每個帳號都已取得配置資格。

只有一款 App，該從哪一種方案開始評估？

如果需求是在同一款 App 中把多項訂閱組合成一次購買，先評估 Bundles；如果訂閱仍是互不相干的單項方案，也要保留現有設計作比較。應同時核對商品、權益重疊和官方週期要求，不能只根據購買頁的呈現方式決定。

同一工作室的多款 App 想共用訂閱，先整理什麼？

先逐款列出訂閱商品、解鎖內容、使用者存取方式及權益失效時的處理規則，再確認 App 是否屬同一開發者。若目標確實是由一項訂閱涵蓋旗下多款 App，優先評估 Suites；授權如何在每款 App 落實，仍須獨立驗證。

跨開發者團隊何時可以把 Bundles 納入發布計畫？

先按 Apple 公布的要求核對申請資料、協議和帳號配置狀態。StoreKit 2 程式已能處理交易，不代表申請已核准或配置入口已開放。取得實際確認前，應將可用性和流程列為待核實項目，不要把它當作已具備的發布條件。

選方案後的發布環境取捨

單 App、多 App 和跨開發者團隊的判斷方向不同，但都要用實際構建及購買流程確認交付結果。若現有流程依賴開發者手邊的 Mac，設備成本、維護與多人共享會成為管理負擔；若改用一般雲端建置環境，對作業系統控制、安裝工具及測試流程的掌握程度則需逐項確認，不能假設都符合 Xcode 發布需求。

需要短期搭建或復測 Xcode、TestFlight 發布鏈路時，遠端 Mac 租用可以作為購置實機以外的選項；但若工作量長期穩定且持續偏高，自購設備可能更符合成本規劃，若測試依賴實體周邊，也應先確認連線方式。評估遠端方案前，可查看SFTPMAC 的 Mac mini 租用方案資訊，再依專案的工具鏈、存取方式和租用週期判斷是否合適。