WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Introducing StoreKit Testing in Xcode

Introducing StoreKit Testing in Xcode

StoreKitIn-App PurchaseXcodeTesting
元の動画を見る

ハイライト

Xcode 12 では、StoreKit のアプリ内購入テストをローカル構成、トランザクション マネージャー、および StoreKitTest の自動プロセスに導入し、開発者が最初に購入、払い戻し、購入依頼、サブスクリプションの更新をローカルで検証し、次にサンドボックスを使用してサーバーの受信とサブスクリプション管理のシナリオをカバーできるようにします。

主要内容

アプリ内購入を実装する場合、開発者は最初に App Store Connect にアクセスし、アプリを登録し、アプリ内購入を定義してから、サンドボックス テスト アカウントを作成する必要がありました。これらの準備が完了した後でのみ、Xcode の StoreKit コードは実際に製品を取得し、購入を開始し、領収書を確認できます。

このパスに関する問題は開発の初期段階で発生します。製品 ID、価格、サブスクリプションのグループ化、返金、購入依頼、サブスクリプションの更新、その他のステータスはすべて繰り返しデバッグする必要がありますが、チームはサーバー構成とサンドボックス アカウントが連携するまで待つ必要があります。 Fruta の例では、アプリは次のように記述されていますSKProductsRequest, ただし、App Store Connect がまだ製品を構成していないため、シミュレーターにはレシピが表示されません。

Xcode 12 の変更は、StoreKit テストの最初のラウンドをローカル プロジェクトに戻すことです。開発者によって作成されました.storekit消耗品、非消耗品、自動更新のサブスクリプションを定義する構成ファイル。スキームの実行オプションをこの構成ファイルに指定すると、StoreKit はローカル テスト環境から戻ります。SKProductメタデータ。

手動テストも制御可能になります。トランザクション マネージャーは、トランザクションの削除、返金のシミュレーション、購入依頼の承認または拒否を行うことができます。サブスクリプション構成により時間を短縮でき、1 か月の更新を数秒で行うことができます。ローカルプロセスが安定したら、App Store Connect とサンドボックスに移動して、実サーバー、領収書の署名、サーバー通知、および TestFlight カバレッジをテストします。

詳細

ローカル StoreKit 構成

(04:13) Fruta の例では、まず StoreKit 構成ファイルを作成し、販売するレシピをプロジェクトに書き込みます。このファイルは、消耗品、非消耗品、および自動更新可能なサブスクリプションを追加できます。製品 ID は、アプリによって StoreKit API に渡される値と一致する必要があります。価格は、アプリに返される値を制御するためにローカルで入力されます。SKProduct。

StoreKit configuration file
Product ID copied from Store.swift
Run Options -> StoreKit Configuration
SKProductsRequest -> SKProduct

キーポイント:

  • StoreKit configuration fileこれはローカル製品ディレクトリであり、レシピはスピーチで非消耗品として定義されました。
  • Product IDアプリコード内の製品 ID と一致している必要があります。そうでない場合は、SKProductsRequest対象商品が入手できません。
  • スキームRun Optionsこの構成が選択されると、StoreKit はローカル テスト環境を使用します。
  • 商品の説明を変更した後、アプリを再実行しますSKProductsRequest再コンパイルや再起動を行わなくても、更新されたメタデータを取得できます。

取引ステータスと境界プロセス

(08:39) Fruta わかりましたSKProductとして作成されましたSKPayment、支払いキューに参加します。シミュレーターには実際のユーザー エクスペリエンスに近い支払いフォームが表示されますが、テスト中にログインは必要なく、料金も請求されません。トランザクション マネージャーにはローカルの購入記録が表示され、開発者は購入の削除、返金のシミュレーション、購入依頼の処理、中断された購入の切り替えを行うことができます。

SKProduct -> SKPayment -> payment queue
Transaction Manager -> delete transaction
Transaction Manager -> refund transaction
Ask to Buy -> deferred transaction -> approve or decline
Interrupted purchases -> failed first transaction -> later transaction added to queue

キーポイント:

  • トランザクションを削除すると、アプリを未購入の状態に戻すことができます。これは、同じ購入プロセスを繰り返しデバッグするのに適しています。
  • 返金のシミュレーション後、トランザクションはまだトランザクション マネージャーと領収書にありますが、領収書にはキャンセル日が記載されます。
  • Ask to Buy により、アプリの支払いトランザクション オブザーバーは遅延ステータスを受け取り、トランザクション マネージャーによって承認または拒否されます。
  • 購入を中断すると、まず失敗が返されます。ユーザーがアカウント操作を完了すると、同じ製品の新しいトランザクションがキューに追加されます。

