StoreKit 2について

♪ (StoreKit 2について) WWDC21にようこそ！ 私はRoss LeBeau StoreKitチームのエンジニアです 本日はStoreKitについてお話しします これは3つのセッションのうちの1つで クライアント側のコードの実装に 役立つように設計され App内課金ができるようにサーバーを構築し お客様サポートや返金対応に役立ちます このセッションはStoreKit 2の紹介ですが 残りの2セッションもWWDC21でご視聴いただけます このセッションではクライアント側の機能と実装に 焦点を当てます では始めましょう iOS 3に導入されて以来StoreKitは皆さまの ビジネスに大きなチャンスを生み出してきました 現在 StoreKitは4つのApple プラットフォームに存在し ゲームから新しいAppまで すべてに対応しています インディーズタイトルから世界的なヒット作まで ここ数年で数々の優れた機能を導入してきました オファーコード ファミリー共有 XcodeでのStoreKitテストなどがそうです しかし今年は初心に帰ります 本日ご紹介するのはStoreKit 2です StoreKit 2は新しい柔軟なSwift API群であり iOS macOS tvOS watchOSで App内課金を扱うためのものです 私たちはSwiftファーストの新たな視点から StoreKitを見直しました 最新の言語機能を採用し async/awaitパターンによるSwiftの並行処理など シンプルでパワフルなAPIを開発しました また App内課金の 仕組みを大幅に改善し もっと簡単に処理できるようにしながら さらに多くの情報と高いセキュリティを提供します そしてサブスクリプションに特化した 強力なAPIが追加され ビジネスの成長に役立つ より深いインサイトも提供します StoreKit 2 APIは現在存在する同じ StoreKitフレームワークの内部にあり すべてのAPIを置き換えるのではなく App内課金体験の中核部分に焦点を当てています 新しいStoreKit 2 APIは5つの主領域で構成され 具体的には商品・購入・取引情報・取引履歴そして サブスクリプションステータスの5つです 本日は各領域の概要を私が説明します その後で同僚のJakobが実際のコードで対応する StoreKit 2 APIの使い方を紹介します まずStoreKitブロックの構築から始めましょう 商品と購入です StoreKit 2商品構造体は これまでのStoreKitの 商品オブジェクトの強化版です まずデータを追加しました 商品タイプや 拡張サブスクリプション情報などです StoreKit 2ではお客様にお試しオファーの資格が あるかどうかなどの確認を しやすくなっています StoreKit 2商品は前方互換で 新機能にも対応します BackingValueと呼ばれるラッピングタイプを追加し 商品に直接添え字を付けて 商品に含まれるデータを 取得できるようにすることで実現しました つまり将来的に商品にデータを追加した場合 古いStoreKit 2を搭載したOSを実行している SDKやデバイスの場合もいつでも StoreKit 2でデータにアクセスできるのです つまり最新機能を駆使して より多くの顧客層に 新機能を提供できるわけです StoreKit 2では商品タイプ自体の 静的関数を呼び出して商品をリクエストします これは既存のSKProductsRequestと 同じくApp Storeの商品メタデータを要求します 新しいSwift並行処理 async/awaitパターンのおかげで 商品リクエストに必要なコードは1行のみ 同様にStoreKit 2では商品の購入も これまた簡単な1行のタスクです 購入は商品タイプのインスタンスメソッドになり つまり受信したばかりの商品で 購入を直接呼び出せるのです 購入メソッドもasync/awaitを使用するので インラインのコードで購入の結果を取得します すべての購入が同じなわけはありません デフォルト設定をやめて購入挙動を変更したければ StoreKit 2には購入オプションがあります 購入オプションは 購入の単一プロパティを記述するアイテムです 購入オプションを1つのセットにして 購入メソッドに渡すことができます StoreKit 2には数量やプロモーションのオファー などの購入オプションが含まれています StoreKit 2にはAppアカウントトークンという 新オプションも追加されます Appアカウントトークンは Appのどのユーザアカウントが 取引を開始・完了したかを追跡する方法です これはAppが所有するアカウントにリンクできる オパークトークンとして生成されます 唯一の要件はUUID形式に準拠することなので Appアカウントトークンを生成するのは 簡単です 購入時に購入オプションとして トークンを送信すると その購入の取引情報でこのトークンが 返されます Appアカウントトークンはデバイスを越えて 取引情報に永久に残ります Appが独自のアカウントシステムに対応する場合 購入に使用したApple IDまたは デバイスに関わらず App内アカウント別に購入状況を 追跡するのに役立ちます さてここまではApp Storeで 商品を入手する話でしたが その購入が完了するとどうなるのでしょうか？ ご想像のとおり 取引が成功した場合StoreKitは 暗号化された情報を返してくれます 聞き覚えがありますね StoreKit 2がApp内課金取引にもたらすのは これまでで最大のアップデートです まずStoreKit 2は取引 トランザクションごとに 個別の署名付きオブジェクトを提供します それだけでなくStoreKit 2以降の App内課金取引情報はごく一般的で 扱いやすいJSON形式で提供されます StoreKitの購入処理では暗号化された安全な署名が 重要な役割を果たすことがわかっているので 現在 JSON Web SignatureというWebで使用される 共通規格を採用しています 加えて 署名済みオブジェクト に含まれるすべての情報を StoreKitのネイティブAPIで利用でき このデータを Appのコードで簡単に扱えるようになります 実際にどれほど簡単かご覧に入れましょう Jakobが実際のコードでこれらのAPIのデモを 見せてくれます こんにちは Jakobです StoreKitチームのエンジニアです 本日はStoreKit 2のAppへの導入が いかに簡単かをご紹介いたします 右側にあるのは作成中のAppのPocket Carsです 本セッションのリソースセクションでこのAppの サンプルコードをダウンロードしてご覧ください Appにはメインビューが2つがあります 私が集めた車のビューとストアのビューです ストアに行ってみましょう 現時点でストアは空っぽです 商品が何もないからです 今からそれらを実装していきます すぐに起動して実行できるように XcodeでStoreKitのテストを走らせれば App Store Connectで商品を定義する前に ストアを構築してテストできます Xcodeプロジェクトには 販売したい商品を定義したStoreKit設定ファイルを 既に作成してあります StoreKitで使用したのと同じ設定ファイルです 手直しも移行も必要ありません すべての商品IDが入った plistもあります Appに組み込まれたリソースファイルとして 含まれているのでランタイムに使用できます 商品をストアに表示するにはまず 表示したい商品のIDを使って商品リクエストを 実行する必要があります StoreKit 2では商品構造体の 静的メソッドを呼び出すだけでそれができます

