RevenueCat iOSサブスクリプションをローカルテストする方法？2026年リモートMac手順

購入ロジックと権利状態の検証 → RevenueCat Test Storeから始め、StoreKit構成、Apple Sandboxの順で進めてください。
公開前のプラットフォーム確認 → Sandboxまで実施し、環境ごとの合格を別々に記録します。

RevenueCatを初めて導入し、購読画面や権利の有効化を確かめたいiOS開発者は、まず環境の違いを確認してください。
Xcodeのシミュレーターで購入を再現したい場合は、StoreKit構成の設定を重点的に読み進めます。
手元にMacがなく、リモートMacでビルドと検証を行う小規模チームには、後半の再現手順と認証情報の分離が役立ちます。

RevenueCat iOSサブスクリプションテストは、3つの環境をどう使い分けるか

Test Storeはアプリの購入処理と権利状態、XcodeのStoreKit構成はローカルでのStoreKit取引、Apple SandboxはAppleの購入経路を確認するために使います。目的が異なるため、ひとつの環境で成功しても、ほかの環境の検証を省略しないでください。RevenueCatのTest Storeの機能と用途と、Appleが説明する開発段階ごとのStoreKitテスト環境を基準に、次の順で進めます。

適合度は各環境の用途に対する編集上の評価です。Test StoreはAppleのプラットフォーム取引を証明するものではなく、StoreKit構成の購入成功もApp Store Connectの商品情報が正しい証拠にはなりません。

最初に商品と権利を対応させ、キーを分ける

購入テストを始める前に、RevenueCatプロジェクトの商品識別子とentitlementの対応を確認します。商品がアプリ内の購読プランを示していても、購入後にどの機能を有効にするかという権利設定が別なら、購入成功だけでは受け入れ条件を満たしません。RevenueCatのiOS商品とentitlementの設定手順に沿って、商品から権利までの関連を確認してください。

SDKの初期化にはアプリ用の公開SDKキーを使い、Secret API keyなどのサーバー用秘密情報はアプリに埋め込まないでください。RevenueCatのSDK設定ガイドを参照し、キーの用途と保存場所を分けます。サンプル内の値は、実際のキーではなく次のようなプレースホルダーに置き換えてください。

公開SDKキー: <PUBLIC_SDK_KEY>
商品識別子: <PRODUCT_ID>
entitlement識別子: <ENTITLEMENT_ID>
ユーザー識別子: <APP_USER_ID>

テスト実行前には、アプリが参照するユーザー識別子、商品識別子、ビルド設定が同じテスト環境を指しているかを記録します。実行中に環境を切り替えた場合は、キー、商品、テストユーザーを改めて照合してください。テスト用のキーや設定をリリース構成に残すと、本番の購入確認を誤る原因になります。

最初の購入はTest Storeでアプリの応答を切り分ける

RevenueCat Test Storeでは、まず購入成功、購入キャンセル、購入失敗のそれぞれに対するアプリの表示と状態変更を確認します。購入後にCustomerInfoが更新され、想定したentitlementが有効になるかをチェックしてください。Test StoreはSDK接続やアプリ内の状態遷移をすばやく検証する用途に向きますが、Apple Sandboxの取引挙動を保証するものではありません。

App Store ConnectにAppleの商品を用意する前でも、RevenueCat側にテスト商品と権利の対応を設定すれば、Test Storeでアプリの購入ロジックを確認できます。ここで確かめられるのはRevenueCatとアプリの連携であり、Apple側の商品登録やストア表示ではありません。テスト結果には「Test Store」と明記し、Apple Sandboxの結果と混同しないようにします。

Xcode StoreKit構成ならローカル購入を再現できるか

XcodeのStoreKit構成ファイルを専用Schemeに関連付けると、ローカルの商品設定を使った購入フローを検証できます。AppleのStoreKit Testing設定手順を確認し、起動するSchemeが意図した構成ファイルを参照しているかを確かめてください。