サブスクリプション、領収書、ローカル証明書

(12:15) セッションでは、Recipes Plus と Recipes Pro によるサブスクリプションの自動更新を示します。 2 つのサブスクリプションが同じサブスクリプション グループに配置されている場合、アプリはアップグレード エントリを提供できます。構成ファイルの時間間隔は 1 秒から 1 日に設定でき、自動更新を確認するのに数秒かかります。

Auto-renewable subscriptions
Subscription group
Time Rate -> one second equals one day
StoreKit Test Certificate
debug macro for local receipt validation

キーポイント:

  • 同じサブスクリプション グループは、アプリがさまざまなサブスクリプション レベルとアップグレード オプションを表示することをサポートします。
  • 時間レートにより、実際の月数が経過するのを待たずに更新テストが可能になります。
  • ローカル StoreKit テスト レシートは別の秘密キーで署名されており、サンドボックスまたは実稼働レシートの証明書チェーンに従って直接処理することはできません。
  • トランスクリプト クライアント側の検証コードでデバッグ マクロを使用し、デバッグ ビルドで StoreKit テスト証明書を選択することをお勧めします。

StoreKitTest とサンドボックスの入力

(17:22) 手動プロセスが実行された後、StoreKitTest フレームワークはローカル テスト環境を XCTest に公開します。テストでは、ポップアップの無効化、古いトランザクションのクリーンアップ、購入のトリガー、サブスクリプション更新の即時トリガーを行うことができ、アプリ内購入プロセスが単体テストと UI テストに入ることができるようになります。

StoreKitTest framework
XCTest
StoreKitTest session initialized with configuration file
Disable dialogs
Clear previous transactions
Buy recipe and confirm availability

キーポイント:

  • テストで参照できるように、構成ファイルをテスト ターゲットに追加する必要があります。
  • ダイアログを無効にすると、テストは支払いフォームの手動クリックを待つ必要がなくなります。
  • 以前のトランザクションをクリーンアップすると、各テストがクリーンな状態から開始されます。
  • サンドボックスは、App Store Connect 製品構成、サンドボックス Apple ID、App Store 署名済みレシート、サーバー側レシート検証、および App Store サーバー通知に引き続き使用されます。

重要ポイント

  • ローカル IAP 返却キット: やるべきこと: 各 IAP アイテムを準備する.storekitターゲットを構成してテストします。実行する価値がある理由: セッションは、ローカルでの購入、トランザクションの削除、返金がすべて Xcode で実行できることを示しています。開始方法: 製品 ID をアプリ コードから構成ファイルにコピーし、StoreKitTest を使用して古いトランザクションをクリーンアップし、購入アサーションを実行します。
  • 払い戻し後の権限回復テスト: 対処方法: 払い戻しが発生した直後に、有料コンテンツがロックバックされているかどうかを確認します。実行する価値がある理由: トランスクリプトには、返金はキャンセル日が記載されたレシートに保存され、アプリは更新情報を受け取ると説明されています。開始方法: トランザクション マネージャーを使用して払い戻しをシミュレートし、ローカルの資格ステータスを確認します。
  • エクスペリエンス チェックの購入を依頼: 対処方法: 子アカウントが購入をリクエストし、承認を待ち、承認後のロックを解除するプロセスをカバーします。実行する価値がある理由: ローカル テストでは、トランザクションを延期に設定してから、手動で承認または拒否できます。開始方法: StoreKit 構成ファイルのエディター メニューで [Ask to Buy] を有効にし、支払いトランザクション オブザーバーのステータスの変化を観察します。
  • サブスクリプション更新加速テスト: 作業内容: 毎月のサブスクリプションの更新、アップグレード、権限の更新を数秒以内に検証に圧縮します。実行する価値がある理由: 時間レートは 1 秒から 1 日まで設定できるため、自動更新可能なサブスクリプションをすばやく確認するのに適しています。開始方法: 複数のサブスクリプションを同じサブスクリプション グループに入れ、購入後のタイム レートを増やします。
  • ローカル受信確認ブランチ: 対処方法: デバッグ ビルドで StoreKit テスト証明書を使用してローカル受信を確認します。実行する価値がある理由: ローカルのレシートは別の秘密キーで署名されており、証明書チェーンも異なります。開始方法: StoreKit 構成エディターから証明書をエクスポートし、クライアント側検証コードのデバッグ マクロを使用して証明書を選択します。

関連セッション

コメント

GitHub Issues · utterances