App Storeから商品情報を受け取ったら 種類別に分けたいですね StoreKit 2ではそれも簡単 App Storeサーバで定義されたとおりの商品の 種類がプロパティとして用意されているからです このAppでは燃料・車・ナビの3種類の 商品を販売しています 燃料は消耗型であり使うとなくなります すべてのコンシューマブルを燃料の配列に入れます

車は非消耗型 ノンコンシューマブルです 購入した車はずっと自分の所有物です すべての非消耗型を 車の配列に入れます

ナビはサブスクリプション商品で 3つのサービスレベルが用意されています 顧客が一度に申し込めるのは 1つのレベルのサービスのみで 定期的に請求されます サービスレベルを変更したければいつでも アップグレードまたはダウングレードできます App Storeはサービスレベルごとに商品を返すので 自動更新可能なすべてのサブスクリプションを サブスクリプションの配列に 入れておきます

さらに種類別の商品を安い順に 並べたいと思います

Appを実行して成果を確認しょう

ストアに入ってみます おお！ 先ほどストアは空っぽでしたが すべての商品が陳列され なかなかの見栄えになりました たった1行のコードで Appの商品をApp Storeにリクエストでき 受け取ったメタデータのみに基づいて商品を グループ化して並べ替え ストアのUIを簡単に構築できました これで商品が揃いましたが 購入ボタンをタップしても反応しません ストア内の購入メソッドが働いて いないからです StoreKitで購入を開始する必要があります それも簡単 商品について購入メソッドを 呼び出すだけです