設定では、StoreKit構成内の商品識別子とRevenueCat側の商品設定を照合します。識別子が一致しない場合、購入画面が動いても期待する商品の情報やentitlementに結び付かないことがあります。RevenueCatのApple App StoreとローカルStoreKitテストの説明も参照し、利用するSDKのテスト方法と必要な設定を確認してください。

ローカルのStoreKit構成は、App Store Connectに登録された商品へ自動で変換されるものではありません。したがって、シミュレーターで購入が完了しても、Apple側の商品名や価格、Sandbox取引の確認まで済んだとは判断できません。また、ローカル購入の結果だけから、返金や購入取消し、プラットフォーム側のイベント処理まで検収済みと推定しないでください。

公開前はApple Sandboxで購入経路を再確認する

Apple Sandboxでは、実際に使うプラットフォーム側の商品設定を前提に購入経路を検証します。AppleのSandboxテスト概要に従い、テスト用アカウントや対象アプリの準備状況を確かめてから購入を実行してください。App Store Connectの商品登録が必要な検証と、RevenueCat Test Storeだけで行えるアプリロジックの検証は分けて記録します。

受け入れ記録では、購入フローの成否と商品メタデータの正確さを別項目にします。購入が完了して権利が有効になったか、表示する商品名や価格が意図どおりかを個別に確認してください。シミュレーターと実機のどちらを使うかは、対象のテスト機能とリリース先に応じて決めます。シミュレーターでの成功を、実機を含むすべての購入環境での合格に広げてはいけません。

最後にリモートMacで同じ条件を再現する

リモートMacでも、テスト対象のコミット、Scheme、StoreKit構成、RevenueCatの商品設定を固定すれば、Xcodeのビルドとシミュレーターでの再検証を進められます。ローカルとリモートで設定が異なると、購入結果の差がコード変更によるものか環境差によるものか切り分けにくくなります。リモートMacを含む環境の選択では、物理Macと仮想化環境の違いも確認し、必要なテスト条件と照らし合わせてください。

実作業では次の順に確認します。

1. 対象を固定します。 テストするコミット、アプリのビルド構成、Schemeを記録します。
2. 商品対応を確認します。 商品識別子、entitlement、アプリ内のプラン表示を照合します。
3. 環境を選びます。 アプリロジックならTest Store、ローカル取引ならStoreKit構成、Appleの購入経路ならSandboxを選びます。
4. 購入結果を記録します。 成功、キャンセル、失敗それぞれの画面、CustomerInfo、entitlementの状態を残します。
5. 公開設定と分離します。 キーやSchemeを再確認し、テスト用設定がリリース構成に混ざっていないことを確かめます。
6. 環境切り替え後に再検収します。 リモートMacで設定を切り替えたら、使用中のキー、商品、テストユーザーを再確認します。

購入結果の記録には、使用環境、対象の商品識別子、Scheme、確認した権利状態を含めます。認証情報そのものはログや共有資料に貼らず、必要な担当者だけが参照できる場所で管理してください。シミュレーターでの再現はリモートMacでも行えますが、Apple Sandboxでの確認を省けるという意味ではありません。公開先に応じて必要な端末やプラットフォームの確認を追加します。

手元のMacだけで続ける方法は、追加の機材や契約が不要な一方、ローカルのディスク容量を圧迫しやすく、開発用設定と検証用設定が混ざり、チームで同じビルド条件を保ちにくい面があります。Macを新たに購入する方法も、継続利用する開発環境には適していますが、短期の検証用マシンには初期費用や管理の負担が残ります。Xcodeとシミュレーターを日常環境から分けて使いたい場合は、MacDateのMacレンタル料金案内を確認し、必要な期間とテスト対象に合うかを判断してください。リモートMacはビルドやシミュレーター検証の選択肢になりますが、Apple Sandboxやリリース先で必要な実機確認の代わりにはなりません。