特定のエラーメッセージへの対処だけでなく、次のような一般的なデバッグ手法を活用すると、問題をより早く診断して解決できます。

1. RevenueCat ダッシュボードを活用する

ダッシュボードは最初に使うべきデバッグツールです。設定とユーザーアクティビティに関するリアルタイムデータを表示します。

顧客履歴

1. RevenueCat ダッシュボードに移動します。
2. Customer listsに移動します。
3. 次の項目でユーザーを検索します。
   • App User ID。
   • メールアドレス(設定している場合)。
   • トランザクション ID。
4. 該当ユーザーの購入履歴全体、アクティブなエンタイトルメント、サブスクリプションの状態を確認します。

これにより、次のことを確認できます。

• 購入は実際に処理されたか。
• ユーザーはどのエンタイトルメントを保有しているか。
• サブスクリプションはいつ期限切れになったか。
• 失敗したトランザクションはあるか。

設定の検証

ダッシュボードは設定の問題に関する警告を表示します。

• サービス認証情報の不足。
• ストアで商品が見つからない。
• パッケージのないオファリング。
• 公開されていないペイウォール。

2. サンドボックスと本番環境の両方でテストする

環境固有の問題を見つけるには、常に両方の環境でテストする必要があります。

サンドボックステスト(iOS)

メリット

• 実際の請求が発生しません。
• サブスクリプションの更新がより速くなります(5分 = 1か月)。
• サブスクリプションのライフサイクルを手軽にテストできます。

デメリット

• サンドボックスアカウントの設定が必要です。
• ときどき不安定になったり遅くなったりします。
• 本番環境と動作が異なります。

本番環境テスト

iOS の場合: サンドボックスアカウントで TestFlight を使用するか、別の「テスト用」ビルドを作成します

Android の場合: ライセンステスターとともに内部テストトラックを使用します

本番環境でテストすべきタイミング

• 主要なリリースの前。
• 設定を大きく変更した後。
• エンドツーエンドのフロー全体を検証するとき。

3. より速いテストのために Test Store を使う

RevenueCat Test Store は、サンドボックスで遭遇する多くの悩みを解消してくれます。

• 実際のストアへの依存なし: App Store Connect や Google Play がなくても動作します。
• 予測可能な結果: 購入の成功/失敗を直接制御できます。
• シミュレーター/エミュレーターで動作: 実機が不要です。
• CI/CD フレンドリー: 自動テストに最適です。

詳しくは以下を参照してください。

• iOS 向け Test Store
• Android 向け Test Store

4. 異常な動作が発生したらキャッシュをクリアする

キャッシュされたデータが奇妙な動作を引き起こすことがあります。

RevenueCat の顧客情報キャッシュをクリアする

iOS:

// SDK に最新データの取得を強制する
Purchases.shared.invalidateCustomerInfoCache()

Android:

// SDK に最新データの取得を強制する
Purchases.sharedInstance.invalidateCustomerInfoCache()

デバイス/アプリのキャッシュをクリアする

iOS:

1. アプリを削除します。
2. デバイスを再起動します。
3. アプリを再インストールします。

Android:

1. 設定 → アプリに移動します。
2. 対象のアプリを見つけます。
3. ストレージ → キャッシュを削除をタップします。
4. Google Play ストアのキャッシュも一緒にクリアします。

5. RevenueCat コミュニティを確認する

同じ問題をすでに経験した人がいる可能性が高いです。

• RevenueCat コミュニティフォーラム: 発生したエラーを検索してみます。
• RevenueCat ドキュメント: 公式ドキュメントとガイドです。
• GitHub リポジトリ: Issue や PR を確認します。

6. プロキシを活用したネットワークデバッグ

Charles Proxy などのツールでネットワークトラフィックを検査できます。

確認すべき項目

• api.revenuecat.com への API リクエスト。
• HTTP ステータスコード(200 = 成功、401 = 認証の問題など)。
• リクエスト/レスポンスのペイロード。
• リクエストの所要時間(遅いリクエストはネットワークの問題を示唆します)。

Charles Proxy をセットアップする

1. Charles Proxy をダウンロードします。
2. デバイスが Charles をプロキシとして使用するように設定します。
3. デバイスに Charles の証明書をインストールします。
4. アプリを実行してリクエストを確認します。

7. 問題の範囲を絞り込む

デバッグの際は、何が問題を引き起こしているのか範囲を絞り込んでみてください。

最小限のテストケースを作成する

// SDK の初期化のみをテスト
Purchases.logLevel = .debug
Purchases.configure(withAPIKey: "appl_xxx")
print("SDK initialized")

// オファリングの取得のみをテスト
Task {
    do {
        let offerings = try await Purchases.shared.offerings()
        print("Offerings fetched: \(offerings.all.count)")
    } catch {
        print("Error: \(error)")
    }
}

これにより、問題が次のどこにあるかを判断できます。

• SDK の初期化。
• ネットワーク/API アクセス。
• 商品の設定。
• アプリの UI/ロジック。

8. サンプルアプリと比較する

RevenueCat は、正常動作が確認された公式サンプルアプリを提供しています。

• iOS のサンプル
• Android のサンプル
• Flutter のサンプル

サンプルアプリをクローンしたら、以下の手順を進めてください。

1. API キーを自分のものに置き換えます。
2. 自分の設定でも正常に動作するかを確認します。
3. 自分の実装をサンプルコードと比較します。

よくあるデバッグシナリオのクイックリファレンス

デバッグチェックリスト

サポートを依頼する前に、次のステップをすべて完了しているか確認してください。

• デバッグログを有効にしたか(Purchases.logLevel = .debug)。
• RevenueCat ダッシュボードで設定の警告を確認したか。
• ダッシュボードで顧客を確認したか(該当する場合)。
• ストアと RevenueCat の間で商品 ID が一致しているか確認したか。
• プラットフォームに合った正しい API キーであるか確認したか。
• サンドボックスと本番環境の両方でテストしたか(可能な場合)。
• キャッシュをクリアしてアプリを再起動したか。
• コミュニティフォーラムで類似の問題を検索したか。
• 問題を切り分けるために最小限のテストケースを作成したか。
• 公式ドキュメントを確認したか。