Rossが述べたように StoreKit 2はSwiftの新しい並行処理機能を 使用するようにゼロから構築されました Appに購入のコードを保持してすべての 購入結果を同じコンテキスト内で 処理できるので 読みやすいコードになります 購入が完了すると購入結果が返されます この購入結果から購入の成否がわかり エラー以外の完了状態もわかります ユーザが購入をキャンセルしたかあるいは 購入に追加の銀行の認証または保護者の承認が 必要かどうか といったことです 各ケースに対応するために切り替えていきます

購入結果が成功の状態ならば 検証結果も届きます 検証結果は検証済みか未検証かの いずれかです StoreKit 2では取引タイプにJWSペイロードが含まれ それが署名済み取引を表します AppがStoreKit 2から取引を受信するたびに 取引は検証プロセスを通過してこの端末のAppが App Storeによって署名済みかどうかを 確認します 噂は本当でした StoreKit 2が取引検証までやってくれます もちろん検証結果をどう処理するかは ビジネスニーズに合わせて自分で決められます このAppでは受け取った取引検証結果を 確認することにします checkVerifiedメソッドをストアに作っておけば どの検証結果にも使用できます

結果が未検証な場合 failedVerificationエラーとして Appの他の部分にアラートします 結果が検証済みの場合 取引をラップ解除して呼び出し元に返します 購入結果についてこのcheckVerifiedメソッドを 使用できます

最後に取引を検証したら ユーザにコンテンツを配信します

ユーザがコンテンツを受け取ったら StoreKitに取引を終了するように指示する 必要があります

次いでUIを更新できるようにそれを返します

Appにはアカウントデータベースがあります AppがApp Storeの署名済み取引を取得したら 常に情報を利用できるように Appに現在ログインしているユーザを StoreKitの購入に含めたいと思います そのためにはログインアカウントのトークン版で appAccountToken購入オプションを作成し そのオプションを購入メソッドに渡します

よし これで購入メソッドの実装ができました Appを再実行しましょう

ストアに戻ってみると かなり冒険心が沸いてきました 前々から1台欲しかったので バイクを買うことにします StoreKitからの支払いシートに 購入が適切に始ったことが示されています タップして購入を確認します するとStoreKitから 購入成功のアラートが表示されます アラートを閉じると 購入ボタンが緑色のチェック印に変わります これはAppが取引が信頼され バイクが 配達されることを示します もう1つ重要な注意点があります 先ほど述べたように お客様が購入を完了する前に アカウントの追加検証や 保護者の承認が 必要になることがあります そういった場合 product.purchaseから受信する購入結果は 保留状態になります つまり お客様によるアカウント検証後 または保護者の承認後にAppのUIを更新して 完了した購入を反映する必要があります このような取引の更新を検知するには 取引タイプの静的プロパティを 繰り返し処理する必要があります

このプロパティは無限のasyncシーケンスです つまり forループをキャンセルするか 中断するまでStoreKitから受け取る 取引更新を繰り返し処理します ここではデタッチタスクを作成することで ストアの割り当てが解除された時点で 更新リスナーを明示的にキャンセルするための タスクハンドルを返します StoreKit 2から受け取るすべての取引と同じように コンテンツをユーザに配信する前に検証結果が 検証されているかどうかを確認したいと思います 使用するのは前に定義したメソッドcheckVerified

そして購入レスポンスの場合と同様に 検証済み取引を取得したらコンテンツをユーザに 配信する必要があります

そしてもちろん 常に取引を終了する必要があります 非常に重要なのはAppを起動したら取引を1つも 見逃さないようにすぐに 取引更新リスナーを起動することです ストアの作成後すぐにこれを用意し Appの起動直後に実行されるようにします

