StoreKitテストの最新情報

StoreKitテストの最新情報

App内課金やサブスクリプションのテストに役立つ最新ツールをご確認ください。ご利用のプロダクトをApp Store ConnectからXcodeのStoreKitテストに取り込む方法、トランザクションマネージャの改善点、XcodeプレビューのApp内課金フローについて解説します。また、サンドボックス環境用のApple IDを設定する際のベストプラクティスをはじめ、返金リクエスト、値上げへの同意、請求のリトライなどのテストを作成する方法も紹介します。

リソース
関連ビデオ

WWDC23
WWDC22
- App内課金の最新情報
- SKAdNetworkの最新情報
WWDC21
- サーバにおけるApp内課金の管理
- StoreKit 2について
WWDC20
- StoreKit Testing in Xcodeの導入
ダウンロード

♪ ♪ こんにちは Gregです「StoreKitテストの最新情報」へようこそこの回では Peterと StoreKitのApp内課金をテストすることに関連する新機能を紹介しますまずはXcode 14を使って App内課金のテストを効率化する方法をいくつか紹介します次に App内課金の実装でコーナーケースを含み利用できる全く新しい機能を紹介します最後に Peterはサンドボックスのテスト環境に関する新しい拡張を紹介します Food Truckに取り組んでいますドーナツ販売トラック事業者に機能を提供するAppですすでにStoreKitと統合し Appの販売履歴機能の完全版とソーシャルフィードサービスの拡張機能のためのサブスクリプションを提供していますこのセッションを通して Xcodeの StoreKit Testingを使い App内課金機能をテストしていきます WWDC 2020では Xcodeで StoreKit Testingを導入し直接App内課金のテスト開始を可能にしました今年はXcode 14で StoreKit Appのテストライフサイクル関連のアップデートを紹介します変わらず XcodeでStoreKit 設定ファイルを作成し App Store Connectで Appを設定することなく App内課金の実装テストを開始することが可能です App Store Connectで App設定の準備ができたら Xcode 14で全く新しい機能を導入し App Store Connectで入力したのと同じApp内課金プロダクトを XcodeのStoreKit Testing で使用できるようにしますすでにストア上に Appがある場合は StoreKit設定ファイルを一から設定せずに Xcode上ですぐに使い始めることができますこの便利な機能により App内課金を一度設定し Xcode ユニットテスト内サンドボックス環境リリースの準備ができたときには App Storeで同じ設定をローカルに使用することができます XcodeでApp Store Connect のプロダクトを簡単に同期できますまずこのSocial Feed+のサブスクリプションのように App Store Connectでプロダクトを設定しますそして Xcodeにプロダクトデータを読み込むための同期設定ファイルを作成しますもし英語タイトルの更新など変更を加えたい場合は App Store Connectで変更を行い再度Xcodeで設定を同期させることができます同期した設定をローカルで編集可能なファイルに変換しその場で変更することも可能です同期した設定のローカルへの変換は一方的な操作で再度同期するには新しいファイルを作成する必要がありますすでに Food Truck Appの Social Feedの拡張版 Social Feed+の登録グループの設定を始めています早速 Xcodeの StoreKit Testingでこれらの使用方法を見てみましょう MacでFood Truckのプロジェクトを開いています始めに StoreKitの新規設定ファイルを作りますファイルメニューから新規ファイルを作成 StoreKitでフィルタをかけ次へをクリックします
Xcode 14では新規設定ファイルを作るとチェックボックスが表示され App Store Connectで Appと同期させることができますローカルファイルの場合はチェックを外します同期を設定するにはチェックを入れ正しいチームとAppの選択を確認するだけですピッカーメニューで別のチームや Appの選択も可能です次へをクリックしファイルを保存する場所を選択しますファイルを保存すると同時に App内購入のメタデータがApp Store Connectから同期を始めますデータのダウンロード中は Appの作業を続けアクティビティバーで進捗を確認できます同期が終わると通常の StoreKit設定ファイルとは違う見た目に気づくでしょう同期されたファイルが読み取り専用状態だからです Xcodeで全てのデータを見ることができますが変更にはApp Store Connect を開く必要があります
SafariにSocial Feed+の月額プロダクトがありますこのプロダクトの英語タイトルを更新し年間プランと区別しやすくするために接尾辞を追加してみます
これで更新されたので保存して Xcodeに戻ります
この変更を設定ファイルに反映させるためには左下にあるこの同期ボタンを押すだけです
同期が完了すると Xcodeで変更の反映を確認できます
同期されたファイルは読み取り専用ですが Xcodeの中で素早く変更するためローカルファイルにデータコピーができます
設定ファイルから項目をコピーするだけでなく同期ファイル全体をローカルで編集可能に変換もできますあとは同期したファイルを開きエディタメニューから「ローカルのStoreKit設定に変換」をクリックするだけです
変換後に取り消すことはできないので注意しましょう再度同期するには StoreKit 設定ファイルを新しく作成する必要ですこれはApp Store Connectと同期しておきたいのでこのアラートはキャンセルしましょうファイルの同期が完了したのでテスト環境を設定してみましょうまず始めにスキーマエディタを開きます
ランアクションを選択しオプションを選択します
オプションではStoreKitの環境をピッカーメニューから切り替えることができます「なし」を選ぶとSandboxに「Food Truck」を選ぶと Xcode環境に接続されます現在のテストニーズに応じて簡単に環境を切り替えることができどの環境でも同じプロダクトとサブスクリプションのメタデータを使用できます同期した設定ファイルを選んでみましょう
XcodeにStoreKitを設定完了しテストします SwiftUI Appを使用しているため Xcodeでサブスクリプションストアを直接プレビューできます
Xcode 14から設定ファイルのプロダクトがそのまま SwiftUIプレビューに読み込まれます実際のApp内課金データでユーザインターフェースを簡単に構築しテストができますプロダクトオプションにサブタイトルを入れてプロダクトの詳細を追加してみましょうローカライズされた説明文のテキストビューを追加します
App Store Connectで設定した説明文を使ってすぐにプレビューのアップデートを見ることができますだいぶ良くなったと思います
UIが良くなったので iPhoneで Appを起動し機能テストを始めてみましょう
Xcode14では StoreKit Transaction Managerに強力な新しいツールがあります Appを起動しデバッグバーにある購入アイコンを押すとトランザクションマネージャを開くことができます
右側には新しいトランザクションインスペクタがありトランザクションの裏側の詳細をすべて視覚化することができますこのツールは App内トランザクションの状態を把握するのに有効です例えば Social Feed+のサブスクリプション期間が終了した日や今後の更新情報を確認できますまたプロダクトサブスクリプショングループサブスクリプションオファー設定ファイルに飛ぶことができますサブスクリプショングループ横のジャンプボタンをクリックするのです
設定ファイルの Social Feed+に行きます
このインスペクタはこの回の後半のより高度なテストケースで役立ちます
またトランザクションをフィルタリングできるようになり Social Feed+の更新を含むトランザクションのリストをナビゲートするのに非常に便利ですこのAppでは年間販売履歴にもアクセスできます
サブスクリプション更新がたくさんあるためどのトランザクションで機能が利用可能かわかりにくくなりますそのプロダクトのIDを入力すると簡単にそのプロダクトのトランザクションを見つけることができます
自動補完メニューからプロダクトIDフィルタを選択します
購入日での絞り込みも可能なので今購入しているものだけに絞ることもできます
Social Feed+のサブスクリプション期限が切れているので Appで再度サブスクライブしてみましょう
これでサブスクリプションの確認ができたので新しいトランザクションだけが表示されるようになりました
XcodeでApp内購入テストの強化方法を見てきました App Store Connectからプロダクトとサブスクリプションを同期させ SwiftUIプレビューで StoreKit 設定を使用しトランザクションマネージャの新ツールを活用するのですでは Xcodeの新しい機能を使って高度なサブスクリプションケースをカバーするために Food TruckのApp内課金の機能テストを続けますまず Food Truckでの購入プロダクトの返金を依頼する返金リクエストのテストについてです次に Social Feed+ の加入者にプロモーションを提供するオファーコードのテスト Food Truckのユーザインターフェースにおける値上げの処理最後に課金のリトライと猶予期間のサポートによる不本意な解約の減少を検討します返金リクエストのテストを始めるため Appのサポートビューに移動し返金する最近のトランザクションを選択しますこのためのコードは簡単です refundRequestSheet モディファイアを追加し返金ボタンを押したら isPresented Bindingを trueに切り替えますでは実際に見てみましょう
Bindingがtrueになると返金請求シートが表示されます Xcode環境でテストすると選択したissueが StoreKit APIの取消理由と1対1で対応しました「デベロッパの問題」から「返金請求」を押してみましょう
App Storeでは返金処理に時間がかかりますが Xcodeや Sandboxのテストでは返金リクエスト後すぐにトランザクションが返金されますトランザクションマネージャで更新されたトランザクションのインスペクタを見ると先ほど選択した取消理由と取消日を確認することができます
トランザクションマネージャで返金をクリックするだけで返金をテストすることができます返金リクエストAPIは Food Truckの利用者に素晴らしいカスタマーサポートを提供します Xcodeで返金リクエストのテストをしたので StoreKitで返金されたトランザクションの処理方法を見ましょう
返金後更新されたトランザクションの値が Transaction.update シーケンスから発行されます revocationReasonと revocationDateプロパティを使い返金されたトランザクションを検出します Xcodeの返金リクエストシートでオプションを選択することで 2つの取消理由を簡単にテストすることができますそれが Xcodeで返金リクエストシートをテストする方法です iOSとmacOSで Xcode環境またはSandboxを使用している場合に有効です Xcodeでのテストは iOSかiPadOS 15.2以降の動作するiPhone またはiPadが必要です XcodeでMac上のテストは OS 12.1以降が必要ですではサブスクリプションオファーコードをテストしてみましょうローカルのStoreKit 設定ファイルを使用しますコード用の新しいオファーを作るにはサブスクリプションを選択しオファーコードテーブルの下の「+」を押してくださいそこでオファーを設定できますこれを「無料月間」と名付け 1ヶ月間の無料キャンペーンにします
App Store Connect と同様にどのようなお客様が対象となるのかお試しオファーが受けられるのかなどを選定しますとりあえずデフォルトの設定にしましょうコードの設定が完了したので「終了」を押します。 App Store Connectと同期している場合は設定されたオファーが自動的に表示されますオファーが設定されたので Appのストアビューに移動してみましょうサブスクリプションオファーを利用するためにビューの下部近くにこのボタンを追加しました Xcodeでストアビューの実装を開くとオファーコードの実装は offerCodeRedemption モディファイアを追加し誰かがボタンをタップしたときに isPresented Bindingを trueに切り替えますどうなるか見てみましょう
ボタンを押すと Appの上に引き換えシートが表示されます App Storeでは App Store Connectで生成したオファーコードを入力することができますが Xcodeではより合理的にテストができます設定ファイルのコードの全オファーリストを解除されるサブスクリプションによってグループ化されています利用するため先ほど作成したオファーをタップして利用するボタンを押してみましょう支払いシートが表示されお試しオファーの支払い直後にコードのオファーが開始されます
登録後確認画面が表示されるのでシートを閉じて Appが Social Feed+のアクセス解除を確認します
この新規トランザクションのインスペクタを見てみるとお試しオファーが適用されていることがわかります都度払いなので更新の欄を見るとお試しオファーの更新があと2回ありますそして先ほど引き換えた 1ヶ月無料コードその後通常サブスクリプションが無期限で更新されますインスペクタは複雑なシナリオでもも複数のサブスクリプションの状態に何が起こっているのか非常に明確に示してくれます StoreKitのローカル設定にオファーコードを設定する方法と iPhoneでのテスト方法について見てきましたオファーコードは将来および既存のサブスクリプション登録者に柔軟なプロモーションを提供する素晴らしい方法ですそして今 Food Truckでオファーコードを使うことがこれまで以上に簡単になりましたでは StoreKitでオファーをどう扱うか見てみましょうコードを引き換えた後 Transaction.updateと Status.updateの両方が新しい値を発行しますトランザクション値の offerTypeプロパティを確認し現在のトランザクションに適用されるオファーがあるかを確認できます今見たケースでは登録者がコードのオファーでお試しオファーを利用したため offerTypeの値は introductory になります renewalInfoの値で offerTypeプロパティをチェックすることで次の更新でどのオファーが存在するかを確認できます先ほどのケースでは都度払いを採用しているため初期値はお試しであることが予想されます 2つのサブスクリプション期間の後コードのオファーを重ねるように値がコードに切り替わるのを見ることができます offerTypeがcodeの場合 offerIDプロパティを使って適用されるオファーの参照名を取得することができますこれが Xcodeでオファーコードをテストする方法です Xcode 13.3からコードのオファーを設定し iOS15.4以降を搭載した iPhoneやiPadでテストしますこれでFood Truckでのコード動作が確認できました Social Feed+の値上げ時の Appの対応を検証します値上げのテストは Xcodeでは実に簡単ですまず初めにソーシャルフィードの月額利用料を値上げします
このステップは任意です価格はそのままでも値上げのシミュレーションは可能ですトランザクションマネージャに戻るとあとはサブスクリプションの最新のトランザクションを選択しツールバーの「値上げリクエストの同意」を押すだけです
トランザクションマネージャではトランザクションが「値上げペンディング」状態になりデバイスではApp上に値上げ同意を求めるシートが表示されていることが確認できますこのシートはコードなしでも表示されますが新しいMessage APIを使ってその動作をカスタマイズできます
Messages APIをどの様にコードに統合したのでしょうか
メッセージのシーケンスを forループイテレートし値上げのようなメッセージを受け取った場合ドーナツエディタのようなセンシティブなビューが表示されないことを確認しますそれ以外の場合は DisplayMessageActionでメッセージを表示しますドーナツエディタが表示された場合は Messageの値を保持しドーナツ編集終了後に表示するようにします
テストに戻りましょう
App Storeでは登録者が解約や値上げに同意するまで異なるタイミングで複数の値上げメッセージが表示される場合があります Xcodeではこのメッセージをいつ表示完全にコントロールできますトランザクションマネージャのボタンを押す度すでに値上げされた状態のトランザクションでも再度メッセージが表示されますこの延期ロジックが機能するか試してみましょうドーナツエディタを開いて
再びシートを開くためのメッセージを送信します
まだシートは表示されていませんがドーナツエディタから離れると期待通りにシートが表示されます値上げを承認するかシートで解約もできますが現実にはユーザーがメールなどの外部ソースで値上げに応じることもあるでしょうこれをシミュレートするためトランザクションマネージャの承認/辞退ボタンを使用できますドーナツ編集体験が気に入りトランザクションマネージャで承認を押して新しい価格に同意します XcodeでStoreKitを使うと値上げなど複雑なケースのテストがとてもスムーズにできます値上げをシミュレーションする方法を見たので次は StoreKitを使って値上げを処理する方法です
値上げの状態をテストする場合状態の更新シーケンスは状態変更毎に値を発行します RenewalInfoの priceIncreaseStatus プロパティを確認することで Appで更新を検出できます値上げで顧客がサブスクリプションを解除した場合 expirationReason プロパティに didNotConsentToPriceIncrease をチェックすることで検出することができます値上げテストを中心にユニットテストも書けますまずダイアログを無効にすることで App上に値上げのUIを表示せずにテストができますサブスクリプション後 requestPriceIncrease ConsentForTransaction APIを使用してサブスクリプションに最新トランザクションの IDを渡して処理を開始できますテストトランザクションが値上げ待ちであることを確認するため isPendingPriceIncreaseConsent プロパティをチェックします最後にテスト内容に応じて consentToPriceIncrease ForTransaction 又はdeclinePriceIncrease ForTransactionで価格上昇時のAppの反応を確認できます値上げのテストは以上です値上げは Xcode13.3にて全プラットフォームでテスト可能です値上げのメッセージは iOS15.4以降でテスト可能です最後にサブスクリプション支払いの再試行と猶予期間を見てみます支払いの再試行とはカードの有効期限切れなどエラーが発生した場合にサブスクリプション更新をしようとする状態です App Storeでは支払いの再試行の際に問題の修正とサブスクリプションの回復が試みられます支払いの再試行状態の開始時に期間限定で利用を継続させる猶予期間をオプションで有効にすることができます Xcodeでテスト時にこれをシミュレートする方法を説明しますサブスクリプション更新の課金問題をシミュレートするためテスト中のStoreKit設定の「エディタ」メニューを開き「更新時の支払いの再試行」を有効にします
Food Truckは課金猶予期間に対応させたいのでメニューの「課金猶予期間」も有効にしましょう
購読率も速くして状態がどう変化するか見守ります
まずはSocial Feed+に登録しましょう
リニューアルの時期になるのを待ちましょう
トランザクションが終了すると課金猶予期間状態になりますトランザクションインスペクタで各状態の終了時刻が見れます
課金猶予期間が切れたばかりで今は標準的な支払いの再試行の状態ですいつでも「トランザクションの問題解決」ボタンで課金エラーを解決するシミュレーションを行うことができます問題を解決するテストをしましょう
問題が解決されたので新しいトランザクションを取得します
「更新時の支払いの再試行」を有効にしている限り新しいトランザクションはそれぞれ支払いの再試行に入り続けるのでこのテストを何度でも繰り返すことができます支払いの再試行と猶予期間を適切に処理することは不本意な解約を減らし契約者を維持する重要ポイントです Xcodeでこの状態を簡単にシミュレートできると分かったので StoreKitでこれらの状態を処理する方法を説明します支払いの再試行と猶予期間の状態が変化すると状態更新シーケンスが新しい値を発行します Food Truckでは課金猶予期間を設けるため猶予期間中は加入者が Social Feed+にアクセスできるようにする必要があります契約者の猶予期間は更新情報の gracePeriodExpirationDate プロパティで確認できます支払いの再試行を確認するには isInBillingRetryで確認します
Statusのstateプロパティで一方の状態を検出できますお客様が一方の状態にあることを確認したら課金問題を解決するためディープリンクでApp Storeに誘導できます現在のエンタイトルメント APIを使用している場合猶予期間の期限切れのサブスクリプションのトランザクションを受信します StoreKitのテストセッションで billingGracePeriodIsEnabledと shouldEnterBillingRetryOnRenewal を設定することでユニットテストで支払いの再試行と猶予期間を制御できます Appが支払いの再試行に入ったことを認識するとトランザクションのhasPurchaseIssue はtrueになりますさまざまなステータス更新を待ち Appが予想通りに更新されたことを確認したらトランザクションの問題解決メソッドを使用して App Storeのサブスクリプション回復をシミュレートできます支払いの再試行と猶予期間はすべてのプラットフォームの Xcode 13.3以降でテスト可能です後半ではPeterが iOSと iPadOS16のSandboxでこの状態をテストする方法をより詳しく説明します
返金要求から支払いの再試行や猶予期間の処理まで高度なテストケースをカバーしましたこれらのケースをサポートする新しい StoreKit APIの使用方法の詳細は「App内課金の最新情報」をご覧ください
以上今年のXcodeでの StoreKit Testing新機能をざっと紹介しましたが網羅した訳ではありません新しいサブスクリプションの更新率があり XcodeでStoreKit 2の App内サブスクリプションテスト StoreKitTestを使って SKAdNetwork実装のユニットテストが書けるようになりました詳しくは「SKAdNetworkの最新情報」をご覧くださいそれでは Peterが今年のSandbox テスト環境の新機能を説明しますありがとう Greg App StoreのサーバエンジニアのPeterです新機能StoreKit Testingが複雑なApp内課金の実装をテストするのに役立つことを確認しました私たちは常にお客様の声に耳を傾けており多くの皆様がApp Store Sandbox環境を利用して App内課金やサーバ実装のテストを行っています今回はオンライン環境でより簡単にAppやサーバテストが出来る様新しい機能拡張を紹介します Sandboxの Apple ID作成 App Store Connect APIの強化支払い障害想定について紹介しますサンドボックス環境を利用するためには App Store Connectで Apple IDを設定しますサンドボックスのテスターリストは「ユーザとアクセス」のナビゲーションバーに移りプラスボタンで新しいテスターを作成します新しいテスターウィンドから幾つかフィールドを削除し作成プロセスを効率化しました必要最低限の情報しか求めないため不要な情報を入力せずにアカウント作成に進むことができますアドレスには「プラス記号」が使えテスター毎に新しいアドレスを作る必要はありません強力パスワードは面倒ですがこれも簡単にできます安全性を高めるための提案もインラインで追加しています
Apple IDの作成フォームを合理化しパスワードの複雑さのヒントを改善することでアカウント設定時間を削減 Appの開発に時間を割ればと思います App Store Connectは Apple IDの作成と管理およびAppコンテンツと組織の管理を行う中心的な場所ですここ数年アカウント地域の変更や購入履歴のクリアなどみなさんからご要望をいただいていた機能を追加しています多くはApp Store Connect やデバイス上のサブスクリプション管理ページでアクセス可能です今年後半には Apple IDのリスト照会購入履歴を消去したり購入状態を中断させるなど機能を幾つかApp Store Connect APIに取り入れる予定ですアカウントでの高速テストが可能になり一般的なツールの自動化顧客設定に役立ちます最後に支払い障害想定への対応をお知らせします 2018年には不本意な解約を減らすために自動更新のサブスクリプションに対する支払いの再試行と猶予期間を発表しました 2019年の発表以来課金猶予期間は 3億日分の有料サービスをお客様に回収しました結果みなさんのビジネスには収益の増加がもたらされお客様にはサービスの中断がされることはありません多くはすでに本番環境で課金障害を処理していますがサンドボックスでより多くのテストシナリオを提供し App Storeで公開前に課金障害をテストして処理できるようにしたいと考えています新しいアカウント設定ページを使用してアカウントの課金障害想定を有効にし Appのコンテキストでフォアやバックグラウンドのサブスクリプション障害をテストサンドボックスの verifyReceipt App Store Server API App Storeサーバ通知 V2 でサブスクリプション状態を確認できます支払いの再試行や不本意な解約を減らすための詳細は 2018年のWWDC「サブスクリプションのデザイン」がお勧めです今年はアカウント設定に App内課金失敗を想定するスイッチを新たに導入します Sandboxサブスクリプションページも新たに設置されました課金失敗想定を有効にするとフォアグラウンドでの App内課金が失敗されますこの動作はお客様の支払い方法が拒否された場合の動作と一致しますまた課金障害想定により自動更新の状態が本番の課金障害時の状態と一致することを確認しますつまり課金に問題があるお客様に対しての App内メッセージをテストできますこれらのサブスクリプション状態は V2通知で確認したApp内課金のレシートに反映されますサブスクリプションのライフサイクルを確認しましょう Sandboxで自動更新のサブスクリプションを購入すると SUBSCRIBEDや DID_RENEWといった V2通知を受け取っていますアクティブなサブスクリプションを持つアカウントで App内課金の失敗をテストすると次の更新が支払いの再試行状態になります DID_FAIL_TO_RENEW のような支払いの再試行通知を受け取れるようになりました課金障害想定を無効にした後サブスクリプションの更新回復の試行を停止すると次の更新の試行は成功しサブタイプ BILLING_RECOVERYの DID_RENEW 通知が届きますリトライの制限に達し課金失敗想定が有効の場合サブスクリプションは失効しサブタイプ BILLING_RETRYで EXPIRED を受け取りますすでに本番環境で Grace Periodを使用し SandboxでV2通知を使用している場合 GRACE_PERIOD DID_FAIL_TO_RENEW 通知を受け取ることが期待できます以下は支払いの再試行状態猶予期間のあるサブスクリプション例です猶予期間終了時に課金障害想定が有効な場合 GRACE_PERIODとGRACE_PERIOD_EXPIRED と同様にサブタイプの DID_FAIL_TO_RENEW の通知を受け取ります App StoreサーバAPIでサブスクリプション情報を検証する場合 signedRenewalInfoのペイロードをデコードしサブスクリプション状態を検証できます expirationIntentと支払いの再試行のフィールドが入力されます支払いの再試行ステートのレシートで /verifyReceiptを呼ぶと is_in_billing_retry_period フラグが 1 に設定されます猶予期間を使用する場合有効期限のフィールドが入力される期待ができます Sandboxでの課金障害のテストが完了したらアカウント設定でスイッチを無効にできます新しいテストがお客様にとって最高のエクスペリエンスを構築するのに役立つことを願っています本日は App内課金機能のテストを効率化するためのいくつかの新しいテスト機能について説明しました App Store Connectの設定を Xcodeと同期させることでローカルやSandbox 環境のテストでも同じApp内課金の設定を利用できます Xcodeのオファーコードや返金テストの新機能により複雑なStoreKitの実装を検証できますサブスクリプション管理のテストの容易性でサービスが中断されても優れた顧客体験を保証するために Appを進化させることが可能になります課金失敗がサブスクリプションにどう影響するか SandboxでのApp Store サーバ通知 V2については WWDC 21のセッションをお勧めします「サーバにおける App内課金の管理」です App Store Server APIと V2通知の新機能は「App内課金の最新情報」をご覧くださいこれらの新機能について皆様の意見をお待ちしてますご参加ありがとうございました

