Xcode 27.2 RCでオファーコードをどうテストする？2026年StoreKitチュートリアル
📋 目次
Appleの公開記録では、Xcode 27.2 RCは2026年10月19日に公開されています。(Apple Developerのリリース記録
症状：オファーコードを交換できても、アプリの権利状態が更新されたか分からない。
最短解：StoreKit構成ファイルでアプリ内交換とアプリ外交換を別々に実行し、取引更新、権利付与、取引終了まで確認します。ローカル検証だけでApp Store Sandboxや本番環境の審査を済ませたことにはなりません。
この記事は、サブスクリプションやアプリ内課金にオファーコードの交換導線を追加するiOS開発者向けです。
取引監視と権利付与を保守する個人開発者や、Xcode 27.2 RCで公開前の検証を行う小規模チームにも役立ちます。
最終更新：2026年10月30日。Xcodeのリリース日とアップロード状況は、Apple Developerの公開記録およびApp Store Connectの更新情報で確認しています。
ローカル検証とSandbox検証の役割分担
XcodeのStoreKit Testingでは、構成ファイルに設定したオファーコードを使って、アプリ内交換とアプリ外交換の両方をローカルで試せます。ただし確認できるのは、設定したテスト環境でのアプリの処理です。実際のApp Store商品やSandboxでの取引が正常だと証明するものではありません。Appleの開発段階別StoreKitテスト説明も、Xcode内のローカルテストとSandboxを別の検証段階として扱っています。
経路を混ぜると、交換画面が開いたことと、アプリが購入後の権利を正しく付与したことを取り違えます。まずローカルでアプリの取引処理を確かめ、その後にSandboxで実際の商品データを使う段階へ進めてください。
- ローカルのStoreKit Testing：交換導線、取引イベント受信、検証処理、権利付与の実装確認に使います。
- App Store Sandbox：App Store Connectの商品設定を使った取引経路の確認に使います。
- 公開前の最終確認：対象環境での購入動作と、権利・サーバー連携などアプリ全体の結果を確認します。
Xcode 27.2 RCについて、Appleの公開記録はリリース日を2026年10月19日としています。またApp Store Connectの更新情報では、このRCビルドをApp StoreおよびTestFlightへのアップロードに使用できると案内しています。これはRCの記載であり、別のXcodeバージョンにも同じ状態が当てはまるとは限りません。リリース日とアップロード可否は、冒頭に示したApple Developerのリリース記録とApp Store Connectの更新情報を、それぞれ確認してください。
商品設定とStoreKit構成ファイルの準備
最初に、テスト対象の商品とアプリ内オファーコードの組み合わせを決めます。ローカルのStoreKit構成ファイルに入れた商品情報は、App Store Connect上の実際の商品価格や販売状態そのものではありません。XcodeのStoreKit Testing設定手順に沿って、テスト用の構成と実行対象を確認してください。
作業前に、次の順で設定を点検します。
- Xcodeでプロジェクトを開き、テスト対象のSchemeがStoreKit構成ファイルを参照しているか確認します。
- 構成ファイルに対象の商品を用意し、商品IDがアプリ側の判定ロジックと一致しているか照合します。
- 対象商品にテスト用のオファーコードを設定し、アプリで使う商品・オファーの組み合わせを記録します。
- アプリ内交換の導線と、取引更新を受け取る処理がテスト対象のビルドに含まれているか確認します。
- テスト前の取引状態を記録します。既存の取引や付与済みの権利があると、再交換の結果を新規ケースと誤認しやすくなります。
Appleは、アプリでのオファーコード対応について専用の実装説明を公開しています。オファーコードをアプリでサポートする手順を参照し、交換画面を開くAPIと、交換後の取引処理を分けて確認してください。設定ファイル内の商品名や価格表示を、実ストアでの販売条件の証拠として扱わないことも重要です。
アプリ内交換から権利付与までの確認
アプリ内交換では、アプリからシステムの交換画面を開き、利用者が設定済みのオファーコードを選んで確定する流れを確認します。先ほど紹介したAppleのアプリ内オファーコード対応資料を見ながら、交換画面の表示と交換後の取引処理を別々に追跡してください。
実行時は、画面の確認だけで合格にせず、以下の順番で結果を記録します。
- アプリの交換操作からシステム画面が開く。
- テスト対象として設定したオファーコードと商品を選択し、交換を確定する。
- アプリの取引監視処理が対象の取引を受け取る。
- 取引内容を検証し、対象の商品に対応する権利をアプリ内の状態へ反映する。
- 処理完了後に取引を終了する。
「交換画面が表示された」「確定ボタンを押せた」だけでは、権利付与の成功とは判断できません。アプリが受け取った取引の商品IDや状態をログに残し、ユーザーの権利状態が期待どおりに変わったことを確かめます。処理後に取引を終了する設計も、交換処理の完了条件に含めてください。
アプリ外交換とTransaction Managerの判定
アプリ外交換は、アプリ内の交換ボタンを通らずにオファーコード交換が発生した場合の処理を確かめる経路です。XcodeのTransaction Managerで対象商品に対するアプリ外交換をシミュレートし、アプリが取引更新を受け取って権利へ反映できるかを確認します。Appleのアプリ外購入テスト説明では、Transaction Managerを使う検証方法が案内されています。
アプリ内交換とアプリ外交換は、最初の操作場所が異なります。アプリ内の画面遷移だけをテストしても、アプリが起動中または再開時に外部で発生した取引を処理できるとは限りません。
| テスト経路 | 起点 | 合格判定 | 適合度 |
|---|---|---|---|
| アプリ内交換 | アプリの交換導線とシステム画面 | 交換後の取引受信、検証、権利付与、取引終了を確認 | アプリ内導線の検収に高い |
| アプリ外交換 | Transaction Managerでのシミュレーション | アプリが取引更新を受信し、権利へ反映して処理を終えることを確認 | 外部イベントの処理検収に高い |
| App Store Sandbox | Sandboxの商品・取引環境 | ローカル構成では再現できない商品環境を使って取引を確認 | ストア側の確認に必要 |
アプリ外で発生した取引をアプリが受け取る経路として、Transaction.updatesの監視状態を確認します。AppleのTransaction.updates資料に沿って、更新を受けた後に取引を検証し、権利を反映してから取引を終了する処理を追跡してください。
よくある確認事項
Xcode 27.2 RCでアプリ内のオファーコード交換をどう確かめますか？
StoreKit構成ファイルで対象商品とオファーコードを設定し、アプリの交換導線からシステム画面を開きます。交換を確定したら、アプリが取引を受信したこと、取引を検証したこと、対応する権利が付与されたこと、処理後に取引を終了したことを個別に記録してください。画面の表示だけを合格条件にしないでください。
Transaction Managerでアプリ外交換を再現するとき、何を見ますか？
対象商品とオファーコードを設定したStoreKit構成を選び、Transaction Managerからアプリ外交換をシミュレートします。アプリ内の交換画面を経由したかではなく、取引更新の受信、検証、権利反映、処理後の終了までを確認してください。アプリ内経路とは別のテストケースとして記録すると、未検証の経路を見落としにくくなります。
交換後、アプリが取引更新を受け取ったと判断するには？
交換画面の完了表示ではなく、取引監視処理に対象商品に対応する取引が届いたことを確認します。その取引が検証され、期待する権利状態に反映され、完了後に終了されているかも追跡してください。画面表示・取引受信・権利付与を別の判定項目に分けると、失敗箇所を切り分けやすくなります。
再テスト時にStoreKitの取引状態をどう確認しますか？
まずTransaction Managerで対象商品の取引履歴と現在の権利状態を確認します。既存の取引や適用中のオファーが再交換を妨げている場合は、テスト管理機能で該当する状態を整理してから再実行してください。商品種別やオファーの条件によって挙動は異なるため、すべての商品に同じリセット方法を適用しないでください。
取引状態の確認と再テスト
再テストでは、同じ操作を繰り返す前に、現在の取引とアプリ内の権利状態を確かめます。すでに付与された権利や、対象商品に残った取引があると、再交換の結果が初回と異なる場合があります。商品種別やオファー条件を無視して、すべてのケースで同じ再テスト結果になると決めつけないでください。
- Transaction Managerを開き、対象商品に関係する取引を確認します。
- アプリの現在の権利状態と、テスト前に記録した状態を照合します。
- 再実行に影響する取引がある場合は、現在のXcodeとテスト管理機能で利用可能な操作を確認します。
- 適用できる場合に限って該当するテスト状態を整理し、交換経路をもう一度実行します。
- 新しい取引の受信、権利付与、取引終了を、前回の記録と区別して保存します。
状態を整理できない場合は、操作を繰り返して結果を曖昧にするより、別のテスト構成やアカウント状態で条件を切り分けてください。StoreKit Testingのローカル状態を整え直しても、App Store Sandboxや実ストアの取引履歴が同じ方法で初期化されるわけではありません。Appleのテスト段階の説明を基準に、どの環境の状態を変更しているかを記録します。
公開前の判定とMac環境の選び方
公開前の記録には、使用したXcodeの版、StoreKit構成ファイル、テスト対象のScheme、交換経路、取引更新、権利付与、取引終了の結果を含めます。Xcode 27.2 RCのアップロード可否と、StoreKitのローカルテスト合格は別の確認事項です。RCを使った記録にはバージョンを明記し、別のビルドや正式版の検証結果と混同しないようにしてください。
Macを用意する方法は、作業の継続性とコストで選びます。ローカルのMacは手元で直接操作でき、短い作業や物理デバイスを使う確認に向きます。一方、専用のビルド機を購入すると初期費用が発生し、Xcode用に固定したMacを維持する必要があります。購入費と運用条件を比べる際は、Mac miniの料金ガイドも判断材料になります。
ノートPCだけで検証を続ける方法には、作業中に本体を占有する、利用者が席を外すと継続実行しにくい、チーム間で同じ環境を共有しにくいという制約があります。公開前に同じXcode環境で繰り返し検証する必要があり、専用Macの購入を避けたい場合は、実機のMacを期間単位で利用する方法も候補になります。長期の常時高負荷運用や物理機器への接続が欠かせない場合は、購入または手元のMacの方が適することがあります。必要な期間だけMac環境を確保したい場合は、MacDateの案内で利用条件を確認し、ローカル検証とSandbox検証を分けた手順に組み込めるか判断してください。