更新リスナーをテストするためには Xcodeテスト環境でAsk To Buyを有効にして 保留状態の購入レスポンスを シミュレーションします StoreKit構成ファイルを選択してEditorメニューで Enable Ask To Buyを選択します Appを再実行してもう一度購入しましょう

今回は支払いシートの確認後にStoreKitから 購入を完了するには許可を求める必要があるという 新しいアラートが表示されます 先に進んでAskをタップします 保留状態のAppに購入リクエストが 返ります 購入を承認するにはXcodeのTransaction Managerで StoreKit Testを開いて右上にある Approveボタンをクリックします

すばらしい！ 取引の承認直後に更新リスナーが 検証結果を受け取りすぐにUIが変わり 承認された購入が表示されました さて今度はドライブ用の5人乗りの新車です ここまでで 商品のリクエスト購入の開始 さまざまな購入結果への対応 取引整合性の検証App Storeから保留取引に 関する更新の受け取りがいかに簡単かを ご覧いただきました　すべてStoreKit 2 1つでこと足ります ではRossに再登場願いユーザの取引履歴と サブスクリプションステータスの 扱い方を紹介してもらいましょう おお 新しいAPIが実際に動作するのを 見るのは感動的です そして自動検証これ以上のものが あるとすれば 暗号化が欲しいことと 自らデータ検証したいことでしょうか 心配いりません StoreKit 2の自動検証でセキュリティの水準は 上がりますがそれは人的検証責任を完全に 置き換えることを意図したものではありません いつものようにセキュリティの土台は 強度 時間 複雑さのスペクトルです 検証については後ほど耳寄りな情報をお伝えします 私と同じでStoreKit 2のトランザクションに 胸を躍らせている方々は まずそれらを扱えるように 新しく用意された数々の方法を知りたいでしょう ユーザの取引履歴で 完了した取引をクエリするための 新しいAPIセットを追加しています StoreKit 2では1回のAPI呼び出しで ユーザの過去すべての取引に アクセスできます 商品の最新取引にもアクセスできます 最も最近のサブスクリプションの 更新記録を見たければそれも可能です そして知っておくべき最も重要なことは ユーザが今まさにどの商品にお金を払ったかです 私たちは その情報をCurrentEntitlements という1つの機能にまとめました Current Entitlementsにはユーザの取引履歴 すべての非消耗型ならびに 現在アクティブなすべての サブスクリプション取引が 含まれます Appでユーザが支払ったすべてについて ロック解除に必要なすべての情報が得られます これはユーザにとって 現在アクセスが必要なもののみを表すので 呼び出された取引は 応答に含まれません 消耗型も含まれません 取引履歴の永久的部分ではないからです 皆さんは早く自分のAppで呼び出したくて 待ちきれない気分でしょう StoreKit 2では それまでにAppでユーザが完了した どの取引でも要求すればすぐに手に入ります つまりユーザが新しい端末に Appをインストールして 初めてAppを開いた時点でどの商品に アクセスする権利があるかがわかります しかも取引履歴はユーザ全員の端末で 自動的に更新されます 顧客が1台の端末で買い物をすると 同じAppをインストールしてある 他のすべての端末でその買い物を確認できます 実際 購入時にAppが 別の端末で動作していれば 新しい取引について通知が届きます Appの起動直後に取引をリッスンすることの 重要性をJakobが述べましたが これもその理由の1つです つまるところAppを 新しい端末に再インストールや ダウンロードする際に 過去にユーザが完了した取引を 復元する手間がいらないわけです 何もかもがStoreKitでフェッチされ 最新状態が保たれます しかしAppleデバイスは使う人によって 用途も場所もさまざまです まれにユーザが実行したはずの取引が 表示されないことがあります その場合App Store sync APIを使います そうすればStoreKit 2 の 全取引がすぐに再同期します これはrestoreCompletedTransactions API に代わるものであり AppにUIを用意すればユーザが 同期を開始できます しかしStoreKit 2の自動同期のおかげで ユーザによる手動同期が 必要なケースはごくまれです 自動同期で大半のケースがカバーされます それでも手動同期をしようとするユーザは アカウントの認証が必要です こうした理由で このAPIはユーザ入力への応答としてのみ ご使用ください 最後に StoreKit 2 APIで実施した取引はすべて 初期のStoreKit APIでも利用でき 逆もまた同じです Appに既存の取引があれば StoreKit 2 APIの使用開始と同時に 既存の取引が表示されます 初期のStoreKit APIで実行した 新規購入の情報は StoreKit 2 APIを介してすぐに利用でき StoreKit 2で実行した購入は統合レシートを 更新すればそこにも表示されます StoreKit 2には取引履歴のほかに ユーザのサブスクリプションステータスに 関する詳細を 取得する方法も追加されています サブスクリプションステータスには 3つの部分があります 1つ 目は最新取引です このサブスクリプションで最後に発生した取引を すぐに表示できるので便利です 前に述べた最新取引の 呼び出しと同じです 2つ目は更新の状況です これはサブスクリプションの 現状を示す列挙型です 現状でどうなっているか 知りたい場合にこの値を見てください 契約中か期限切れか 猶予期間かなどがわかります 1か所を見れば全部わかるように設計したので この値に基づいてAppの ロジックを組めば簡単です サブスクリプションステータスの 3つ目は更新情報です ユーザのサブスクリプションの 詳細すべてが表示される場所です 実際の取引がなくても変わる可能性があるデータは 取引情報には含まれません そういったすべての種類の 情報がここに表示されます 例えば 更新情報には自動更新ステータスも 含まれそれを見れば ユーザがこのサブスクリプションの 自動更新をオンに しているかどうかがわかります 自動更新が設定してある 商品IDもわかります ユーザが最近サブスクリプションを ダウングレードしたことに気付いた場合 高いグレードに戻れば特典があるという オファーを提示できます サブスクリプションが期限切れの場合 更新情報を見れば期限切れの理由がわかります 完全更新情報には これらすべてのデータに加えて もう1つの重要な特徴があります そう 暗号好きの皆さんお待ちかね 更新情報はJWSで署名されるのです！ 取引情報と同じように 更新情報はロック解除サービスと マーケティング判断の重要部です だからこそApple直送の 有効な機能であると確信していただけます それから皆さんがきっと 気になっているであろうこと そう StoreKit 2は更新情報を 自動的に検証します サブスクリプションステータスAPIについて 最後にお伝えしたいのは ステータスの配列が返ることです ユーザは同じ商品について 複数のサブスクリプションを 契約することがあるからです 例えば 商品のサブスクリプションを 申し込んだ後で ファミリー共有のサブスクリプションを 受けることがあります 配列を確認すれば 契約中の最高レベルのサービスがわかります ここでJakobに再登場を願い 取引履歴やサブスクリプションステータスAPIを 扱うAppコードを見せてもらいましょう ありがとう Ross 先ほどお見せしたAppに戻って Rossが話した新しい取引履歴と サブスクリプションステータスAPIを 使用するようにアップデートしましょう 先ほど購入したバイクに緑色のチェックが ついていないことにお気づきでしょう ストアビューからいったん離れてまた戻ると 5人乗り車にも緑色のチェックがついていません ユーザとして既に購入済みのものがわかりません この問題はStoreKit 2で簡単に片付きます いつでもAppでStoreKitにクエリをして 購入済みの商品を問い合わせれば AppのUIは最新の表示になります このStore.swiftファイルで isPurchasedメソッドは現在falseのみを返します Transaction.latest(for:)を 呼び出して解決しましょう