VStack(alignment: .leading) {
    Text(subscription.displayName)
        .font(.headline.weight(.semibold))
    Text(subscription.description)
}

11:18 - Refund view

struct RefundView: View {
    @State private var selectedTransactionID: UInt64?
    @State private var refundSheetIsPresented = false
    @Environment(\.dismiss) private var dismiss
    var body: some View {
        Button {
            refundSheetIsPresented = true
        } label: {
            Text("Request a refund")
                .bold()
                .padding(.vertical, 5)
                .frame(maxWidth: .infinity)
        }
        .buttonStyle(.borderedProminent)
        .padding([.horizontal, .bottom])
        .disabled(selectedTransactionID == nil)
        .refundRequestSheet(
            for: selectedTransactionID ?? 0,
            isPresented: $refundSheetIsPresented
        ) { result in
            if case .success(.success) = result {
                dismiss()
            }
        }
    }
}

12:33 - Refunds emit an updated value from the transaction updates sequence

for await update in Transaction.updates {
    let transaction = try update.payloadValue
  
    if let revocationDate = transaction.revocationDate,
  	   let revocationReason = transaction.revocationReason {
        print("\(transaction.productID) revoked on \(revocationDate)")
       
        switch revocationReason {
        case .developerIssue: <#Handle developer issue#>
        case .other: <#Handle other issue#>
        default: <#Handle unknown reason#>
        }
        
        <#Revoke access to the product#>
    }
    <#...#>
}

