技術記事

アプリ単体で収益化する場合、サブスクの実装は事業の生命線です。
メディカルサークルでは、Apple / Google の課金を RevenueCat 経由で統合し、Firestore と同期させる構成を採用しました。
本記事では、その実装で詰まった点と学びを共有します。

Entitlement Identifier は変更不可

RevenueCat の Entitlement Identifier は、ダッシュボードで一度作成すると変更できません。
有料プラン名を改名した際、合わせて Identifier も変えたかったのですが、不可能でした。
結果として、Identifier は「内部的な識別子」、プラン名は「ユーザーに見せる表示名」と完全に分離し、コード側で定数として一元管理する設計に切り替えました。

課金状態を Firestore とアプリ内 state に二重反映する

RevenueCat のリスナーで課金状態の変化を検知し、変化時には Firestore のユーザードキュメントの isPremium フラグを更新します。
同時にアプリ内の状態管理プロバイダも更新し、UI 側はプロバイダを監視するだけで有料機能のロック/アンロックが即座に切り替わるようにしました。
Firestore 側にもフラグを置いているのは、セキュリティルールで参照する必要があるからです。
「クライアントの自己申告だけでルールを書く」のは危険なため、二重反映は必須でした。

1 つのプロバイダで有料機能の制御を統一する

有料機能のロック/アンロックを画面ごとにバラバラに書くと、改修時に必ずどこかが取り残されます。
メディカルサークルでは、課金状態を返すプロバイダを 1 つ定義し、すべての画面からそれを参照する方式に揃えました。
画面ごとの分岐は「プロバイダの値を見て if/else する」だけで済むため、新規プラン追加や条件変更にも追従しやすい構造になっています。

「購入の復元」は機能というよりテストの問題

App Store の審査で必須となる「購入の復元」は、設定画面にボタンを配置し、タップ時に RevenueCat の復元 API を呼んで結果を反映する構成です。
実装自体は数十行で済みますが、本当の論点は「ちゃんと動作するかをどう検証するか」でした。
サンドボックスアカウントを用意し、購入 → アンインストール → 再インストール → 復元、というシナリオを実機で繰り返し検証することで、リリース後のサポート問い合わせを最小化できました。

まとめ

RevenueCat を組み込んだ課金実装は、コードだけ見れば単純です。
しかし「Identifier の不変性」「ルールとの同期」「画面横断の制御」「復元の検証」という、見落としやすい論点が積み重なります。
メディカルサークルでは、最初の数日でこれらをまとめて潰しておいたことで、その後の機能開発を課金まわりに足を引っ張られず進められました。