商品IDを渡して 最新取引を取得します このStoreKitメソッドは別の検証結果を返し 取引がStoreKit 2の検証チェックを通過したことを 示してくれます 以前に書いたメソッドcheckVerifiedで 取引が検証されラップ解除されたことを確認します

revocationDateがnilに等しいことを確認して 拒否された取引のコンテンツが 配信されていないことを確認します

また 契約期間の途中で お客様がサブスクリプションを 高いサービスレベルにアップグレードした場合 isUpgradedフラグがtrueに設定されます お客様が申し込んだ最高レベルの サービスをAppが提供している ことを確認したいので isPurchasedメソッドはアップグレードされた取引を 無視すべきです

サブスクリプション商品の場合 取引タイプのみでは全貌が見えません サブスクリプションの取引日や有効期限のほかにも 知りたいことがあります サブスクリプションの次回の更新予定日や 顧客がサブスクリプションの 自動更新をオフにしたか または次回の更新期間に サービスレベルを 変更しそうかどうかなどです これらすべての情報が手に入るように StoreKit 2にはサブスクリプション ステータスAPIがあり このSubscriptionsView.swiftファイルで StoreKitからサブスクリプションステータスを 取得してユーザに表示する処理を updateSubscriptionStatusメソッドで行います 当店のサブスクリプション商品はすべて 同じグループに属するのでどれを使っても グループの最新ステータスを取得できます ストアから1つ目のサブスクリプション商品を 選ぶことにします