14:21 - Offer code view

struct SubscriptionPurchaseView: View {
    @State private var redeemSheetIsPresented = false
        
    var body: some View {
        Button("Redeem an offer") {
            redeemSheetIsPresented = true
        }
        .buttonStyle(.borderless)
        .frame(maxWidth: .infinity)
        .padding(.vertical)
        .offerCodeRedeemSheet(isPresented: $redeemSheetIsPresented)
    }

}

16:23 - Offer redemptions emit updated values from Transaction.updates and Product.SubscriptionInfo.Status.updates

for await verificationResult in Transaction.updates {
    guard case .verified(let transaction) = verificationResult else {
        <#Handle failed verification#>
    }
    <#Handle updated transaction#>
}

for await updatedStatus in Product.SubscriptionInfo.Status.updates {
    guard case .verified(let renewalInfo) = updatedStatus.renewalInfo else {
        <#Handle failed verification#>
    }
    <#Handle updated status#>
}

16:31 - Check the active offer on the transaction value

for await status in Product.SubscriptionInfo.Status.updates {
    let transaction = try status.transaction.payloadValue
    let renewalInfo = try status.renewalInfo.payloadValue
    
    if let currentOfferType = transaction.offerType {
        switch currentType {
        case .introductory: <#Handle introductory offer#>
        case .promotional:  <#Handle promotional offer#>
        case .code:         <#Handle offer for codes#>
        default:            <#Handle unknown offer type#>
        }
        self.hasCurrentOffer = true
    }

    <#...#>

}

