購読を組み合わせたいのに、BundleとSuiteのどちらを選ぶべきか決められない。
単独でも購入できる購読をまとめて販売するならBundle、複数Appを一体のサービスとして提供し、購読を個別販売しないならSuiteを優先して検討してください。開発者間の共同提供は多開発者Bundleの対象です。どの方式も、StoreKit 2と対象OSの確認に加え、Appleへの申請とApp Store Connectでの設定が必要です。(AppleのBundlesとSuitesの公式説明)

単一のAppで複数の購読サービスを提供している独立開発者は、単品販売を残す必要があるか判断できます。
複数のAppを運営する開発者は、利用者が必要とする権利が一つのAppに限られるのか、Appをまたぐのかを整理できます。
他の開発者との共同提供を考えるチームは、Suiteと多開発者Bundleのどちらが候補になるか、申請前に確認できます。

確認日:2026年10月25日。AppleのBundlesとSuites公式資料、App Store Connectヘルプ、WWDC 2026の解説をもとに確認しています。 (公式説明・WWDC 2026の解説)

単一Appでの単品販売とBundle

一つのAppに複数の購読がある場合、購読同士を組み合わせて販売する意義があるかを先に見ます。Bundleは、単独でも購入できる購読を組み合わせる設計です。既存の単品プランを残したまま、利用者に組み合わせ購入の選択肢を提示したい場合に検討できます。詳しい提供条件はAppleのBundlesとSuitesの案内で確認してください。

判断材料は、SKUの数だけではありません。どの購読がどの機能を解放するか、購入後に利用者がどの権利を得るか、各購読を単独で選べる必要があるかを一緒に整理します。

一つのiOS Appだけを運営している場合、BundleとSuiteのどちらが候補になりますか?
一つのAppで提供する複数の購読を単品でも販売し、組み合わせ購入も用意したいなら、まずBundleを検討します。Appが一つだからSuiteが不適切と即断するのではなく、Suiteが想定する「複数Appをまたぐ一体型サービス」に当たるか、実際の権利設計で照合してください。

既存の購読をそのまま残すのか、組み合わせ購入後にどの機能を有効化するのかも重要です。表示名だけを束ねても、購入内容に応じた権利判定ができなければ、購入後の体験を一貫させられません。

複数Appの個別提供とSuite

複数のAppを運営している場合も、Appの数だけを見てSuiteを選ぶのは早計です。利用者が一つのAppだけを使う契約を引き続き選ぶのか、複数Appをまとめて使う一体型サービスとして契約するのかを、提供する権利と合わせて決めます。Appleの説明では、Suiteは複数の購読を一つのサービスとして扱い、購読を個別に販売しない形が示されています。

StoreKit BundleとSuiteの違いは何ですか?
判断の軸は「複数の購読を組み合わせても、個別購入を残すか」です。単品購入を残したいならBundleを検討し、複数Appを一体のサービスとして提供して個別購読を売らないならSuiteを検討します。購入後の権利とAppごとの解放範囲が、その選択と矛盾しないように設計してください。

なお、App Store Connectにある従来のApp Bundle作成機能と、StoreKitの購読Bundlesは同じものではありません。App Bundleの作成・提出手順は別の機能として案内されています。名称が似ているため、設定作業を始める前にApp Store ConnectのApp Bundle手順と購読向けの公式説明を見分けてください。

開発者間の共同提供と多開発者Bundle

他の開発者の購読も含めて一つの組み合わせ商品を提供したい場合は、多開発者Bundleが候補です。Appleの公式説明では、複数の開発者による組み合わせが対象に含まれています。ただし、共同提供の合意だけで公開できると考えず、参加者ごとの購読、権利の所有者、利用者へのサポート責任を整理してから申請に進みます。(Appleの多開発者Bundleに関する説明)

複数の開発者が一緒に購読Bundleを提供できますか?
公式資料上、多開発者Bundleは検討対象になります。ただし、申請が必ず承認されるわけではありません。Appleが求める申請手続き、法的な追加条項、提出資料を確認し、参加する各開発者と責任範囲を合意してから準備してください。

提携先が提供する購読の内容や継続条件が変わった場合に、利用者の権利をどう保つかも事前に決めます。共同販売の見せ方だけでなく、購入後の問い合わせ先や権利確認の担当も設計対象です。

StoreKit 2と対象OSの移行判断

Appleの公式資料では、BundlesとSuitesの利用にStoreKit 2が必要とされ、対応するアプリの対象としてiOS 27、iPadOS 27、macOS 27、tvOS 27以降が示されています。対象OSとStoreKitの条件は、申請や実装前に現行のApple公式要件で再確認してください。

使用中の購読実装が旧方式の場合、App全体を書き直す必要がありますか?
新しい購読の組み合わせを検討することと、App全体の再実装は同義ではありません。まずStoreKit 2を使っているか、現在の購入処理と権利確認のどこに変更が必要かを調べます。影響箇所を特定してから移行範囲を見積もれば、不要な書き換えを避けやすくなります。

確認時は、購入開始だけでなく、購入結果の受け取り、購読状態の判定、Appごとの機能解放まで追います。現在の構成が対象OSを満たせるかも、配布対象と利用者層に照らして判断します。

申請から公開確認までのマイルストーン

ローカルでStoreKitの動作を確かめても、App Store Connect上の購読設定やAppleの申請が完了したことにはなりません。申請、Appleからの確認、追加資料の提出、ストア設定、購入経路の確認を別々の段階として管理してください。(BundlesとSuitesの申請手順)

