StoreKit Testing in Xcodeの導入

こんにちは WWDCへようこそ “StoreKit Testing in Xcodeの導入” こんにちは“StoreKit Testing in Xcodeの導入”へようこそ 私の名前はダナです みなさんに 私たちが今年導入する すばらしい機能の数々をご紹介する 機会をいただいたことに ワクワクしています これは APP内課金の構築とテストを 今までよりも改善するものです 新機能のご紹介を始める前に APP内課金機能を追加するために 開発者の方々は 現状ではStoreKitをどう扱っているか 簡単に見てみましょう 今 私がアプリケーションを 更新したいと考えたとします StoreKitを通じてコンテンツを 売り始めたり 新しい販売用コンテンツを追加するためです 本当の第一歩としてしなくてはならないのは App Store Connectにサインインすることです そこで私は アプリケーションを登録し APP内課金を定義する必要があります そして テスト用に私のサンドボックス アカウントを作成する必要があります これらの手順を踏んだ後に ようやくXcodeに戻って StoreKitをアプリケーションに統合する プログラムを書き始めることができます

アプリケーションを構築する中で APP内課金をテストするために サンドボックス環境で作業することになります App Store Connect内で設定した サンドボックスアカウントを使うと テストとして購入を行った場合でも 課金されません さらに アプリケーションをベータテストに 出した後も サンドボックス環境は アプリケーションについて 作業する開発者の間で使われ続けます

アプリケーションが想定どおりに 動作することを確認してはじめて アプリケーションをApp Storeにリリースできます App Storeでは StoreKitの呼び出しを支援 するために商用環境が使用されます

過去 これはうまく行っていました しかし 開発者の皆さんにより良い方法を ご提供できるのではないかと考えました “Xcode内のStoreKitテスト” 今年のXcode 12の新機能をご紹介 できることに ワクワクしています 新しい開発およびテスト用 ソフトウェアスイートを導入します これは StoreKitとAPP内課金に 特化したものです これを使うと Xcodeの中で あなたのアプリケーションのAPP内課金を 完全にローカルで構築してテストできます これはすべてXcodeに統合されています アプリケーションの開発ワークフローと 切れ目なくつながっています さらに 全く新しいStoreKitテスト フレームワークも導入しました StoreKit統合について テストを完全に自動化できます “開発ライフサイクル” これによって StoreKitの 開発ライフサイクル全体が変わります 今後は App Store Connectを起動する 代わりに Xcodeの中で

StoreKit統合の構築と アプリケーションの他の部分の構築を 同時に行うことができます

追加で UIおよびその他の自動化テストで アプリケーションのStoreKit統合を確実に 高品質なものにできます その後にApp Store Connectにサインインして サンドボックス環境を使うことができます サンドボックスを使うことは 必須手順の一つです App Storeにアプリケーションをリリースできる 状態かどうかを確認するためです それはまた アプリケーションについて あらゆるサーバー対サーバーの機能を テストするためにも必要な環境です さらに今年 サンドボックス環境に 多くのすばらしい機能強化が 追加されました このセッションの後半で 私の同僚の クリスが詳細をご紹介します

Xcode 12内のStoreKitテストについて 詳細を見ていくことにしましょう 私がFrutaという フルーツスムージーに関する アプリケーションを開発しているものとします そして 今とりかかっているのが スムージーのレシピ販売機能だとします StoreKit技術を使うよい例です レシピはアプリケーション内で販売したい デジタルコンテンツだからです Frutaの開発は既に レシピに関するストアプロダクトを 取得して表示することができています アプリケーション内のストアコンテンツを 保存しているStore.swiftを見ていくと プロダクトIDのリストがあるのが ご覧いただけるでしょう 販売したいさまざまな レシピのすべてです

下の方に行くと fetchProducts機能の中に

SKProductsRequestの 呼び出しがあり そこには これらのレシピすべての プロダクトIDが保存されています

Frutaは それらのプロダクトを取得して 表示できるようになっているはずです シミュレーター内で起動して どうなるか見てみましょう

ご覧いただけるように レシピが一つも表示されません しかし これは当然です App Store Connect内で アプリケーションやAPP内課金を 設定していないからです 初期設定では StoreKitは サンドボックス環境を使用します 従って Xcode内のローカルテストを 使用可能にする必要があります プロジェクトのアプリケーション内 プロダクトを定義する必要があります 最初にメニューに移って

新規ファイルを作り