16:49 - Check the next pending offer on the renewal info value

for await status in Product.SubscriptionInfo.Status.updates {
    let transaction = try status.transaction.payloadValue
    let renewalInfo = try status.renewalInfo.payloadValue
    
    <#Check active current offer#>
    
    if let nextOfferType = renewalInfo.offerType {
        switch currentType {
        case .introductory: <#Handle introductory offer#>
        case .promotional: <#Handle promotional offer#>
        case .code:
            print("Customer has \(renewalInfo.offerID) queued")
            <#Handle offer for codes#>
        default: <#Handle unknown offer type#>
        }
        self.hasQueuedOffer = true
    }
    <#...#>
}

18:45 - Messages updates loop

private var pendingMessages: [Message] = []

private func updatesLoop() {
    for await message in Message.messages {
      if <#Check if sensitive view is presented#>,
         let display: DisplayMessageAction = <#Get display message action#> {
           try? display(message)
      }
      else {
        pendingMessages.append(message)
      }
    }
}

20:53 - Price increase changes emit an updated value from the status updates sequence

for await status in Product.SubscriptionInfo.Status.updates {
    let renewalInfo = try status.renewalInfo.payloadValue

    if renewalInfo.priceIncreaseStatus == .agreed {
        print("Customer consented to price increase")
        <#Handle consented to price increase#>
    }
    if renewalInfo.expirationReason == .didNotConsentToPriceIncrease {
        print("Customer did not consent to price increase")
        <#Handle expired due to not consenting to price increase#>
    }

    <#...#>

}

