App Storeでのサブスクリプションのテストは非常に重要ですが、適切に行うのは簡単ではありません。Appleのサブスクリプション関連ドキュメントは……正直に言って物足りず、テスト用のリソースもあまり提供されていません。そこで私たちは、そのギャップを埋めるためにこのガイドを作成しました。
Appleがサブスクリプションに変更を加えたり、より効果的なテスト方法が見つかった際には、この投稿も随時更新していく予定です。
Android向けのガイドをお探しですか？Androidサブスクリプションテストガイドはこちらをご覧ください >>
このガイドは、TestFlight におけるサブスクリプションテストの変更を反映するために、2024年12月に更新されました。
iOSテスト環境
iOSアプリを開発やリリースの各段階でテストする際には、3つの異なるテスト環境を使用することができます。これには、サンドボックス（開発者ビルド）、TestFlight（プロダクションサンドボックス）、そしてプロダクション（App Store）が含まれます。これらの環境はそれぞれ挙動が少しずつ異なるため、理想的にはアプリをリリースする前にすべての環境でテストを行うべきです。
サンドボックスでのiOSテスト
開発者用サンドボックスは、テストの第一段階として重要な役割を果たします。プロダクション環境でのテストに進む前に、開発中にこのサンドボックスの特性や制限をしっかりと把握しておくことで、後の 工程で時間を節約できます。
開発者サンドボックスでテストを行うには、Xcodeでアプリを「デベロッパービルド」としてビルドする必要があります。開発者は通常、開発中にデバイス上で素早く動作確認を行うためにこの環境を使いますが、TestFlightやベータ版審査を経ずに、プロビジョニングされたデバイスを使ってQA担当者や社内テスターにもこのビルドを配布することができます。
アプリがApp Store外で広く配布されるのを防ぐために、Appleはデバイスごとのプロビジョニング数を制限しています。iPhone、iPad、Apple Watch、Apple TV、Macの各デバイス種別ごとに最大100台まで、合計で500台が上限です。
iOSの開発者用サンドボックスでテストを行うには、サンドボックスアカウントが必要です。この点についてはAppleの公式ドキュメントが比較的よく整備されており、今後も最新の情報が保たれることを願いたいところです。
新しいサンドボックスアカウントで初めてサインインするには、まず開発者ビルドのアプリ内で購入を試みる必要があります。この方法でサンドボックスアカウントにログインすると、その後、設定アプリを開き、iTunes & App Storeをタップし、画面を一番下までスクロールするとSandbox Accountのセクションが表示されます。
このセクションでは、テスト用に複数のサンドボックスアカウントをログイン・ログアウトして切り替えることができます。もし誤ってサンドボックスアカウントを本番のApp Storeで使用してしまうと、そのアカウントはサンドボックス環境で使用できなくなります。迷ったときは、新しいサンドボックスアカウント を作成して再度テストするのが確実です。
（設定アプリのSandbox Accountセクションは、iOS 12で導入されました。iOS 11以前でテストする場合は、まず本番用のApp Storeアカウントからサインアウトし、アプリ内で求められたときにテストアカウントでサインインする必要があります。）
テスト購入を行おうとすると、デバイスが何度もサンドボックスアカウントへのサインインを求めてくる場合があります。これは正常な動作であり、ダイアログが表示されるたびにサインインしてください。最終的にiOSが認証を完了し、購入が正常に進むようになります。なお、この挙動は本番環境では見られず、あくまでサンドボックス環境特有の挙動です。
信頼性についての注意点
開発者用サンドボックス環境は、信頼性が低いことでよく知られています。（参 考までに、RevenueCatではサンドボックス環境の稼働状況を確認できる便利なダッシュボードを提供しています。）Appleが意図的に本番環境で起こりうる問題を模倣するためにパフォーマンスを制限しているのか、それともApple自身もこのサンドボックスを内部のテストに使用していて、意図せず頻繁に壊しているのかは定かではありません。
いずれにせよ、コードが正しく動作しているにもかかわらず、サンドボックス側で問題が発生することがあるという点を念頭に置いておいてください。そうした状況は、予期しないエラーをどのように処理するかを見直す良い機会でもあります。
とはいえ、「本番に出せば自然に直るだろう」といった楽観的な見方は禁物です。このガイドでは既知のサンドボックスの癖についても紹介していますが、それでもアプリを公開する前に、サンドボックス内で購入フローをエンドツーエンドで確実にテストできるようにしておくべきです。
開発者用サンドボックス環境におけるサブスクリプションの更新間隔
サンドボックスでは、サブスクリプションや無料トライアルの期間が大幅に短縮されており、これはテスト目的のために設定されています。この仕組みによって、開発者は購入、更新、失効といった一連のフローを迅速かつ繰り返しテストすることが可能になります。
| App Store Duration | Sandbox Duration | Testflight |
| 3 days | 2 minutes | 1 day |
| 1 week | 3 minutes | 1 day |
| 1 month | 5 minutes | 1 day |
| 2 months | 10 minutes | 1 day |
| 3 months | 15 minutes | 1 day |
| 6 months | 30 minutes | 1 day |
| 1 year | 1 hour | 1 day |
（この「3日間の期間」についてはAppleの公式ドキュメントには記載されていませんが、サンドボックスのトランザクションを確認することで把握できます。）
App Store Connectのサンドボックステストアカウントの設定から、サブスクリプションの更新間隔を変更することができます。
サブスクリプションはアカウントごとに最大12回まで自動更新されますが、実際の更新回数はランダムです。12回の更新を超えると、それ以降は自動的に更新が止まります。
App Storeと同様に、アプリが開 かれていなくても更新は自動的に行われます。ただし、App Storeとは異なり、サンドボックス環境では購読のキャンセルや払い戻しはできないため、それらのシナリオを直接テストすることはできません。また、サブスクリプション管理のテストも行えません。
各自動更新は決済キューに追加されます。アプリを再度起動すると、その間に発生したトランザクション（時間の経過に応じて複数ある場合もあります）が処理されます。最新のレシートを確認するには、一度アプリを閉じてから再度開くようにしてください。レシートをサーバー側でリフレッシュしている場合は、これらの追加トランザクションもレシートに表示されるはずです。
テスト手順
更新とサブスクリプションの有効期限切れ
- 月額サブスクリプションに登録します。
- アプリを閉じて、20分のタイマーをセットします。
- 20分後にアプリを再起動し、まだサブスクリプションが有効な状態であることを確認します。
- アプリを閉じて、再度20分のタイマーをセットします。
- さらに20分後（サブスクリプション購入から約40分後）にアプリを再度起動します。すると、アプリは未購読の状態に戻り、ユーザーが再度サブスクリプションに登録できるようになるはずです。
有効期限切れ後の購入の復元
- 月額サブスクリプションに登録します。
- アプリを閉じて、35〜40分待ちます。
- アプリを起動します（未購読の状態に戻っているはずです）。
- 購入を復元ボタンをタップします。
- アクティブなサブスクリプションは見つからず、ユーザーにはその旨を伝えるメッセージが表示されるべきです。
有効なサブスクリプション期間中の購入の復元
iOSのサンドボックス環境でのテストにおける大きな注意点の1つは、購入が行われるまでデバイス上にレシートファイルが存在しないことです。これは、インストール時にレシートファイルが生成されるプロダクションサンドボックスおよび本番環境とは異なります。サンドボックスでの購入復元を完全にテストするには、アプリを未購読の状態に戻すためのボタンやジェスチャーなどの手段を追加する必要があります。
- 月額サブスクリプションに登録します。
- ボタンやジェスチャーを使用して、アプリを未購読の状態に戻します。
- 購入を復元ボタンをタップします。
- これを35分のサブスクリプション期間が終了する前に実行すれば、有効なサブスクリプションが見つかり、アプリは購読中の状態に戻るはずです。
複数デバイス間での購入の復元
- デバイスAで月額サブスクリプションに登録します。
- サブスクリプションが失効する前に、デバイスBにアプリをインストールします。
- デバイスBで、デバイスAで使用したものと同じサンドボックスアカウントにログインします。
- デバイスBでアプリを起動します。
- 購入を復元ボタンをタップします。
キャンセルのテスト
- 月額サブスクリプションに登録します。アプリがサブスクライブ状態になっていることを確認します。
- 設定アプリ > App Store > 使用中のサンドボックスアカウント > 管理 > サブスクリプション と進み、登録済みのサブスクリプションを選択します。
- サブスクリプションをキャンセルし、利用規約に同意します。
- アプリを終了し、10分ほど待ちます。
- アプリを再起動します。
- アクティブなサブスクリプションは検出されないはずです。
アップグレード、ダウングレード、クロスグレードのテスト
iOS 14以降では、設定アプリ内のサンドボックス用サブスクリプション管理画面からこれらの操作をテストできます。iOSの古いバージョンをテストする場合は、アプリ内にボタンなどの手段を用意して、アップグレード、ダウングレード、クロスグレードをトリガーする購入をテストする必要があります。
- 月額サブスクリプションに登録します。
- アプリを終了します。
- 設定アプリ > App Store > 使用中のサンドボックスアカウント > 管理 > サブスクリプション に進み、現在のサブスクリプションを選択します。
- リストから別のプロダクトを選択してサブスクリプションを変更します。
- もしサブスクリプションをダウングレードした場合は、5〜10分ほど待ちます。
- アプリを起動します。
- ユーザーは新しいプロダクトにサブスクライブされているはずです。
購入の中断
※この挙動はiOS 14以降でのみ可能です。
- App Store Connect > Users and Access > Sandbox Testers に移動し、「Interrupt Purchases for This Tester（このテスターに対して購入を中断する）」を有効にします。
- このユーザーとしてログインした状態で、自動更新サブスクリプションを購入します。
- 利用規約のダイアログが表示されたら、「キャンセル」をタップして利用規約に同意しないでください。
- アプリが購入を解除していないか確認します（解除されるべきではありません）。レシートには、今試みた購入は含まれていないはずです。
- もう一度購入を試み、今度は利用規約に同意してください。
- アプリを更新すると、有効なサブスクリプション購入が反映されているはずです。
重要なポイント
- サンドボックス環境では、サブスクリプションは通常よりも早いペースで自動更新されます。
- サンドボックスでは、購入が行われるまでレシートは生成されません。
- StoreKitTest を使ってテストしている場合でも、定期的に実際のサンドボックス環境でアプリをテストすることを忘れないでください。
開発者用サンドボックスにおけるトライアルの利用資格
アプリ内にユーザー向けの無料トライアルを提供する「初回オファー付きのプロダクト」が含まれている場合、それらのオファーを受け取る資格があるユーザーのみにトライアル情報がペイウォール上に表示されるかどうかをテストする必要があります。まず、新規のサンドボックステスターアカウントを使用してアプリを起動し、初回オファーがあるプロダクトに対して正しい文言が表示されているか確認します。その後、実際にそのプロダクトを購入し、すぐにキャンセルして、上述の短縮されたサンドボックスの期間に基づいてトライアルが終了するのを待ちます。
トライアル終了後、再度ペイウォールを開き、そのアカウントで該当のプロダクトが「トライアルを受け取る資格がない状態」として表示されているか確認します。ペイウォール上の文言は、もはや無料トライアルが提供されることを示していないはずです。このテストを繰り返したい場合は、these Apple の提供する手順に従って、サンドボックスユーザーのトライアル利用資格をリセットすることができます。
さらに詳しく
- アプリ内課金テスト （Apple公式ドキュメント）
- アプリ内課金トランザクションのテスト （Apple公式ドキュメント）
StoreKitTest
iOS 14以降、StoreKitTestフレームワークを使用して、Xcode上でローカルにStoreKitのテストが可能になりました。これにより、App Store Connectでの製品の追加、購入処理、サブスクリプションライフサイクルの一連の流れなど、AppleのStoreKitシステム全体をシミュレートできます。Appleのサンドボックス環境でのテストに比べて、より迅速にテストできるのが利点です。StoreKitTestは、コンテンツのロック／アンロックといった一部機能のテストに活用するのがおすすめです。ただし、最終的なテストは必ずサンドボックス環境でも行い、App Store Connectでの設定が正しく機能していることを確認する必要があります。
StoreKitTestでのサブスクリプション更新間隔の設定
デフォルトでは、StoreKitTestを使用して行ったサブスクリプションはリアルタイムで更新されます。ただし、StoreKitTestの構成ファイル（Configuration File）をXcodeで開き、「Editor > Subscription Renewal Rate」に移動することで、更新間隔を変更することが可能です。ここで提供されているいずれかの更新間隔を選択することで、より柔軟にテストのスピードやシナリオを調整できます。
TestFlightを使ったiOSテスト
TestFlightはサンドボックス環境と似た挙動をしますが、実際のApp Storeアカウントを使用します。TestFlight経由で配布されたアプリは、自動的に本番用サンドボックス環境を使用して課金処理を行います。TestFlightビルドではユーザーが実際に課金されることはありませんが、ペイウォールを表示したり、購入フローを実際に踏んで動作を確認したりすることが可能です。
本番用サンドボックスにおけるサブスクリプションの更新頻度
2024年12月より、AppleはTestFlightでのサブスクリプション更新頻度をサブスクリプションの期間に関係なく24時間に1回へと変更しました。以前は、TestFlight上でのサブスクリプションは数分おきに更新されており、1日のうちに複数回の課金サイクルを迅速にテストすることが可能でした。
この変更はAppleから公式に発表されたものではありませんが、以下のドキュメントに記載されています：https://developer.apple.com/help/app-store-connect/test-a-beta-version/subscription-renewal-rate-in-testflight
これにより、TestFlightを使ったサブスクリプションライフサイクルのテストに時間がかかるようになりました。
TestFlightでの購入状態の切り替え
テストを効率よく行うために、TestFlightビルドにアプリ内の購入状態を切り替えるボタンや隠しジェスチャーを追加すると便利です（※App Storeに提出する本番ビルドではビルドフラグを使ってこの機能を必ず除去してください）。また、ベータテスターにペイウォールのテストを依頼する際は、TestFlightのリリースノートにこの機能の存在を明記するのを忘れずに。
注意点として、TestFlightは本番用サンドボックス環境を使用しますが、TestFlightに提出するビルドは、最終的にApp Storeで公開するビルドと同一のものであるべきです。バックエンドがステージング環境と本番環境で分かれている場合、TestFlightビルドは本番のバックエンドに接続しつつ、購入処理は本番サンドボックス環境で行われること になります。
一般的なセットアップは以下のようになります：
| アプリの種類 | App Store | あなたのバックエンド |
| Sandbox | Sandbox | Staging |
| TestFlight | Production Sandbox | Production |
| App Store | Production | Production |
TestFlightベータテスターとのコミュニケーション
TestFlightでのサブスクリプションテストにはいくつか制約があります（すべてのサブスクリプション期間が固定で24時間ごとに更新されるようになった点も含むため）、多くの開発者はベータテスター向けに全機能を自動的にアンロックする選択をしています。
絶対に避けたいのは、TestFlightのベータテスターを使ってアプリの価格テストやペイ ウォールのA/Bテストなどを行うことです。AppleはTestFlightユーザーに対して実際に課金することを許可していませんし、大半のベータテスターもそのことを理解しています。したがって、そうしたテスト結果は偏ったものになります。仮にAppleがTestFlightユーザーへの課金を許可していたとしても、ベータテスターは多くの場合、あなたのアプリに強く関心を持つ忠実なユーザーです。つまり、アプリを初めて使う一般的なユーザー層とは大きく異なります。
とはいえ、一部のベータテスターにペイウォールを実際に表示し、ペイウォールが表示されるトリガーから購入処理（サンドボックス環境で）までの一連の流れを体験してもらうことは有用です。重要なのは、その流れをどのようにテスターに説明し、実際に役立つフィードバックが得られるように導くかです。
正直なところ…ほとんどの人は細かい注意書きなんて読みません。せいぜい斜め読み程度ですそのため、アプリのプレミアム機能をすべてロックした状態でベータを配信し、「ベータ版には制限があります」とリリースノートに書くだけでは、うまくいかないことが多いです。結果として、混乱したベータテスターがプレミアム機能をうまくテストできない、という事態になりがちです。
一つの方法としては、ベータテスター向けに全機能をアンロックしておき、ペイウォールテストの手順をリリースノートに記載するやり方があります。これなら、リリースノートをきちんと読んでくれる人はペイウォールのテストに協力してくれますし、それ以外の人はプレミアム機能のテストに集中できます。
また、TestFlightビルド にボタンやシークレットジェスチャーを仕込んで、アプリを無料状態に戻せるようにするのも効果的です。これにより、事情をよく理解したベータテスターは、この機能を使ってペイウォールを表示させ、本番環境でのユーザー体験を擬似的に体感することができます。
テスト手順
TestFlightでのテスト手順は、サンドボックス環境で行う手順と同じであるべきです。
さらに詳しく
- TestFlightでのアプリのテスト （Apple公式ドキュメント）
- App内課金のテスト （Apple公式ドキュメント）
- TestFlightでのベータテストの簡単な始め方 （Apple公式ドキュメント）
本番環境でのiOSテスト
まだApp Storeで公開されていないアプリの場合、アーリーバージョンを承認してもらうことで、サブスクリプションのテストを本番環境で行うのは非常に効果的です。リリース前でも本番環境でテストするためのいくつかの工夫はありますが、アプリがApp Storeで公開された後も、アップデートごとに本番環境での継続的なテストを行うことが重要です。
リリース前のテスト
- アプリのベータ版をApp Reviewに提出します。このとき、「バージョンのリリース」を「このバージョンを手動でリリースする」に設定しておくことで、アプリがApp Store上に公開されないようにします。
- アプリのプロモーションコードを生成します。これは、承認されていてもまだApp Storeで公開されていない無料アプリに対して可能 です。
- App Storeでプロモーションコードを使用してアプリをダウンロードします。
- サブスクリプションに登録します。
このアプリはすでに承認を通過しているため、サブスクリプションはApp Storeで公開された場合とまったく同じように動作します。つまり、テスターがサブスクリプションに登録すると実際に課金され、App Storeアプリ上でサブスクリプションの管理も可能です。テスターにプロモーションコードを提供すれば、無料でアプリを試すことができます。プロモコードによって支払われたサブスクリプションは、通常の有料サブスクリプションと同じように動作しますが、自動更新はされません。
もうひとつ注意点として、アプリがApp Storeで公開される前にプロモコードを使ってダウンロードされた場合、ダウンロードバンドル内に正しいレシートファイルが含まれていないことがあります。購入を行えばレシートは更新されますが、この挙動は、実際のユーザーがまれに正確なレシートを含まない状態に陥るケースのテストとして活用できるかもしれません。
新しいプロダクトの追加
自動更新と有効期限について
注意すべき点のひとつは、アプリ本体とアプリ内課金（プロダクト）がApp Storeに反映されるタイミングが必ずしも同じではないことです。この問題は、これまでにリリースされたことのあるプロダクトには影響せず、新しく追加されたプロダクトに限って発生するようです。新しいアプリやアプリのアップデート、あるいは新規プロダクトがApp Store上で購入可能になるまでに、24時間以上かかる場合があります。アプリやアップデートは先にApp Storeに表示されても、プロダクトの購入がすぐにはできない可能性があります。つまり、App Storeからプロダクション版のアプリをダウンロードできたとしても、まだ何も購入できないということが起こり得ます。アプリとプロダクトの承認後は、24時間以上待ってから再度テストを行ってください。
テスト手順
本番環境での自動更新や有効期限のテストは困難です。なぜなら、サブスクリプションの期間が短縮されないためです。たとえば、月額サブスクリプションの更新をテストするには1か月待つ必要があり、年額サブスクリプションの有効期限を確認するには1年間待たなければなりません。これは現実的ではないため、Appleはサンドボックス環境でサブスクリプション期間を短縮しています。サンドボックス環境で更新や有効期限の処理が正しく動作していれば、App Store上でも問題なく動作するはずです。
キャンセルのテスト手順
- 月額サブスクリプションに登録します。
- アプリがサブスクライブ状態になり、機能がアンロックされていることを確認します。
- App Storeアプリを開き、サブスクリプションをキャンセルします。
- Appleがキャンセル処理を支払いキューに追加するのに数分かかることがあるため、1～2分ほど待ちます。
- アプリを再度起動します。
この時点で、レシート上の自動更新は無効になっているはずです。アプリは現在の課金期間が終了するまではサブスクライブ状態を維持し、その後、未サブスクライブ状態に戻る必要があります。
返金処理
- 月額サブスクリプションに登録します。
- アプリがサブスクライブ状態となり、機能がアンロックされていることを確認します。
- Apple に連絡して返金をリクエストします。
- Apple が返金を処理し、支払いキューに追加するのを待つために、1日待ちます。
- アプリを再度起動します。
この時点で、返金イベントが支払いキューから読み取られ、アプリはサブスクライブ状態から非サブスクライブ状態へと切り替わるはずです。
購入の復元
理想的には、アプリが自動的にサブスクリプションの状態を判定し、それに応じて機能をロックまたはアンロックするようになっているはずです。しかし、期待通りに動作している場合でも、レシートを手動で更新する必要があることがあります。
- アプリにサブスクライブします。
- アプリを削除し、デバイスを再起動してから、アプリを再インストールします。
- アプリを起動します。
- 必要に応じて、「購入を復元」ボタンをタップします。
有効なサブスクリプションが見つかり、アプリはサブスクライブ状態に切り替わるはずです。
無料トライアルと初回オファー
無料トライアルは初回オファーの一種であるため、サブスクリプションアプリの開発者の多くは、自覚がない場合でもこの機能を利用しています。
ここで最も重要なのは、アプリが初回オファーの対象となるユーザーにのみオファーを表示するようにすることです。
ひとつ注意すべき点は、一度でもアカウントが初回オファーを利用すると、同じサブスクリプショングループ内の他の製品に対してもそのアカウントは初回オファーの対象外になるということです。つまり、無料トライアルをテストした場合、そのアカウントでは以後同じグループの製品で初回オファーが利用できなくなります（これをリセットする方法は現時点では存在せず、新しいサンドボックスアカウントを作成するしかありません）。
理想的には、アプリ側で初回オファーの対象可否をチェックし、ユーザーが対象でない場合には「無料トライアル」などのオファー関連の文言を非表示にするべきです。ただし、この処理を誤るとAppleからのリジェクト理由になることが多いため、「すべてのユーザーを対象とする」方向に倒すほうが、「すべてのユーザーを対象外とする」よりは安全といえます。
さらに詳しく
- Introductory Offers のテスト方法 （Apple公式ドキュメント）
- アプリでの初回オファーの実装方法 （Apple公式ドキュメント）
サブスクリプションオファーのテスト
iOSのSubscription Offerは、サブスクリプションが失効した後でないとサンドボックス環境では利用できません。これは、サンドボックス環境ではプロダクトの変更（アップグレードやダウングレード）が機能しないことに関連しています。一方で本番環境では、アクティブなサブスクライバーや一時的に離脱したサブスクライバーも、Subscription Offerを利用することが可能です。
Further reading
- アプリにサブスクリプションオファーを実装する （Apple公式ドキュメント）
- サブスクリプションオファーの設定 （Apple公式ドキュメント）
- サブスクリプションオファーのベストプラクティス （WWDC 2019）
- RevenueCatでiOSサブスクリプションオファーに署名する方法 （RevenueCatブログ）
QAチェックリスト
アプリ内サブスクリプションのテストにおいて、抜け漏れがないように、以下の便利なチェックリストをご活用ください。
開発者サンドボックス環境で：
- サブスクリプションの購入をテストする
- サブスクリプションの自動更新と有効期限切れをテストする
- サブスクリプションの期限切れ後に購入を復元できるかをテストする
- アクティブなサブスクリプション期間中に購入の復元が可能かをテストする
- 異なるデバイス間で購入を復元できるかをテストする
In TestFlight:
- サブスクリプションの購入をテストする
- サブスクリプションの自動更新と有効期限切れをテストする
- サブスクリプションの期限切れ後に購入を復元できるかをテストする
- アクティブなサブスクリプション期間中に購入の復元が可能かをテストする
- 異なるデバイス間で購入を復元できるかをテストする
本番環境で：
- リリース日前に購入できるかをテストする
- リリース日に購入できるかをテストする
- サブスクリプションのキャンセル処理をテストする
- 購入に対する返金処理をテストする
- 購入の復元が正しく行えるかをテストする
iOSテストに関する追加のヒント
私たちはこれまでに、iOSでのアプリ内サブスクリプションの実装とテストに関して多くの知見を得てきました。ここでは、その過程で蓄積してきたヒントやテクニックをいくつかご紹介します。
サブスクリプションのプロモコードを使用する
App Store Connect では、サブスクリプション用のプロモコードを発行することができます。ただし、利用する前にいくつか注意すべき点があります。
- プロモコードで付与されたサブスクリプションは自動更新されません。そのため、たとえば1か月間無料のプロモコードを配布した場合、ユーザーは1か月間は無料で利用できますが、その後サブスクリプションは終了し、通常のアプリ内課金フローを通じて再サブスクライブする必要があります。
- すでにサブスクリプションを利用しているユーザーに対して無料のプロモコードを提供すると、現在のサブスクリプションがキャンセルされ、自動更新のない無料の1か月間が提供されます。
- アプリ自体が有料の場合、まずアプリのダウンロード用に別途プロモコードを発行する必要があります。
- レシートにはプロモコードで購入されたことを示す情報は含まれていないため、プロモコードの使用を指標として明確に追跡することはできません。
サブスクリプションのオファーコードの利用
オファーコードは、サブスクリプション用のプロモコードとよく似た仕組みで機能しますが、プロモコードに伴う多くの注意点がないのが特徴です。さらに、オファーコードはアプリ内の支払い画面またはApp Store（ディープリンク経由）で引き換えることができます。唯一の注意点は、オファーコードはサンドボックス環境で完全にはテストできないことです。ただし、サンドボックス内でサブスクリプションの購入が正常に動作することを確認できれば、オファーコードも本番環境で正しく機能すると信頼して差し支えありません。
TestFlightの招待
TestFlightへの招待を送る際、ユーザーのApp Storeアカウントのメールアドレスを収集する必要はありません。任意のメールアドレス宛に招待を送ることができます。ユーザーがTestFlightの招待メール内の固有リンクをタップすると、そのリンクは、そのデバイスで現在ログインしているApp Storeアカウントに関連付けられます。今後のベータ版メールは引き続き、最初に招待を送ったメールアドレスに届きます。また、AppleがApp StoreアカウントのメールアドレスをあなたのTestFlightテスターリストに追加することはありません。
レシートの欠如について
App Storeからアプリをダウンロードすると、通常はアプリバンドル内にレシートが含まれているはずです。しかし、まれにそれが存在しない場合があります。一説によると、ユーザーがiTunesを使ってデバイスをバックアップおよび復元した際に、レシートがアプリと一緒に転送されないことが原因と考えられています（レシートの改ざんを防ぐ目的があると思われます）。
このようなケースでは、iOSが自動で新しいレシートをダウンロードしてくれそうなものですが、実際にはそうなりません。だからこそ、アプリバンドルにレシートが存在しないという例外的なケースを適切に処理し、購入の復元ボタンをわかりやすい場所に用意して、ユーザー自身がレシートを取得できるようにしておくことが重要です。
このようなケースで自動的に新しいレシートをダウンロードしようとするのは、一見よい考えのように思えるかもしれませんが、実際にはレシートのリフレッシュ時にシステムレベルでパスワード入力が求められ、多くのユーザーがそれをキャンセルしてしまいます。そのため、自動でレシートを取得しようとするのではなく、ユーザーが必要に応じて使用できる購入を復元ボタンを表示するようにしましょう。
新しいプロダクトの追加
アプリがサブスクリプション付きで公開された後は、App Store Connect を通じてアプリのアップデートなしで新しいプロダクトを追加・承認することができます。ただし、新しいプロダクトが承認された後、App Store 全体に反映されてユーザーが利用できるようになるまでに最大24時間かかることがある点に注意が必要です。そのため、新しいプロダクトオファーをリモートで有効化できるように、ペイウォールを設計しておくことが重要です。
このプロセスは、以下のような流れになります：
- あなたのアプリが App Store 上でmonthly_product_1を使って公開されている。
- App Store Connect で新しいmonthly_product_2を作成し、承認のために提出する。
- Apple がmonthly_product_2を承認する。
- 24時間待つ。
- リモート設定などを使って、アプリ内で表示するプロダクトをmonthly_product_2に切り替える。
サブスクリプションに関する開示事 項
かつて Apple は、ペイウォール画面上でさまざまな利用規約や条件を開示することをアプリに求めていましたが、現在はその要件が緩和されています。現在では、ペイウォール上に利用規約やプライバシーポリシーへのリンクを設置する必要すらありません（ただし、アプリ内のどこかには必ずリンクを設けておく必要があります）。
現在、アプリのペイウォール画面で必須とされているのは、以下の3つのみです：
- サブスクリプションの名称
- サブスクリプションの期間
- サブスクリプションの価格（該当する場合は単位あたりの価格も）
まとめ
この iOS サブスクリプションアプリ向けのテストガイドが、みなさんのお役に立てば幸いです。「ここが足りていない」と感じた点があれば、ぜひTwitter で教えていただくか、当社ウェブサイトからご連絡ください。
アプリ内サブスクリプションの実装やスケールでお困りの場合は、RevenueCat のオープンソース SDKをぜひご覧ください。サブスクリプションにまつわる面倒な部分をすべて処理してくれるので、アプリ開発そのものに集中することができます。