それに“StoreKit”と打ち込んで StoreKit設定 ファイルテンプレートを選択します プロジェクト内に新しい 設定ファイルを作成します アプリケーション内プロダクトすべての メタデータを保存する場所ができました アプリケーションが提供するレシピは エディターの左下にあります StoreKit品目を追加することを 選択できます

選択すると 追加するプロダクトの種類を 選ぶことができます 最初の選択肢は消耗型です これは 何度も購入できるような 種類のプロダクトです たとえばゲーム内のライフや宝石です ２番目は非消耗型で 一度購入したら期限切れがないものです 最後に 自動更新サブスクリプションが あります これは サービスやコンテンツのアクセスに 対して ユーザーに定期的に課金するものです 非消耗型を作ることを 選択します デジタルレシピの購入には 一番ふさわしいからです

次に販売したいレシピの詳細を 打ち込んでいく必要があります この場合 Berry Blueを選択します 私が好きなスムージーだからです

プロダクトIDはアプリケーション内の 特定のプロダクトを示す一意のIDです それは アプリケーションがStoreKit APIへ 渡す値と合っていなくてはなりません 確実に正しいものにするために Store.swiftからコピーしてペーストします

次に価格を設定する必要があります App Store Connectでは 価格カテゴリから選択しましたが それとは違って ここでは好きな数値を 入力することが選択できます StoreKitのXcode内での テストにおいては 価格は単にSKProduct内で アプリケーションに返される値を 設定するためのものに すぎないからです ここでは値を直接制御して 簡単に変更できます アプリケーションがあらゆる可能性のある 戻り値を扱えるか確認するためです 今のところ 99セントの ままにしておきます

さらに ファミリー共有を有効化するか 選択できます これは今年リリースする 新機能です Xcode内でStoreKitをテストする際に ファミリー共有を有効化すると SKProduct内のis-family-shareable フラグが更新されます ここでは有効化しないままにします

最後に このプロダクトにアプリケーション内 ローカルの名前を付ける必要があります

“BERRY BLUE”

内容説明を設定することもできますが 今のところは空白のままにします

StoreKit設定ができましたので 起動時にサンドボックスではなく そちらを使用するようXcodeに指示します やり方は簡単です スキームエディターを開いて

“run options”の下で さっき作成した 設定を選択します

アプリケーションを再起動すると StoreKitはローカル テスト環境を使用します

SKProductは先ほど設定した メタデータを返します

先に Berry Blueの内容説明の 設定を省略しましたが 内容説明を表示したいとします そして Frutaは既に ローカルの 内容説明を取得できるよう設定されました SKProductから取得して表示します Xcode内のStoreKitテストは 完全にインタラクティブです つまり アプリケーション内プロダクトの メタデータについて 再コンパイルや再起動せずに更新できます StoreKit設定ファイルを 更新するだけで 内容説明を表示できます

“入力と更新”

そして アプリケーションが SKProductリクエストを再実行して アップロードしたメタデータを取得します

プロジェクトには既に 販売したいすべてのレシピの StoreKit設定が 含まれています そちらのファイルに切り替えて アプリケーションを再起動しましょう

“構築成功”

アプリケーションは既に 取得したSKProductのデータを利用して SKPaymentを作成し 支払キューに 追加するよう設定されています そのプログラムを実行するには “購入” ボタンの一つを選択する必要があります

シミュレーター内で ユーザーが見るのと ほぼ同様の支払シートを見られます 大きな違いとして サインインする必要がなく 認証も不要ということがあります ここではテスト目的で 課金されるわけでもありませんので 単に“確認”を選択し 支払手続を続けます

サンドボックスや商用環境と同様に アプリケーションの支払トランザクション オブザーバーが更新されます トランザクションは“購入中”から “購入済”に移行します アプリケーションが確認できるように レシートも発行されました Berry Blueのロックが解除されました レシピを閲覧して確認できるようになりました

たとえば バグ修正や購入まわりの ユーザー体験のために Blue Berryの購入を再度実行する 必要が出てきたとします Xcodeの新しいStoreKit Transaction Managerで簡単にできるようになりました

ローカルテスト環境で行ったすべての 購入を見ることが可能で それらを完全に制御できます このトランザクションも削除できます “ID: ０ 購入済” そして 購入がなかったかのように 状態をリセットすることができます トランザクションを削除します よろしいですか？ “トランザクションなし” これで Blue Berryを購入したことがない人と 同様にBlue Berryを購入できるようになりました