21:19 - Unit testing price increases

let session: SKTestSession = try SKTestSession(configurationFileNamed: "<#Configuration name#>")
session.disableDialogs = true

<#Purchase a subscription#>

var transaction: SKTestTransaction! = session.allTransactions().first
session.requestPriceIncreaseConsentForTransaction(identifier: transaction.identifier)

transaction = session.allTransactions().first
XCTAssertTrue(transaction.isPendingPriceIncreaseConsent)

<#Assert app updates for pending price increase#>

// Write a test case for consenting and cancelling due to price increase:

session.consentToPriceIncreaseForTransaction(identifier: transaction.identifier)

// OR

session.declinePriceIncreaseForTransaction(identifier: transaction.identifier)
session.expireSubscription(productIdentifier: "<#Product ID#>")

<#Assert app updates for finished price increase#>

24:57 - Billing retry and grace period status changes emit an updated value from the status updates sequence

for await status in Product.SubscriptionInfo.Status.updates {
    let renewalInfo = try status.renewalInfo.payloadValue

    if let gracePeriodExpirationDate = renewalInfo.gracePeriodExpirationDate,
       gracePeriodExpirationDate < .now {
        print("In grace period until \(gracePeriodExpirationDate)”)
        <#Allow access to subscription#>
    }
    else if renewalInfo.isInBillingRetry {
        <#Handle billing retry#>
    }

    <#...#>

}

25:27 - Using the state property of a status value to check for billing retry states

struct SubscriptionStatusView: View {
    let currentSubscription: Product
    let status: Product.SubscriptionInfo.Status
    @Environment(\.openURL) var openURL
    var body: some View {
        Section("Your Subscription") {
            <#...#>
            if status.state == .inBillingRetryPeriod || status.state == .inGracePeriod {
                VStack {
                    Text("""
                    There was a problem renewing your subscription. Open the App Store to
                    update your payment information.
                    """)
                    Button("Open the App Store") {
                        openURL(URL(string: "https://apps.apple.com/account/billing")!)
                    }
                }
            }
        }
    }
}

25:41 - Current entitlement APIs will account for grace period

for await entitlement in Transaction.currentEntitlements {
    <#Grant access to product#>
}

25:50 - Unit testing billing retry and grace period

let session: SKTestSession = try SKTestSession(configurationFileNamed: "<#Configuration name#>")
session.billingGracePeriodIsEnabled = true
session.shouldEnterBillingRetryOnRenewal = true

<#Purchase a subscription#>

wait(for: [<#XCTExpectation#>], timeout: 60)

let transaction: SKTestTransaction! = session.allTransactions().first
XCTAssertTrue(transaction.hasPurchaseIssue)

<#Assert app still allows access to subscription due to grace period#>

wait(for: [<#XCTExpectation#>], timeout: 60)

<#Assert app detects billing retry and no longer allows access to subscription#>

session.resolveIssueForTransaction(identifier: transaction.identifier)

<#Assert app allows access to subscription#>

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21

WWDC20