実装確認にはXcodeのStoreKitテスト環境を利用できます。AppleはXcodeでのローカルStoreKitテストの設定と、開発段階からSandboxまでのテスト方法を公開しています。ただし、ローカルテストの成功は、商店上の設定や実際の購入経路が完了した証明にはなりません。(XcodeでStoreKitテストを設定する方法、開発段階とSandboxを通したStoreKitテスト)

  • 商品構成の棚卸し: 現在のSKU、提供する権利、単独購入の要否を一覧にします。
  • 方式の仮決定: Bundle、Suite、多開発者Bundleのどれが商品と権利の設計に合うか絞ります。
  • 互換性の確認: StoreKit 2の利用状況と配布対象OSを調べ、必要な改修範囲を見積もります。
  • 申請準備: 参加する開発者、購読内容、権利の扱い、必要な法的条項や提出資料を確認します。
  • Appleの確認と追加対応: 申請後に届く確認や追加依頼に対応します。申請を提出した時点で公開可能と扱わないでください。
  • ストア設定: App Store Connectで必要な購読情報を構成し、ローカルのテスト設定と区別して記録します。
  • 公開前の受け入れ確認: App内の購読表示、購入結果、各Appでの権利反映をそれぞれ確認します。

方式選定と公開前確認の比較表

次の条件分岐で候補を絞り、最後に申請条件と実際の権利設計を照合してください。

  • 単独購入できる購読を残しながら、組み合わせ販売も提供したい場合は、Bundleを優先して評価します。
  • 複数Appを一体型サービスとして提供し、購読を個別販売しない設計なら、Suiteを評価します。
  • 他の開発者の購読と共同で提供するなら、多開発者Bundleを候補に加え、参加者と申請条件を確認します。
  • StoreKit 2や対象OSの条件を満たせない場合は、機能を前提に公開計画を進めず、実装や配布対象を見直します。
  • Appleの申請・設定が未完了なら、ローカル検証が成功していても公開済みとして扱わず、完了までの作業を分けて管理します。
判断項目 Bundle Suite 多開発者Bundle
主な商品設計 単独でも購入できる購読を組み合わせる 複数購読を一体型サービスとして提供する 複数開発者の購読を組み合わせる
単品販売の考え方 単独購入を残す設計に適する 個別購読を販売しない設計が示されている 参加する購読と提供条件を確認する
優先して確認する点 組み合わせ購入後の権利 Appをまたぐサービス境界と権利 参加者、権利の帰属、申請・契約条件
確認対象 開発・テスト時 公開準備時
StoreKit StoreKit 2対応と購入・権利判定を確認 実際に設定した購読と権利の対応を確認
OS Appleが示す対象OS要件と配布対象を照合 利用者向けの対応範囲を再点検
購入経路 XcodeのローカルStoreKitテストで動作を確認 App Store Connectの設定と購入経路を別に確認
Appleの手続き 実装上の準備を進める 申請、確認、追加資料、構成完了を確認
マイルストーン 完了とみなす条件 未完了時の対応
商品設計 SKU、単品購入の要否、権利の対応が明確 BundleとSuiteの候補を再比較
実装確認 StoreKit 2と購入後の権利判定を検証 対象機能と改修範囲を再調査
申請・構成 Appleの確認とApp Store Connect設定が済んでいる 公開予定を確定扱いにしない
公開前受け入れ 購読表示、購入結果、各Appの権利を確認 不一致の箇所を修正して再確認

Xcode 27でのStoreKitテストは、実装上の購入や権利判定を検証する用途として活用できます。AppleはXcodeのStoreKitテスト設定と開発段階ごとのテスト方法を案内していますが、ローカルの結果だけでApp Store Connectの構成や実購入の確認を代替することはできません。遠隔のMac環境でXcodeを使う場合は、利用可能な環境と接続方法を事前に確かめ、VMSPINのMac利用案内も比較材料にできます。

Xcode 27で確認する作業と、App Store Connectで確認する作業はどう分けますか?
Xcode側では、StoreKitのテスト環境を使って購入処理や権利判定を確かめます。App Store Connect側では、購読情報や申請後の構成状態を確認します。最後にApp内の表示、購入結果、各Appでの権利反映を通して確認し、ローカルテストと公開準備を別々に完了させてください。

検証範囲 確認方法 合格の判断
購入処理 XcodeのStoreKitテスト環境で実行 購入結果をAppが正しく扱う
購読設定 App Store Connect上の構成を確認 申請・設定の状態が想定と一致
権利反映 購入後に対象Appの機能を確認 契約した購読に対応する権利が有効
公開経路 実際の配布・購入準備を確認 ローカルテストだけを根拠に公開可としない

Bundleは単品購入を残したいとき、Suiteは複数Appを一体型サービスとして提供するときの候補です。どちらを選んでも、StoreKit 2、対象OS、Appleへの申請、ストア設定、権利の受け入れ確認を順に進める必要があります。

現在のMacでXcode 27を使え、検証を継続できるなら、その環境を活用するのが自然です。一方、検証のたびにMacを用意する必要がある場合は、購入費用、保管場所、OS更新や環境維持の手間が負担になり得ます。長期にわたる常時稼働や物理接続が欠かせないなら自前のMacが合う場合もありますが、期間を区切った検証では、利用期間や接続方法を確認したうえでVMSPINのMacレンタル案内を比較対象にできます。レンタルを選ぶ場合も、必要なXcode環境が提供されているかを事前に確認し、実際の購入・公開確認はAppleの公式手順に沿って進めてください。