以前の購入を 削除できることに加えて 返金のシミュレーションも可能です 返金の場合 トランザクションは transaction managerに残りますが 返金済としてマークされます

“ID 1: 購入済” “ID 1: 返金済”

トランザクションは アプリケーションの レシートにも残りますが キャンセル日を追加するように 更新されます 返金が実行された日です アプリケーションに返金の通知が行われて 即座に対応できるようになります 子供が購入の前に許可を得なくては ならない設定があります 子供用のアプリケーションを 使いやすいものにしたい場合 Xcode内のStoreKitテストは Ask to Buyを完全にサポートしています StoreKit設定ファイルに戻って エディターメニュー内の Ask to Buyを有効化するだけです

これで Fruta内で レシピを購入しようとすると おなじみの“許可取得”ダイアログが出ます Ask to Buyが 有効になっているすべての ユーザーのアカウントに表示されるものです

“Ask”を選択すると トランザクションは transaction manager内で “許可待ち”に表示されます プログラム内でアプリケーションの SKPaymentTransactionObserverに トランザクションが現在遅延状態に あることが通知されます

“ID: 2 許可待ち” ここで許可または却下できます 許可すると 以前は遅延トランザクションだったものが 購入済の状態に更新されます アプリケーションが即座に更新されて ロック解除されたレシピを表示します “Carrot Chops” 中断された購入を有効にする ことも選択できます これで ユーザーが購入を完了する前に 何らかの行動をしなくてはならない 場合のシミュレーションを 行うことができます たとえば ユーザーが 支払情報に関連する 情報を更新する 必要がある場合です この場合 最初の購入については “fail”が返されます しかし 購入失敗の原因となった 何らかの問題をユーザーが 解決した後に 同じプロダクトに対して新しい トランザクションが支払キューに追加されます

アプリケーションのビジネスモデルを サブスクリプションに 変更することを検討しているとします ユーザーは １回に１つの レシピを購入する代わりに １ヶ月定額ですべてのスムージーの レシピにアクセスできるようになります Xcode内のStoreKitテストでは 自動更新サブスクリプションの StoreKitを使った構築も 簡単になりました

２番目のStoreKit設定ファイルを 既に作成済みです

アプリケーション内で提供する サブスクリプションが２種類入っています まずレシピプラスです 月額$2.99で自動更新されるように 設定されています

課金の促進のために お試し価格として 初月度は99セントに設定しています

もう一つレシピプロを作成しました これはアプリケーション内のすべてのレシピの ロックを解除するだけでなく サブスクライバーが 個々のスムージーのより詳細な 栄養情報にアクセスできるようにします

２つのサブスクリプションは同一の サブスクリプショングループに入っています レシピプラスとレシピプロの間で アップグレードする選択肢を提供できます 既にFrutaで これらのサブスクリプションを 扱えるように構築しました そのビジネスモデルを試すためです そのために必要なのは StoreKitの設定を変更して アプリケーションを再起動するだけです

これで アプリケーションは提供可能な２種類の サブスクリプションの詳細を表示しています レシピプラスの方のお試し価格に ついても表示されます

アプリケーションがサブスクリプションの 自動更新の際に適切に処理できるか 確認したいとします ただし そのテストのために１ヶ月 まるまる待ちたくはありません Xcode内のStoreKitテストを使うと 時間を加速することができます サブスクリプション設定の エディターメニュー内で

Time Rateを選択します そして１秒を１日に設定します そうするとそのように変更されるので 更新が実行されるまでに数十秒待つだけで まる１ヶ月待たなくて済みます

サブスクリプションを購入したので すべてのレシピのロックが外れています

そして レシピ自動更新サブスクリプションが 自動的に更新する待ち時間は それほど長くなくて済みます

少し前のところで Transaction Managerを使って 購入を取り消して返金しました アプリケーションは即座に更新されて これらのレシピへのアクセスを無効にします これはiOS 14で可能になりました SKPaymentTransactionObserverに 追加された新しいAPI didRevokeEntitlementsForProductIdentifiers のおかげです

このAPIについての詳細 および今年StoreKitに追加された その他の新機能すべてについては “What's New with In-app Purchases”を ご覧になることをお勧めします

アプリケーション内で購入したコンテンツの 認証ができるようにするために App Storeではデジタル署名付き レシートを提供しています レシートはアプリケーション内で当該ユーザーが 購入したという 信頼できる記録です

