expo-revenuecat-superwall-integration

Expo での RevenueCat と Superwall

コードを書く前に、購入完了を担うシステムを 1 つ選んでください。アプリケーションのアカウントと復元ポリシーを維持してください。ペイウォールの統合は、購入の管理者を変更する許可ではありません。

調査して選択する

ロックファイル、Expo の設定、実際のアプリケーションルート、認証コーディネーター、既存の課金呼び出し、商品カタログ、エンタイトルメントのチェックを確認してください。プロジェクトの環境変数処理を通じて公開 SDK キーを解決してください。シークレット API キーや Webhook 認証情報をクライアントコードに埋め込まないでください。

references/architecture-decision-tree.md を使って、次のいずれかを選択してください。

• RevenueCat が購入実行とエンタイトルメントを管理する場合： Superwall の CustomPurchaseControllerProvider、RevenueCat の正確な購入 API、Superwall へのエンタイトルメント全体の単一同期を使用します。同梱の統合例はこの方法を扱っています。
• Superwall または既存の課金実装が購入完了を管理する場合： RevenueCat は purchasesAreCompletedBy を通じて監視できます。これは現在のアーキテクチャであり、単に非推奨の移行回避策というわけではありません。実際の StoreKit バージョンを設定し、レシートとエンタイトルメントが伝播することを検証してください。両方の SDK にトランザクションを完了させないでください。

Expo Go はネイティブストアのテスト環境ではありません。プロジェクトのパッケージマネージャーと npx expo install を使って、必要なパッケージのみをインストールしてください。実際に上書き設定が必要な場合に限り、expo-build-properties を追加してください。古い例にある Android 23／iOS 15.1 の値まで、プラットフォームの最小バージョンを引き下げないでください。

コントラクトを実装する

1. ブートストラップは一度だけ行います。 RevenueCat を呼び出すコードをマウントする前に、RevenueCat の設定が完了するまで待ちます。設定を管理する既存の仕組みがあれば、それを再利用し、別の仕組みを追加しないでください。Superwall の設定に失敗した場合は、ユーザーに分かる形で処理します。
2. 表示された商品と一致させます。 Android のサブスクリプションは、商品、ベースプラン、任意のオファーに基づいて解決します。明示的に指定されたオファーが利用できない場合は、処理を失敗として閉じます。ペイウォールを更新し、defaultOption、最初のオプション、汎用の購入 API に代替しないでください。references/android-base-plans-offers-and-pending.md を参照してください。
3. ストアの実際の結果を返します。 購入済み、キャンセル、保留中、失敗を区別します。課金が完了しているのにエンタイトルメントが非アクティブな場合は、支払い失敗の証拠ではなく、権利付与の問題です。機能へのアクセスを制限して調整し、権利付与の修復のために再度課金しないでください。復元に成功しても、アクティブなアクセス権が見つからないことはあり得ます。
4. 正しく登録し、後始末を行います。 addCustomerInfoUpdateListener の戻り値は void です。同じコールバックを removeCustomerInfoUpdateListener で削除してください。初回取得の前にリスナーを登録し、新しいイベントより古い初回結果が優先されないようにします。アクティブなエンタイトルメント全体をマッピングしてください。ネットワーク障害は、サブスクリプションが非アクティブであることを意味しません。
5. アカウント遷移を制御します。 両方のシステムで同じ不透明な課金 ID を使用します。ネイティブの ID 呼び出しを直列化してください。エフェクトのクリーンアップではそれらをキャンセルできません。認証状態が変わったら ID リビジョンをインクリメントし、そのリビジョンの同期が完了するまで、購入、復元、機能の操作をブロックします。ストア操作の実行中はアカウントの切り替えを延期してください。既知のアカウントから別の既知のアカウントへの変更には、logIn(newId) を直接使用します。匿名状態の作成は、製品で許可されている場合に限ります。
6. 意図的に復元します。 復元はユーザー操作によって行います。過去のデータのインポートや復旧には、承認済みのチェックポイントと syncPurchasesForResult を使用し、マウント時のエフェクトや起動のたびの同期は行いません。呼び出す前に、移転やエイリアスの動作を確認してください。

references/implementation-playbook.md では、例をアプリシェルに結び付けています。これらは統合パターンであり、既存の認証システムの代替ではありません。references/examples/app.example.tsx とシンプルな Router シェルは、ゲストのみをマウントする方法を示しています。認証済みアプリでは、ID ゲートを用意する必要があります。

検証

SKILL_DIR をこのスキルのインストールディレクトリに解決し、アプリを別途渡してください。

python3 "$SKILL_DIR/scripts/validate_expo_setup.py" --project-root /path/to/app
python3 -m unittest discover -s "$SKILL_DIR/tests" -v
node --test "$SKILL_DIR/tests/billing-contracts.test.cjs"

スキャナーが返すのは静的なインベントリであり、申請や課金の準備状況を示すものではありません。動的な Expo 設定を実行したり、環境変数の値を出力したりすることはありません。終了ステータスが 0 であれば、主要な依存関係が欠けることなくインベントリの取得が完了したことを示します。正規表現による検出結果だけでは、プロバイダーがマウントされていることや、コールバックが実行されることの証明にはなりません。

適用した例をアプリにインストール済みの SDK に対して型チェックし、解決済みの設定と統合後のネイティブマニフェストを調べてから、実際の開発用ビルドとストアのサンドボックスビルドをテストしてください。利用できない明示的なオファー、繰り返しのマウント／アンマウント、初回取得とリスナーの競合、A→B→A のアカウント変更、サインアウト、購入のキャンセル／保留／成功、アクセス権がない状態での復元、エンタイトルメント付与が遅れる購入、再インストール、バックエンドの ID を網羅してください。より広範なチェックリストについては、references/testing-matrix.md と references/dashboard-checklist.md を参照してください。

選択した所有者、変更したファイル、正確なパッケージバージョン、実際に実行したテスト、手動で行ったダッシュボード／ストアの手順、未解決の所有権または履行上の問題を報告してください。クライアント側の UI によるゲーティングは、サーバー側の認可の代わりにはなりません。

参考資料

• references/identity-and-restore-behaviour.md：アカウント／復元ポリシーの調査。
• references/ios-uuid-appaccounttoken-and-server-notifications.md：サーバー通知における ID の検討事項。インストール済み SDK の動作と照らし合わせて確認してください。
• references/observability-and-entitlement-verification.md：テレメトリーと検証。
• references/troubleshooting.md：障害の調査。

2026-09-13 に確認した主要な仕様：RevenueCat React Native API、Superwall purchase controller、Superwall RevenueCat integration、RevenueCat Expo setup。

共有されるネイティブの ID／ストアキューについては、ID の調整を参照してください。