【体験談】RevenueCat で新しい上位会員プランを追加する際にハマったこと

「既存の有料会員プランに加えて、より高機能な上位プランを導入したい」――サブスクビジネスをしていると、こんな状況はよくあります。
ところが、実際に RevenueCat を使って新プランを追加してみると、思わぬ問題に遭遇することがありました。この記事では、私が遭遇した具体例とあわせて、回避策・注意点を共有します。

背景：既存会員プランがあるアプリに新たな「上位プラン」を追加

現状: 月額・年額などの「Premium会員」がある。
やりたいこと: それより機能が多い「Pro会員」を追加して、ユーザーにアップグレードしてほしい。

iOS (App Store) / Android (Google Play) の両方で対応し、RevenueCat 経由でサブスク管理をしている状態を想定しています。

私が直面した主な問題

当初、RevenueCat の既存の Offering (例: “main”) に新プラン(“Pro”) をそのまま追加したところ、まだアップデートしていないユーザーの古いアプリでも「Pro」が見えてしまいました。

本来は「新バージョンのアプリ」だけに新プランを表示したい のに、既存バージョンからも見えてしまう…。

対策

新しい Offering (例: “v2”) を作成して、そこに新プランを含める。
新バージョンのアプリのみで “v2” を参照するように実装すれば、古いアプリは従来の “main” Offering しか見られず、新プランを取得できない。

新プラン追加時に押さえておきたい注意点

iOS のサブスクリプショングループ

・「既存プラン」と「上位プラン」が同じサブスクリプショングループ内なら、アップグレード扱いとなり差額精算などが行われる。

・別グループにしてしまうと、2重購読になるリスクがあるので要注意。

Google Play のアップグレード／ダウングレード設定

・Play Console の「定期購入」画面で、アップグレード／ダウングレード時の動作を確認し、必要があれば設定する。

RevenueCat での Offering 設計

・既存バージョンも同じ Offering を参照しているなら、そこに新プランを追加すると古いアプリにも新プランが表示される。

・新Offering を作ることで、新プランを新バージョン限定で表示する設計ができる。

テスト環境整備

・iOS なら TestFlight、Android なら内部テスト / アルファ・ベータトラックを用意し、課金周りの動作確認を行う。

・正しいテスト環境を使わないと、ストアの審査や動作検証に手間取るので注意。

具体的な実装例（かんたん解説）

App Store Connect / Google Play Console で新プラン用の定期購入アイテムを登録（審査が必要）。
RevenueCat ダッシュボードで新たに “v2” Offering を作り、その中に4つのパッケージ (プレミアム月/年、プロ月/年等) を追加。
アプリ側（React Native） で Purchases.getOfferings() → offerings.all["v2"] を取得し、UI に反映。
古いバージョン のアプリは引き続き “main” Offering を参照しているため、新プランが表示されない。