それはデバイスに保存されて システムによって自動的に更新されます 署名付きなので それが確実に App Storeから来たものだとわかります そのデバイスのアプリケーション用 という意味合いです

レシートの確認の方法についてより詳細は 次のセッションをご確認ください 2018年の“Best Practices and What's New with In-app Purchases”です

ただし ローカルのXcode StoreKitテスト 環境で生成されるレシートを 取り扱う際に留意しなくてはならない 重要な相違点について いくつか強調したいことがあります まず ローカルのレシートは サンドボックスや商用環境で 生成されるレシートに 使用されるものとは異なる― プライベートキーで署名されています

確認の際には 別の証明書を使用する 必要があるということです 当該のStoreKitテスト証明書をStoreKit 設定ファイルのエディターメニューを通じて あなたのプロジェクトにエクスポートする 便利な方法をご提供しています

最後に StoreKitテスト証明書は 証明書チェーンに参加していません これらの違いの取扱いを簡単にするため クライアント側の確認プログラム内で デバッグマクロを利用するべきです そこではそのマクロに基づいて プログラムがStoreKitTest証明書と AppleIncRoot証明書の どちらを選択するか見ることができます

加えて クライアント側のレシート確認に OpenSSLを使用している場合 DEBUGをする時だけですが PKCS7_NOCHAIN引数を使用します Xcode 12内のStoreKitテストは 私たちが今までにリリースしたすべての ベータ版OSできちんと動作します シミュレーター上で構築して 起動した場合でも 実機の場合でも ローカルテスト環境を有効にした プロジェクトのStoreKit設定方法について 概要をご説明しました Transaction Managerを使用して 以前の購入を取り消して返金し 遅延または中断した購入 そして自動更新の購入についても 扱いやすい実装を確実に

行うようにしましょう

StoreKit統合を手作業で構築して テストできるようになることと 同じくらい重要なのは APP内課金を継続的に テストする 自動化を構築することです

それが新しいStoreKitTest フレームワークを導入する理由です 完全なローカルテスト環境をプログラム内で コントロールできるようになります “StoreKitTestフレームワーク” 手作業で行ったすべての コントロールはテスト内で公開されます StoreKitTestはAPP内課金の 単体とUIテスト対象を拡大するために XCTestと共同して動作します さらに StoreKitTestを使うと 通常であれば表示されるすべての シートやダイアログを無効に することができます そうすることで ユーザーの入力を 待たずに最後までテストを実行できます 最後に 即座にサブスクリプションの更新 トリガーを起動できます 更新をまたいでアプリケーションの サブスクリプション機能が動作し続けるか 確認のためテストできるようになります “StoreKitTest場合分け” StoreKitTestは広い範囲の場合分けを 対象とするために使用できます たとえば購入が成功 または失敗した 場合のアプリケーションの処理や 中断または遅延した購入 アプリケーションが起動していない時に 開始されたトランザクション サブスクリプションに関連する あらゆる種類の場合分けなどです

Xcodeに戻って 例でひととおり見てみましょう

Frutaの中に 既に一連の単体テストを構築しました APP内課金に関連した場合分けも 対象としています

最初は基本の場合のテストです

ユーザーの購入が成功した際に アプリケーションがスムージーのレシピを 正しくロック解除できることの確認です 一番はじめに実行することは 新しいStoreKitTestセッションの作成です 非消耗型のStoreKit設定ファイルで 初期化します 試験対象に設定ファイルを含めるのを 忘れないことが重要です SKTestSessionから 参照できるようにするためです 次に　セッション中 すべてのダイアログを無効にします ユーザーからの入力なしで最後まで テストが実行できるようにするためです その後　過去のトランザクションを すべて消します 確実に新規の状態から 開始するためです

最後に テストはレシピを購入して それが利用可能になることを確認します

“試験成功”

“試験成功” したがって先へ進めます この時点で アプリケーションとAPP内課金を App Storeで利用可能にするための 手続きを開始することができます 次の重要なステップは App Store Connectにサインインすることです APP内課金をサポートするために App Storeが必要なことをすべて設定します そしてその設定をサンドボックス 環境でテストします サンドボックスに追加しようとしている すばらしい機能強化と特徴のすべてを ご説明することについては クリスにお願いしましょう

ありがとう ダナ こんにちは　私はクリスです App Storeのプログラムマネージャーです Xcode内のStoreKitテストの 方法を見てきました ローカルテスト環境でAPP内課金を早い段階で テストしてデバッグできるようになりました Xcode内でのStoreKitテストと サンドボックス環境でのテストには 重要な違いがあります