商品を選べばサブスクリプションの ステータスプロパティを取得できます

簡単です Rossが述べたとおり 家族でサブスクリプションを共有しているときに ユーザが個人サブスクリプション料を 支払うことも可能です ステータスプロパティはサブスクリプションごとの すべてのステータスが入った配列を返します さてユーザは標準ティアを共有しながら 自分はProティアを契約することも可能です ユーザが契約している最高レベルのサービスに アクセスきるようにしたいので ステータスごとに繰り返します

次に ステータスに期限切れや取り消しの状態が あるかどうかを確認します それらのケースを無視して ユーザの画面に表示されないようにしたいからです 他のすべてのケースについては renewalInfoを取得して checkVerifiedメソッドを使い ストアで検証済みであることを確認します

renewalInfoの検証を確認したら サービスレベルを以前の 商品と比較します このチェックではサブスクリプションステータスに 対応する商品を取得して 以前の商品と比較し より高いティアであれば この新しいサブスクリプションに highestStatusとhighestProductを設定します すべてのステータスを確認して 最高のサービスレベルがわかったら ビューのステータスと現在の サブスクリプションを設定します

ではビルドして実行しましょう

ストアビューをご覧ください 以前に購入した商品に緑色のチェックがつき 既に持っていることがわかるので 再購入する必要はありません サブスクリプション商品を 購入するとどうなるか見てみましょう

購入を確認すると ストアの右側にステータスが表示されます StoreKit 2の組み込みAPIのみで 契約中のサブスクリプションやその更新予定を ユーザに表示できるのです さて My Carsビューですが 本来は購入した商品が表示されるはずなのに 現在は空っぽです 正しい表示にするにはすべての商品を繰り返し 処理してからそれぞれの最新の取引を取得し 取引の有効期限と 返金の有無を確認するわけですが なかなか手間がかかりそうです ありがたいことにStoreKit 2には強力で 便利なAPIが揃っておりcurrentEntitlementsは ユーザの有効な取引を取得するための シンプルで新しいAPIです My Carsビューにこのメソッドを利用し ビューの読み込み時に購入済み商品を更新します 取引アップデートと同じ要領で 現在のエンタイトルメントを繰り返します

取引アップデートと違う点は 現在のエンタイトルメントの 非同期シーケンスは有限なので forループで永久に待つことはなく さらに購入がなされると新しい エンタイトルメントが配信されます エンタイトルメントごとに 検証結果を確認したいと思います 他の取引でもそうするので

検証されたことがわかったら 当初の商品リクエストでそうしたように productTypeプロパティを切り替え エンタイトルメントを配列にふるい分けます

現在のエンタイトルメントは非消耗型と 自動更新可能な商品のみに返ることになります 他の商品タイプは無視して switch文を完成し コンパイル可能にしておきます 取引が発生したら 関連する商品をUIに表示する必要があります 非消耗型取引の場合 車商品配列を検索してこの取引に一致する 商品IDを見つけます 同様にサブスクリプション商品配列を検索して 自動更新可能な取引と一致するものを見つけます 再実行してUIを確認しましょう

