![[SwiftUI]StoreKitのテスト新機能](https://swiftui.quadkinghd.com/wp-content/uploads/2023/05/eye-catching-SwiftUIStoreKitのテスト新機能.png)
アプリ内課金とサブスクリプションをテストするのに役立つ最新のツールを見つけてください。
iPhoneアプリを開発して、世の中にリリースする為には、十分なテストを行う必要があります。では、どのようにしたらiPhoneアプリの評価、デバッグができるのか、WWDCで紹介されている方法を学んでいきましょう。
App Store ConnectからXcodeのStoreKitテストに製品を持ち込む方法、トランザクションマネージャーの改善について学び、Xcodeプレビューでアプリ内購入フローを探索する方法を紹介します。また、サンドボックス環境用のApple IDを設定する際のベストプラクティスを紹介し、払い戻しリクエスト、値上げ同意、請求再試行などのテストを作成する方法を紹介します。
♪ ♪グレッグ：こんにちは、私はグレッグです。StoreKitテストの新機能へようこそ。
このセッションでは、ピーターと私は、StoreKitでアプリ内購入をテストするために利用可能ないくつかの素晴らしい新機能を強調します。
Xcode 14を使用してアプリ内購入テストを合理化する方法のいくつかを見てみましょう。
次に、アプリ内サブスクリプションの実装でさらに多くのコーナーケースをカバーするために利用できるいくつかの新しい機能を見ていきます。
そして最後に、ピーターはサンドボックステスト環境の新しい機能強化を紹介します。
私たちは、ドーナツを販売するフードトラックオペレーターに強力な機能を提供するアプリであるフードトラックと協力します。
私はすでにStoreKitと統合して、フードトラックの販売履歴機能のフルバージョンと、ソーシャルフィードサービスの拡張バージョンのサブスクリプションを提供しています。
セッションを通して、XcodeでStoreKitテストを使用して、アプリのアプリ内購入機能をテストします。
WWDC 2020では、XcodeでStoreKitテストを導入し、Xcodeで直接アプリ内購入のテストを開始できます。
今年は、Xcode 14で、StoreKitアプリのテストライフサイクルに関するいくつかのアップデートを共有できることを嬉しく思います。
以前と同様に、XcodeでStoreKit構成ファイルを作成し、App Store Connectでアプリを設定せずにアプリ内購入の実装のテストを開始できます。
App Store Connectでアプリを設定する準備ができたら、Xcode 14にまったく新しい機能を導入し、XcodeのStoreKit TestingでApp Store Connectに入力したのと同じアプリ内購入製品を使用できるようにします。
すでにストアにアプリがある場合は、StoreKit構成ファイルを最初から設定することなく、今すぐXcodeでStoreKitテストを使用開始できます。
この便利な機能を使用すると、アプリ内購入を一度設定し、Xcodeでローカルで、ユニットテスト内、サンドボックス環境で、リリースの準備ができたら、App Storeで同じ設定を使用できます。
App Store Connectで製品をXcodeと簡単に同期できます。
まず、このソーシャルフィード+サブスクリプションのように、App Store Connectで製品を設定します。
次に、Xcodeで同期された設定ファイルを作成し、製品データをXcodeにロードします。
米国の英語タイトルを更新するなど、変更を加えたい場合は、App Store Connectで変更を加え、Xcodeで設定を再度同期できます。
同期した設定をローカルの編集可能なファイルに変換して、その場で変更を加えることもできます。
同期された構成をローカル構成に変換することは一方向操作であり、再度同期するには、新しい構成ファイルを作成する必要があります。
フードトラックアプリが提供するソーシャルフィードサービスの拡張バージョンであるソーシャルフィード+のサブスクリプショングループを設定することからすでに始めました。
Xcodeに飛び込んで、XcodeのStoreKitテストでこれらの製品を使用する方法を見てみましょう。
私はMacでフードトラックプロジェクトを開いています。
開始するには、ファイルメニューに移動し、新しいファイルを作成し、StoreKitでフィルタリングし、[次へ]をクリックして、新しいStoreKit構成ファイルを作成します。
Xcode 14では、新しい設定ファイルを作成すると、App Store Connectのアプリとファイルを同期させるためのチェックボックスが表示されます。
ローカルファイルを作成するには、名前を入力し、ボックスのチェックを外したままにします。
同期を設定するには、チェックボックスをオンにして、正しいチームとアプリが選択されていることを確認するだけです。
必要に応じて、ピッカーメニューを使用して別のチームとアプリを選択できます。
「次へ」をクリックし、ファイルを保存する場所を選択します。
ファイルを保存するとすぐに、アプリ内購入メタデータがApp Store Connectから同期を開始します。
データがダウンロードされている間、私たちはアプリで作業を続け、アクティビティバーでその進捗状況を追跡することができます。
同期が終了すると、このファイルが一般的なStoreKit構成ファイルとは異なるように見えることに気付くでしょう。
これは、同期されたファイルが読み取り専用状態だからです。
Xcodeのすべてのデータを一目で確認できますが、変更を加えるにはApp Store Connectを開く必要があります。
私はSafariでソーシャルフィード+の月間製品を持っています。
製品を年間計画と区別するために接尾辞を追加して、この製品の英語タイトルを更新しましょう。
これが更新されたので、保存してXcodeに戻りましょう。
この変更を設定ファイルに反映させるには、左下隅にあるこの同期ボタンを押すだけです。
同期が完了すると、変更がXcodeに反映されていることがわかります。
同期されたファイルは読み取り専用ですが、データをローカルファイルにコピーして、Xcode内ですばやく変更を加えることができます。
設定ファイルからアイテムをコピーするだけでなく、同期したファイル全体をローカルの編集可能なファイルに変換することもできます。
同期したファイルを開き、エディタメニューに移動し、「ローカルストアキット構成に変換」をクリックするだけです。
ファイルを変換した後、この操作を元に戻すことはできないことを覚えておいてください。アプリと再度同期するには、新しいStoreKit設定ファイルを作成する必要があります。このファイルをApp Store Connectと同期させたいので、このアラートをキャンセルしましょう。
ファイルを同期したので、テスト環境を設定しましょう。
はじめに、スキームエディタを開きます。 実行アクションを選択し、オプションを選択します。 オプションでは、ピッカーメニューから異なるStoreKit環境を切り替えることができます。「なし」を選択するとサンドボックスに接続し、「フードトラック」を選択するとXcode環境に接続します。
現在のテストニーズに応じて環境を切り替えるのは簡単で、両方の環境はまったく同じ製品とサブスクリプションのメタデータを使用します。
とりあえず、同期した設定ファイルを選びましょう。
XcodeでStoreKitを設定したので、テストに行きましょう。
SwiftUIアプリを使用しているため、Xcodeでサブスクリプションストアをプレビューできます。 Xcode 14以降、StoreKit設定ファイルの製品がSwiftUIプレビューに直接読み込まれます。
これにより、実際のアプリ内購入データを使用して、見栄えの良いストアユーザーインターフェイスの構築とテストが非常に簡単になります。当社の製品のサブタイトルを含めることで、製品オプションに詳細を追加してみましょう。
製品のローカライズされた説明を含むテキストビューを追加するだけです。 そして、App Store Connectで設定した説明で、すぐにプレビューアップデートを見てください。これは今よりずっと良くなっていると思います。 UIの状態が良くなったので、iPhoneでアプリを実行して、機能テストを始めましょう。
Xcode 14では、StoreKitトランザクションマネージャーにいくつかの強力な新しいツールがあります。アプリを実行している状態で、デバッグバーの購入アイコンを押すことでトランザクションマネージャーを開くことができます。
右側には、トランザクションに関するすべての内部の詳細を視覚化できる新しいトランザクションインスペクタがあります。このツールは、アプリ内トランザクションの状態を理解するのに役立ちます。たとえば、このソーシャルフィード+のサブスクリプションの有効期限が切れた日付と、今後の更新に関する情報を確認できます。また、製品、サブスクリプショングループ、またはサブスクリプションオファーの設定ファイルにジャンプすることもできます。このサブスクリプショングループの横にあるジャンプボタンをクリックするだけです。
そして、設定ファイルでソーシャルフィード+に直接持ち込まれます。 この検査官は、より高度なテストケースを検討する際に、セッションの後半で私たちを助けてくれます。 また、今すぐトランザクションをフィルタリングすることもできます。これは、これらすべてのソーシャルフィード+更新でトランザクションのリストをナビゲートするのに本当に便利です。
私たちのアプリでは、年間販売履歴機能にアクセスできることに気付くでしょう。 これらのサブスクリプションの更新がすべてあるため、どのトランザクションにこの機能を受ける権利があるかを知るのが難しくなります。
IDの入力を開始することで、製品のトランザクションを簡単に見つけることができます。 そして、オートコンプリートメニューから製品IDフィルターを選択します。 購入日で絞り込むこともできるので、今行っている購入だけに集中できます。
ソーシャルフィード+のサブスクリプションの有効期限が切れているので、アプリに入ってもう一度購読しましょう。 サブスクリプションを確認したので、新しいトランザクションだけが表示されます。 App Store Connectから製品とサブスクリプションを同期し、SwiftUIプレビューでStoreKit構成を使用し、トランザクションマネージャーの新しいツールを活用することで、Xcodeでのアプリ内購入テストを強化するいくつかの方法を検討しました。
次に、Xcodeの新機能を使用して高度なサブスクリプションケースをカバーすることで、Food Truckのアプリ内購入機能のテストを続けます。まず、フードトラックでの購入の払い戻しをリクエストできるように、払い戻しリクエストのテストを見ていきます。
次に、オファーコードをテストし、ソーシャルフィード+の加入者にプロモーションを提供し、フードトラックのユーザーインターフェイスで価格上昇の処理を検討し、最後に、請求の再試行と猶予期間をサポートすることで、ソーシャルフィード+の非自発的な解約を減らします。払い戻しリクエストのテストを開始するには、アプリでこのサポートビューに移動し、払い戻しする最近のトランザクションを選択できます。
これのコードは簡単です。ビューにrefundRequestSheetビュー修飾子を追加し、払い戻しボタンを押すと、isPresented Bindingをtrueに反転します。さて、これを実際に見てみましょう。
バインディングがtrueの場合、払い戻しリクエストシートがビューの上に表示されます。
Xcode環境でテストする場合、選択した問題は、StoreKit APIのRevocationReasonと1対1に対応します。「開発者の問題」を選択し、「返金をリクエスト」を押しましょう。
App Storeでは、払い戻しリクエストの処理には時間がかかりますが、XcodeまたはSandboxでテストすると、払い戻しリクエストはすぐに取引を返金します。
トランザクションマネージャーでは、この更新されたトランザクションの検査官を見て、選択したばかりの失効理由と失効日を確認できます。トランザクションマネージャーの払い戻しボタンをクリックするだけで、払い戻しをテストすることもできます。
払い戻しリクエストAPIは、フードトラックを使用する人々に優れたカスタマーサポートを提供するのに役立ちます。Xcodeで払い戻しリクエストをテストする方法を見て、StoreKitを使用して払い戻しされた取引を処理する方法をいくつか見てみましょう。
トランザクションを返金した後、更新されたトランザクション値はTransaction.updatesシーケンスから発行されます。revocationDateとrevocationReasonプロパティを使用して、これらの返金されたトランザクションを検出できます。
Xcodeの払い戻しリクエストシートで対応するオプションを選択することで、2つの失効理由のケースを簡単にテストできます。それが、Xcodeで払い戻しリクエストシートをテストする方法です。これは、Xcode環境またはサンドボックスのいずれかを使用する場合、iOSとmacOSで動作します。Xcodeでテストするには、iOSまたはiPadOS 15.2以降を実行するためにiPhoneまたはiPadが必要です。MacのXcodeでテストするには、macOS 12.1以降が必要です。
では、サブスクリプションオファーコードのテストを見てみましょう。このためには、ローカルのStoreKit設定ファイルを使用します。コードの新しいオファーを行うには、サブスクリプションを選択し、オファーコード表の下にある「+」を押します。その後、オファーを設定できます。これを「無料月」と名付け、1か月間無料オファーにします。
App Store Connectと同様に、対象となる顧客を選択し、入門オファーをこのオファーで引き換えることができるかどうかを選択します。とりあえずデフォルト設定はそのままにしておきましょう。コードが設定されたので、「完了」を押します。もちろん、App Store Connectと同期している場合、設定されたオファーはこの表に自動的に表示されます。
オファーが設定されたので、アプリのストアビューに移動しましょう。サブスクリプションオファーを引き換えるために、ビューの下部にこのボタンを追加しました。Xcodeでストアビューの実装を開くと、オファーコードを実装するのは、ビューにofferCodeRedemption修飾子を追加し、誰かがボタンをタップしたときにisPresented Bindingをtrueに反転させるのと同じくらい簡単です。
これがどのように機能するか見てみましょう。 ボタンを押すと、引き換えシートがアプリの上に表示されます。App Storeでは、App Store Connectで生成したオファーコードを入力できますが、Xcodeではテスト体験がはるかに合理化されます。設定ファイルには、ロック解除されたサブスクリプションでグループ化されたコードのすべてのオファーのリストがあります。引き換えるには、作成したばかりのオファーをタップし、引き換えボタンを押しましょう。支払いシートが表示され、
入門オファーに行くと、支払いの直後にコードのオファーが開始されることがわかります。 購読後、確認画面が表示され、シートを閉じて、アプリがソーシャルフィード+へのアクセスのロックを解除することを確認できます。
この新しい取引の検査官を見ると、導入オファーが現在適用されていることがわかります。オファーは有料なので、更新セクションでは、入門オファーのさらに2つの更新を取得することを示しています。その後、私たちが引き換えたばかりの無料の月コード。その後、標準サブスクリプションは無期限に更新されます。
検査官は、複数のオファーのような複雑なシナリオであっても、サブスクリプションの状態で何が起こっているのかを非常に明確にします。ローカルのStoreKit構成でオファーコードを構成する方法と、iPhoneで引き換えをテストする方法を見ました。オファーコードは、将来および既存の加入者に柔軟なプロモーションを提供する素晴らしい方法であり、フードトラックでオファーコードを使い始めるのがこれまで以上に簡単になりました。
では、StoreKitを使用してこれらのオファーを処理する方法を見てみましょう。コードを引き換えた後、Transaction.updatesとStatus.updatesの両方のシーケンスが新しい値を出力します。トランザクション値のofferTypeプロパティをチェックして、現在のトランザクションに適用されるオファーがあるかどうかを確認できます。サブスクライバーがコードのオファーで入門オファーを引き換えることを許可したため、offerTypeの価値が導入式になります。
renewalInfo値では、offerTypeプロパティをチェックして、次の更新でどのようなオファーが存在するかを確認できます。先ほど見たケースでは、ペイ・ア・ア・ゴー・オファーを使用したため、初期値が導入されることが期待できます。
2つのサブスクリプション期間の後、コードオファーが積み重ねられているため、値がコードに切り替わります。offerTypeがコードの場合、offerIDプロパティを使用して、コードに適用されたオファーの参照名を取得できます。それが、Xcodeでコードのオファーをテストする方法です。Xcode 13.3からコードのオファーを設定し、iOS 15.4以降を実行しているiPhoneとiPadでテストできます。フードトラックでコードが機能するオファーを確認したので、アプリがソーシャルフィード+の値上げをどのように処理するかをテストしましょう。
Xcodeでは、値上げのテストは本当に簡単です。まずは、毎月のソーシャルフィードサブスクリプションの価格を引き上げます。 このステップはオプションです。価格を同じままにして、値上げをシミュレートすることができます。トランザクションマネージャーに戻ると、サブスクリプションの最新のトランザクションを選択し、ツールバーの「Request Price Increase Consent」を押すだけです。
トランザクションマネージャーでは、取引が「値上げ保留中」状態になっていることがわかります。デバイスを見ると、アプリの上に表示され、値上げへの同意を求めるシートが表示されます。このシートはコードを追加せずに単独で表示されますが、新しいメッセージAPIを利用して動作をカスタマイズしました。 コード内のメッセージAPIとどのように統合したかを見てみましょう。
ここにメッセージシーケンスを反復するforループがあり、値上げなどのメッセージが表示された場合は、ドーナツエディタのような敏感なビューが表示されていないことを確認してください。それ以外の場合は、DisplayMessageActionを使用してメッセージを表示します。
ドーナツエディタが表示されたら、メッセージの値を保持し、ドーナツの編集が完了した後に表示します。 テストに戻りましょう。 App Storeでは、既存の加入者は、値上げをキャンセルまたは同意する決定を下すまで、異なる時間に複数の値上げメッセージを受け取ることがあります。Xcodeでは、これらのメッセージがいつ届くかを完全に制御できます。トランザクションマネージャーのボタンを押すたびに、トランザクションがすでに値上げ状態であっても、再びメッセージが表示されます。これで、延期ロジックが実際に機能するかどうかをテストできます。だから私はドーナツエディタを開きます… そして、シートをもう一度開くようにメッセージを送ってください。
シートはまだ表示されませんが、ドーナツエディタを離れると、シートは期待どおりに表示されます。値上げを受け入れるか、シートでサブスクリプションをキャンセルすることができますが、実際には、ユーザーは電子メールなどの外部ソースを介して値上げに応答する可能性があります。これをシミュレートするには、トランザクションマネージャーの承認ボタンと拒否ボタンを使用できます。
ドーナツ編集の経験はとても素晴らしかったので、トランザクションマネージャーで承認を押すことで新しい価格に同意します。XcodeでStoreKitを使用すると、値上げのような複雑なコーナーケースのテストが非常にスムーズになります。値上げをシミュレートする方法を見て、StoreKitを使用してアプリの値上げを処理する方法を見てみましょう。
価格上昇ステータスをテストする場合、ステータス更新シーケンスは状態が変わるたびに新しい値を出力します。RenewalInfo値のpriceIncreaseStatusプロパティをチェックすることで、アプリでこれらの更新を検出できます。お客様が値上げのためにサブスクリプションをキャンセルした場合、expirthReasonプロパティでdidNotConsentToPriceIncreaseをチェックすることで、これを検出できます。また、テスト価格の上昇に関する単体テストを書くこともできます。
まず、ダイアログを無効にすると、アプリの上に値上げUIを実際に表示せずにテストできます。サブスクリプションを購入した後、requestPriceIncreaseConsentForTransaction APIを使用してプロセスを開始し、サブスクリプションの最新のトランザクションのIDを渡すことができます。テストトランザクションが値上げを保留していることを確認するために、isPendingPriceIncreaseConsentプロパティを確認します。
最後に、テストしているものに応じて、同意ToPriceIncreaseForTransactionまたは declinePriceIncreaseForTransactionを呼び出すと呼んで、アプリが終了した値上げケースにどのように反応するかを確認できます。価格の上昇をテストするのはそれだけです。値上げは、すべてのプラットフォームでXcode 13.3でテスト可能です。値上げメッセージは、iOS 15.4以降でのみテスト可能であることに注意してください。
最後に、サブスクリプション請求の再試行と猶予期間を見てみましょう。請求の再試行は、期限切れのクレジットカードなど、サブスクリプションを更新しようとしたときにエラーが発生した状態です。App Storeでは、請求再試行中に、App Storeは問題の修正とサブスクリプションの回復を試みます。オプションで猶予期間を有効にすることができます。
これにより、請求再試行状態の開始時に、期間限定でサブスクリプションを使用し続けることができます。Xcodeでテストするときにこれをシミュレートする方法を実演しましょう。サブスクリプション更新の請求問題をシミュレートするために、テストしているStoreKit構成の「エディタ」メニューを開き、「更新時に請求再試行」を有効にします。
フードトラックに請求猶予期間をサポートしてもらいたいので、メニューでも「請求猶予期間」を有効にしましょう。 サブスクリプションレートもスピードアップするので、状態がどのように変化するかを見ることができます。
まず、ソーシャルフィード+を購読しましょう。 さあ、更新の時期になるのを待ちましょう。 トランザクションの有効期限が切れたら、最初に請求猶予期間の状態に入ることに注意してください。トランザクションインスペクタを見て、各州が終了する時間を確認できます。 請求猶予期間が満了したばかりで、現在は標準の請求再試行状態です。いつでも「トランザクションの問題を解決する」ボタンを使用して、請求エラーの修正をシミュレートできます。問題の解決をテストしましょう。 問題が解決したので、新しい取引が取得されます。
「更新時の請求再試行」が有効になっている限り、新しいトランザクションごとに請求再試行が引き続き入力されるため、このテストを何度でも繰り返すことができます。請求の再試行と猶予期間を適切に処理することは、不本意な解約を減らすことによって加入者を維持するための鍵です。Xcodeでこれらの状態をシミュレートするのがどれほど簡単かを見たので、StoreKitを使用してそれらを処理する方法を見ていきます。
請求の再試行と猶予期間の状態が変更されると、ステータス更新シーケンスは新しい値を出力します。フードトラックでは請求猶予期間を提供しているため、猶予期間中に加入者にソーシャルフィード+へのアクセスを許可する必要があります。
更新情報の gracePeriodExpirationDateプロパティを使用して、加入者の猶予期間がどれくらいの期間になるかを確認できます。請求の再試行を確認するには、isInBillingRetryを確認するだけです。 また、ステータスの州のプロパティを使用して、これらの状態のいずれかを簡単に検出することもできます。
お客様がこれらのいずれかの州にいる場合は、App Storeへのディープリンクに誘導して請求の問題を解決できます。現在のエンタイトルメントAPIを使用している場合は、猶予期間中に期限切れのサブスクリプションのトランザクションを受け取ります。
また、BillingGracePeriodIsEnabledを設定し、StoreKitテストセッションでshouldEnterBillingRetryOnRenewalを設定することで、ユニットテストで請求の再試行と猶予期間を制御することもできます。アプリがサブスクリプションに通知した後、請求の再試行を入力すると、テストトランザクションのhasPurchaseIssueプロパティは真になります。
さまざまなステータスの更新を待ち、期待どおりにアプリの更新を主張した後、トランザクション方法の問題解決を使用して、サブスクリプションを回復するApp Storeをシミュレートすることができます。請求の再試行と猶予期間は、すべてのプラットフォームでXcode 13.3以降でテスト可能です。
セッションの後半で、ピーターはiOSとiPadOS 16のサンドボックスでこれらの状態をテストする方法について詳しく説明します。 払い戻しのリクエストから請求の再試行と猶予期間の処理まで、高度なテストケースをカバーしました。
これらのケースのいくつかをサポートするために新しいStoreKit APIを使用する方法の詳細については、「アプリ内購入の新機能」をご覧ください。これは、今年のXcodeでのStoreKitテストの新機能の簡単な概要でしたが、すべてをカバーしたわけではありません。
新しいサブスクリプション更新率があり、XcodeでStoreKit 2のアプリ内管理サブスクリプションシートをテストしたり、StoreKitTestを使用してSKAdNetwork実装の単体テストを書いたりできます。詳細については、「SKAdNetworkの新機能」をご覧ください。
今、ピーターは今年のサンドボックステスト環境の新機能を説明します。ピーター:ありがとう、グレッグ。こんにちは、私はApp Storeサーバーエンジニアのピーターです。XcodeのStoreKitテストの新機能が、より複雑なアプリ内購入の実装をテストするのにどのように役立つかを見ました。
私たちは常にあなたのフィードバックに耳を傾けており、多くの人がアプリ内購入とサーバーの実装をテストするためにApp Storeサンドボックス環境に依存していることを知っています。オンラインテスト環境でアプリとサーバーをより簡単にテストできるように、サンドボックスで行っている新しい機能強化を共有できることを嬉しく思います。
Sandbox Apple IDの作成、App Store Connect API、請求失敗シミュレーションの機能強化を導入します。サンドボックス環境を使用するには、まずApp Store ConnectでサンドボックスApple IDを設定する必要があります。 サンドボックステスターリストをユーザーとアクセスページのナビゲーションバーに移動したことに気付くでしょう。
ここでは、プラスボタンで新しいテスターを作成できます。新しいテスターウィンドウからいくつかのフィールドを削除して、作成プロセスを合理化しました。現在、最小限の情報のみを求めているので、不要な情報なしでアカウントの作成を進めることができます。メールアドレスに「プラス記号」を使用することもできるので、テスターごとに新しいメールアドレスを作成する必要はありません。
強力なパスワードの作成は面倒なことがわかっており、これも簡単にしました。また、パスワードをより安全にするためのインラインの提案も追加しました。 合理化されたApple ID作成フォームと、より良いパスワードの複雑さのヒントにより、アカウントの設定に費やす時間を減らし、アプリの開発により多くの時間を費やしていただければ幸いです。
App Store Connectは、サンドボックスのApple IDを作成して管理し、アプリのコンテンツと組織を管理する中心的な場所です。ここ数年、サンドボックスアカウントの地域の変更や購入履歴の清算など、あなたが求めていた機能をサンドボックスに追加してきました。
これらの機能の多くは、App Store ConnectまたはSandbox Manage Subscriptionsページのデバイス上でアクセスできます。今年後半には、サンドボックスApple IDのリストの照会、購入履歴の消去、中断された購入状態の設定など、これらのサンドボックス機能のいくつかをApp Store Connect APIに導入します。
これにより、サンドボックスアカウントでのテストが高速化され、一般的に使用されるテストツールの自動化クライアントのセットアップに役立ちます。最後に、サンドボックスでの請求失敗シミュレーションのサポートを発表できることを嬉しく思います。
2018年には、不本意な解約を減らすために、自動更新サブスクリプションの請求再試行と猶予期間を発表しました。2019年の開始以来、請求猶予期間により、顧客への3億日間の有料サービスを回収することができました。これにより、ビジネスの収益が増加し、顧客はサービスの中断を経験しません。多くの人がすでに本番環境で請求失敗のケースを処理していますが、Sandboxでより多くのテストシナリオを提供したいので、アプリがApp Storeで公開される前に請求失敗をテストして処理できます。
新しいサンドボックスアカウント設定ページを使用して、アカウントの請求失敗シミュレーションを有効にし、アプリのコンテキストでフォアグラウンドおよびバックグラウンドサブスクリプションの失敗をテストし、サンドボックスのverifyReceipt、App Store Server API、およびApp Store Server Notifications V2でサブスクリプションステータスを確認できます。
請求の再試行と不本意な解約の削減の詳細については、2018年のWWDCセッション「エンジニアリングサブスクリプション」をお勧めします。今年は、アプリ内購入の失敗をシミュレートするために、新しいサンドボックスアカウント設定にスイッチを導入します。これは、サンドボックスのサブスクリプションページの新しいホームでもあります。
請求失敗シミュレーションを有効にすると、フォアグラウンドのアプリ内購入は失敗します。この動作は、顧客の支払い方法が拒否されたときの動作と一致します。また、請求失敗シミュレーションは、自動更新サブスクリプションの状態が本番環境での請求失敗の状態と一致することを保証します。
これは、請求の問題を抱えている顧客のためにアプリ内メッセージをテストできることを意味します。これらのサブスクリプションの状態は、アプリ内購入の領収書に反映され、V2通知で確認されます。サブスクリプションのライフサイクルを確認しましょう。
サンドボックスで自動更新サブスクリプションを購入すると、SUBSCRIBEDやDID_RENEWなどのV2通知がすでに届きます。アクティブなサブスクリプションを持つアカウントのアプリ内購入試行のテストに失敗すると、次の更新は請求再試行状態になります。
これで、DID_FAIL_TO_RENEWのような請求再試行通知がサンドボックスで届きます。サブスクリプションの更新を回復しようとするのを停止する前に請求失敗シミュレーションを無効にすると、次の更新試行が成功し、サブタイプのBILLING_RECOVERYを含むDID_RENEW通知が届きます。再試行の制限に達し、請求失敗シミュレーションが有効になっている場合、サブスクリプションは期限切れになり、サブタイプBILLING_RETRYでEXPIREDを受け取ります。
すでに本番環境で猶予期間を使用し、サンドボックスでV2通知を使用している場合は、GRACE_PERIODサブタイプでDID_FAIL_TO_RENEW通知を受け取ることが期待できます。以下は、猶予期間付きの請求再試行状態のサブスクリプションの例です。
猶予期間の終了時に請求失敗シミュレーションがまだ有効になっている場合は、GRACE_PERIODのサブタイプとGRACE_PERIOD_PERIODのDID_FAIL_TO_RENEW通知が届きます。
App Store Server APIでサブスクリプション情報を確認する場合、signedRenewalInfoのペイロードをデコードすることで、サブスクリプションの状態を確認できます。ここでは、expirthIntentフィールドと請求再試行フィールドが入力されています。
請求再試行状態のサブスクリプションの領収書で/verifyReceiptを呼び出すと、is_in_billing_retry_periodフラグが1に設定されていることがわかります。また、猶予期間を使用する場合、猶予期間の有効期限フィールドが入力されることを期待できるようになりました。
サンドボックスでの請求失敗のテストが完了したら、サンドボックスアカウント設定でスイッチを無効にすることができます。この新しいテスト可能性が、お客様に可能な限り最高の体験を提供するのに役立つことを願っています。今日は、アプリのアプリ内購入機能のテストを合理化するために使用できるいくつかの新しいテスト機能について説明しました。
App Store Connectの構成をXcodeと同期することで、ローカルまたはサンドボックス環境でテストするときに、同じアプリ内購入構成を使用できます。Xcodeでのオファーコードや払い戻しテストなどの新機能は、複雑なStoreKitの実装を検証するのに役立ちます。
また、サブスクリプション管理のテスト可能性により、サービスが中断された場合でも、優れた顧客体験を確保するためにアプリを進化させることができます。
請求の失敗がサブスクリプションの領収書にどのように影響するか、さらにサンドボックスのApp Store Server Notifications V2の詳細については、WWDC 21セッション「サーバーでアプリ内購入を管理する」をお勧めします。
また、App Store Server APIとV2通知の新機能については、「アプリ内購入の新機能」をご覧ください。これらの新機能についてのご意見をお待ちしております。ご参加いただきありがとうございます。
コメント