まず App Store Connectで APP内課金を設定します このプロダクト情報はApp Storeで アプリケーションが利用可能となってから 使用するのと同じものです

テストデバイスにサインインするために サンドボックスApple IDを作成します

サンドボックスでは すべてのレシートは App Storeによって署名されます

サンドボックスはまた サーバー側レシート確認および App Storeサーバー通知もサポートします

iOS 12でApp Store設定にサンドボックス アカウントのセクションを追加しました

App Store Connectで設定する アカウントである サンドボックス アカウントにサインインするためです

iOS 14では APP内課金やサンドボックス内の サブスクリプションのテストが簡単になりました 新しいManageオプションを選ぶと 新しい Sandbox Manage Subscriptionsページが開きます

そこでサンドボックス内のサブスクリプションを 確認してテストできます

Frutaアプリケーションをタップすると サブスクリプショングループ内に すべてのサブスクリプションがあるのが見えます

サブスクライバーとして商用環境でこのページを 使ったことがある方もいるかもしれません 異なるサブスクリプション間で アプグレード ダウングレード キャンセルができます

今このページは開発者としての あなたが開いていますので サンドボックス環境で サブスクリプションの層をテストできます サブスクリプションのお試し価格機能に ついて対象者かどうかをリセットできる

機能が追加されました　これを使うと 同じサンドボックステストアカウントを 使って 無料お試しや お試し価格をテストできます お試し価格を 再試験するたびごとに 新しいサンドボックスApple IDを 設定する必要は もうありません “サンドボックス内での App Storeサーバー通知” サブスクリプションライフサイクルの 一例がここにあります サンドボックスの新機能を使うと アプリケーション外で起きる よくあるサブ スクリプションに対する変更をテストできます たとえばダウングレードや アップグレード キャンセルなど 顧客の行動を含みます サブスクライバーステータス変更通知タイプ に関するサーバーロジックをテストできます たとえばDid_Change_Renewal_Statusや Did_Renewなどです 新しい通知タイプが今年この後に 商用環境に追加されます それもサンドボックスで受け取ることができます

サーバー通知タイプについての詳細は “What's New with In-app Purchase”の セッションをご参照ください

App Store Connectの近日公開機能で デバイス上で中断された購入を サンドボックスアカウントがテストできます これを使うためには サンドボックスApple IDの行を選択します

シンディのアカウントを選択します 中断された購入を有効にする チェックボックスをチェックします

これでiOSデバイス上のサンドボックスで 中断された購入をテストできます

購入を完了する前に更新された 利用条件に同意する必要がある というようなシナリオが考えられます

個々のサンドボックスアカウントについて デバイス上での購入は App Store Connectに戻って 個々のテスト担当者に対して 中断された購入を無効にするまで 中断され続けます

新しいiOS 14のサンドボックス内の サブスクリプションおよびAPP内課金テスト 機能を確認してみましょう “サンドボックステストの新機能” デバイス上でサブスクリプションを 確認して管理できるようになりました アップグレード ダウングレード キャンセルや お試し価格の資格のリセットなども テストすることができます 今後すぐに デバイス上で アプリケーションが中断された購入に どう反応するかテストできるようになります

最後に App Store Connectにおいて 開発者の役割のユーザーは サンドボックステスト担当アカウントを 作成し管理することができます サンドボックス環境でのテストは 商用リリースの前にAPP内課金の 処理を改善できる すばらしい方法です まとめはダナにお返しします

ありがとう クリス StoreKitを利用する高品質なアプリケーションを 構築してリリースするには明快な道筋があります Xcode 12を起動して インタラクティブなローカルテスト環境を使用し StoreKit統合を構築します

StoreKitTestフレームワークを使用して テストとその自動化を構築し アプリケーションのサブスクリプションと APP内課金の機能について 確実に高品質なものにします

App Store Connectにサインインし APP内課金をサポートするために App Storeが必要なことをすべて設定します そしてその設定をサンドボックス 環境でテストします さらに サンドボックスを使って アプリケーションが必要とするすべての サーバー対サーバー機能をテストします

TestFlightを利用して アプリケーションとそのサブスクリプションや APP内課金機能の両方について ベータテストの対象としましょう それからApp Storeで アプリケーションを公開しましょう あらためてありがとうございます 皆さんがリリースするすばらしい アプリケーションを楽しみにしています