My Carsビューに移動すると 購入したもの全部が表示されています 車は上の方にまとまっていて サブスクリプションは下の方 Appは今や新装開店可能となり なかなかの出来栄えです 以上 ユーザの画面に表示されるUIについて App内で情報に基づく判断を するための取引履歴と サブスクリプションステータスAPI の使い方をご説明いたしました では Rossに交代して JSON Web Signatureオブジェクトについて 詳しく説明してもらいましょう すばらしいデモでしたありがとう Jakob 新しい取引とサブスクリプションAPI群の 重宝さが皆さんに伝わったことでしょう さて StoreKit 2でJWSを使ってセキュリティを 確保する2とおりの方法をお見せしましたが 今度はJWSに注目して独自の検証を 組み込む方法をご紹介します JSON Web Signatureは3つの部分から成ります 1つ目はヘッダーで メタデータに関するオブジェクトが入っています ここには重要な情報が入っています 例えば 署名に使用するアルゴリズムとか 署名の有効性を確認する 証明書がある場所などです 現在 StoreKit 2が使用するECDSAアルゴリズムは Swift の CryptoKit で ネイティブサポートされます StoreKit 2は証明書のx5c ヘッダーを使用し 証明書チェーン全体がJWSデータに 入っていることを示します つまり JWS署名の検証に インターネット接続が要らないということです JWSデータの次の部分はペイロードです 取引ID・商品ID・購入ID・購入日などの 主な情報が入っています 署名の検証後にこの場所を読むことで 取引とサブスクリプションに関して必要なすべての データが手に入ります そしてJWSデータの最後の部分が署名自体です ヘッダーとペイロードの両方を使って生成されます JWS署名の検証は規格できちんと説明されているので 独自の実装のコードを書こうとする場合には 原本のソースをなるべくそのまま 生かすことをお勧めします このセッションの資料に リンクを載せておきました JWSデータの署名を検証した後で 署名情報がAppと現在のデバイスに 有効であることを確認するためにすべきことが 2つほどあります まず署名情報ペイロードに示された バンドルIDが AppのバンドルIDと一致することを確認します セキュリティ強化のためお勧めは APIコールに頼りきりではなく Appのどこかに AppのバンドルIDを埋め込んでおき その値をペイロード内の バンドルIDと比較することです そして最後にすべきことは デバイス検証チェックの実行です 署名情報が本当に現在のデバイスのために 生成されたものであることを確認するためです StoreKit 2 API AppStore.deviceVerificationID を使用して現在のデバイス検証IDを取り出します 次いで 署名情報からデバイス検証ノンスを 取り出して StoreKitから取得したデバイス検証IDを アペンドします この値でSHA384ハッシュを実行して結果を 署名情報のデバイス検証フィールドと比較します 一致すれば署名情報はこのデバイス用に 生成されたものであり署名情報の検証は完了です 最後にご注意ください これらの新しいJWSオブジェクトは App内課金専用です Appレシートを検証したい場合には 既存のAPIとそのプロセスを使用すべきです もちろん新しいJWSオブジェクト用に 新しいApp StoreサーバーAPIをご用意しますので サーバー上で直接検索と 検証を実行していただけます さて このStoreKit 2紹介セッションを お楽しみ頂けたなら幸いです StoreKit 2でApp内課金がより良いものになり APIはさらなる情報をもたらし 使い勝手も良くなりました 具体的には取引ごとのJSONベースの 情報オブジェクト 取引の詳細や取引履歴データを ネイティブコードで示してくれるAPI群 それを新しいサブスクリプション ステータスAPIと組み合わせれば StoreKit 2はApp内課金の豊かな 可能性を解き放ちます App内課金についてさらに学ぶには 残りのセッションをご視聴ください サーバー側のコーディングや お客様サポートを扱っています Jakobも私も StoreKit 2をご紹介でき本当に嬉しく思います WWDC21へのご参加ありがとうございます！ ♪