新しいApple PayのStoreKit2 APIは、製品、購入、トランザクション情報、トランザクション履歴、およびサブスクリプションステータス。
WWDC2021 Meet StoreKit2のApple Payの内容を確認する。
ロスルボー：こんにちは、WWDC21へようこそ。
私の名前はRossLeBeauで、StoreKitチームのエンジニアです。
今日はStoreKitについてお話します。
これは、実際には、クライアント側のコードの実装、アプリ内購入用のサーバーの構築、顧客のサポート、払い戻しの処理を支援するために設計された3つのセッションの1つです。
このセッションはMeetStoreKit 2であり、他の2つのセッションはここWWDC21にあります。
このセッションでは、クライアント側の機能と実装に焦点を当てます。
それでは始めましょう！
StoreKitがiOS3で導入されて以来、 それはあなたとあなたのビジネスに素晴らしい機会を生み出しました。
現在、4つのAppleプラットフォームに存在し、ゲームからニュースアプリ、インディーズタイトル、国際的なヒット曲まで、あらゆるものをサポートしています。
長年にわたり、Xcodeでのオファーコード、ファミリー共有、StoreKitテストなどの優れた機能を導入してきました。しかし、今年は最初に戻ることにしました。
本日は、StoreKit2をご紹介します。StoreKit 2は、iOS、macOS、tvOS、watchOSでアプリ内購入を操作するための最新の柔軟なSwiftAPIの新しいセットです。
Swiftファーストの考え方でStoreKitを見直しました。
最新の言語機能のいくつかを採用しました。async / awaitパターンを使用したSwiftの同時実行のように、シンプルでありながら強力なAPIを作成します。
また、アプリ内購入トランザクションにいくつかの大幅な更新を行い、より多くの情報と高いセキュリティを提供しながら、操作をはるかに簡単にしました。
また、ビジネスの成長に使用できるより深い洞察を提供するために、サブスクリプション専用のより強力なAPIを追加しました。
StoreKit2 APIは、現在存在する同じStoreKitフレームワーク内に存在し、すべてのAPIを置き換えるのではなく、コアのアプリ内購入エクスペリエンスに重点を置いています。
新しいStoreKit2 APIは、製品、購入、トランザクション情報、トランザクション履歴、およびサブスクリプションステータス。
今日は、これらの各領域の概要を説明します。同僚のJakobが、対応するStoreKit 2APIを実際のコードで使用する方法を紹介します。
それでは、まず、StoreKitの構成要素である製品と購入から始めましょう。
StoreKit 2製品構造体は、使い慣れたStoreKit製品オブジェクトのスーパーチャージャーバージョンです。まず、製品タイプや拡張サブスクリプション情報などの追加データを追加しました。
StoreKit 2を使用すると、顧客が紹介オファーの対象かどうかを確認するなどの作業が簡単になります。また、StoreKit2製品に新機能との上位互換性を持たせています。
これは、製品に直接添え字を付けることで製品に含まれるデータを取得できるBackingValueと呼ばれるラッピングタイプを追加することで実現しました。つまり、将来的に製品にデータを追加した場合、古いバージョンのStoreKit 2を搭載したオペレーティングシステムを実行しているSDKやデバイスでも、StoreKit2でいつでもデータにアクセスできるようになります。
つまり、最新のバージョンを使用できます。特長新機能を提供するために、あなたの顧客ベースのより大きな部分に。
StoreKit 2では、商品タイプ自体の静的関数を呼び出して商品をリクエストします。これは、既存のSKProductsRequestと同じように、AppStoreから製品メタデータを要求します。しかし、新しいSwift同時実行非同期/待機パターンのおかげで、StoreKit2製品リクエストには1行のコードしか必要ありません。
同様に、StoreKit 2で製品を購入することは、もう1つの単純な1行のタスクです。購入は、商品タイプのインスタンスメソッドになりました。
つまり、取得したばかりの商品を取得して、直接購入を呼び出すことができます。
購入方法もasync / awaitを使用するため、コードでインライン購入の結果を取得します。
これで、すべての購入が同じであるとは限らないことがわかりました。購入行動を変更したい場合デフォルト設定以外に、StoreKit2には購入オプションがあります。
購入オプションは、購入の単一のプロパティを説明するアイテムです。
購入オプションを、購入方法に渡すセットに構成できます。
StoreKit 2には、数量やプロモーションのオファーなどの購入オプションが含まれています。
また、StoreKit 2では、アプリアカウントトークンと呼ばれる新しいオプションを追加しています。アプリアカウントトークンは、アプリのどのユーザーアカウントがトランザクションを開始および完了したかを追跡するための方法です。
これは、アプリが所有するアカウントにリンクできる、生成する不透明なトークンです。アプリアカウントトークンを生成するのは簡単です、唯一の要件は、UUID形式に準拠していることです。
購入オプションとして購入時にアプリアカウントトークンを送信すると、このトークンはその購入のトランザクション情報で返されます。
アプリアカウントトークンは、デバイス間でも、トランザクション情報に永久に残ります。
アプリが独自のアカウントシステムをサポートしている場合、これは、Apple IDや購入に使用されたデバイスに関係なく、各アプリ内アカウントがどの購入を行ったかを追跡するのに役立ちます。
そこで、AppStoreから製品を入手して購入を開始することについて話しました。
その購入が完了するとどうなりますか？ご想像のとおり、StoreKitは、暗号で署名された情報とともに、成功したトランザクションを返します。
おなじみですね。さて、StoreKit 2は、これまでで最大のアプリ内購入トランザクションのアップデートをもたらします。
まず、StoreKit 2は、トランザクションごとに個別に署名されたオブジェクトを提供します。それだけでなく、StoreKit 2以降、アプリ内購入トランザクション情報は、非常に一般的で使いやすい形式であるJSONで提供されるようになります。
また、安全な暗号化署名がStoreKitの購入の重要な部分であることがわかっているため、現在、JSONWeb署名と呼ばれるWeb全体で使用される共通の標準を使用しています。
さらに、署名されたオブジェクトに含まれるすべての情報がネイティブのStoreKit APIを介して利用できるようになり、アプリのコードでこのデータを簡単に操作できるようになります。
実際、それがいかに簡単かをお見せします。これらのAPIを実際のコードでデモンストレーションしたJakobを次に示します。
ヤコブ・スワンク：こんにちは、ヤコブです。私はStoreKitチームのエンジニアです。
今日は、アプリでStoreKit2を簡単に起動して実行できることをお見せできることにとても興奮しています。
右側には、私が作成しているPocketCarsというアプリがあります。
このセッションのリソースセクションでこのアプリのサンプルコードをダウンロードして、フォローすることができます。
アプリには2つの主要なビューがあります。集めた車の眺めと店の眺めがあります。
お店に行きましょう。現在、販売可能な商品がないため、私の店は空です。
私は先に進んでそれらを今実装するつもりです。
すばやく起動して実行するために、XcodeでStoreKitテストを使用しています。
これにより、App Store Connectで製品を定義する前に、ストアを構築してテストすることができます。
私のXcodeプロジェクトでは、販売したい製品を定義するStoreKit構成ファイルをすでに作成しています。
これは、StoreKitに使用していたものと同じ構成ファイルです。
何も変更したり移行したりする必要はありません。
ここには、すべての製品IDを含むplistもあります。
アプリに組み込まれているリソースファイルとして含まれているため、実行時に使用できます。これらの商品をストアに表示するには、まず、表示する商品IDのセットを使用して商品リクエストを行う必要があります。
StoreKit 2では、Product構造体の静的メソッドを呼び出すだけでこれを実行できます。
App Storeから商品を受け取ったら、種類ごとに分けたいと思います。
Productタイプは、App Storeサーバーで定義されているタイプのプロパティを提供するようになったため、StoreKit2を使用してこれを簡単に行うことができます。
私のアプリでは、燃料、車、ナビゲーションパッケージの3種類の商品を販売しています。
燃料は消耗品です。一度使用するとなくなりますので、すべての消耗品を燃料アレイに入れます。
車は消耗品ではありません。車を購入すると、永久に所有します。
それで、私はすべての非消耗品を車の配列に入れます。
ナビゲーションパッケージは、3つのレベルのサービスを備えたサブスクリプション製品です。私の顧客は一度に1つのレベルのサービスに加入でき、定期的に請求されます。
また、サービスレベルを変更したい場合は、いつでもアップグレードまたはダウングレードできます。App Storeはサービスのレベルごとに製品を返すので、すべての自動更新可能なサブスクリプションをサブスクリプション配列に入れます。
また、各タイプの商品を最低価格から最高価格の順に並べ替えたいと思います。アプリを実行して、これまでに行ったことを確認してみましょう。
次に、ストアに移動します。
うわー！以前は私の店は空でしたが、今ではすべての商品が表示されてかなり見栄えがします。たった1行のコードで、App Storeからアプリの商品をリクエストし、受け取ったメタデータのみに基づいてそれらの商品をグループ化して並べ替えることができたため、ストアのUIを簡単に構築できました。
今では私の製品は見栄えが良いのですが、購入ボタンをタップしても何も起こりません。
それは私の店の購入方法が何もしないからです。
StoreKitで購入を開始する必要があります。
これは、商品の購入メソッドを呼び出すだけで実行できます。 ロスが述べたように、StoreKit 2は、Swiftの新しい同時実行機能を使用するためにゼロから構築されました。
これにより、アプリは購入のコードを保持し、その購入の結果をすべて同じコンテキスト内で処理して、コードを読みやすくすることができます。
購入が完了すると、PurchaseResultが返されます。このPurchaseResultは、購入が成功したかどうか、またはユーザーが購入をキャンセルしたか、購入に追加の銀行検証または親からの承認が必要かなど、他のエラー以外の状態で完了したかどうかを知らせます。
それぞれのケースを処理するために、私はそれらを切り替えるだけです。
PurchaseResultが成功状態の場合、検証結果も取得します。
検証結果には、検証済みと未検証の2つのケースが含まれます。
StoreKit 2では、トランザクションタイプには、署名されたトランザクションを表すJWSペイロードが含まれています。
アプリがStoreKit2からトランザクションを受信するたびに、トランザクションは検証プロセスを通過して、このデバイスのアプリのペイロードがAppStoreによって署名されているかどうかを確認します。
あなたはその権利を聞いた。StoreKit2がトランザクションの検証を行います。もちろん、検証結果をどのように処理するかは、完全に私と私のビジネスのニーズ次第です。
私のアプリでは、StoreKitから受け取ったこのトランザクションが検証されていることを確認します。
ここ私のストアでは、VerificationResultに使用できるcheckVerifiedメソッドを作成します。結果が未確認の場合は、自分のfailedVerificationエラーをスローして、アプリの他の部分に警告します。結果が確認されたら、トランザクションをアンラップして呼び出し元に返します。
これで、購入結果に対してこのcheckVerifiedメソッドを使用できます。最後に、トランザクションを確認したら、コンテンツをユーザーに配信します。ユーザーがコンテンツを入手したら、StoreKitにトランザクションを終了するように指示する必要があります。
次に、UIを更新できるように、それを返す必要があります。
私のアプリには、私が管理しているアカウントデータベースがあります。アプリの現在ログインしているユーザーをStoreKitの購入に含めたいので、App Storeで署名されたトランザクションを取得したときに、この情報をアプリで常に利用できます。
これを行うには、ログインしたアカウントのトークン化されたバージョンを使用してappAccountToken購入オプションを作成し、そのオプションを購入方法に渡します。OK。
購入方法の実装はすべて完了しました。アプリをもう一度実行してみましょう。
今、私たちは私の店に戻ってきました、そして私はかなり冒険的な気分です。
ずっと欲しかったのでバイクを購入します。StoreKitからの支払いシートがあり、購入が適切に開始されたことが示されています。
タップして購入を確認します。次に、StoreKitは、購入が成功したことを示すアラートを表示します。そのアラートを閉じると、購入ボタンが緑色のチェックマークに変わり、アプリがトランザクションを信頼し、バイクが配達されたことを示します。
ここで注意したいことがもう1つあります。前に述べたように、顧客は自分のアカウントで追加の検証を行う必要がある場合がありますまたは、購入が完了する前に保護者の承認が必要になります。
このような場合、product.purchase（）から受け取った購入結果は保留状態になります。
つまり、顧客がアカウントの確認を完了するか、親が承認した後、アプリは完了した購入を反映するようにUIを更新する必要があります。これらのトランザクションの更新をリッスンするには、トランザクションタイプの静的プロパティを反復処理する必要があります。
このプロパティは、無限の非同期シーケンスです。つまり、forループをキャンセルするか中断することを選択するまで、StoreKitからのトランザクション更新を繰り返し処理します。
ここでは、ストアの割り当てが解除されたときに更新リスナーを明示的にキャンセルするために使用できるタスクハンドルを返すデタッチタスクを作成しています。
StoreKit 2から受け取るすべてのトランザクションと同様に、コンテンツをユーザーに配信する前に、検証結果が検証されているかどうかを確認したいと思います。
以前に定義したcheckVerifiedメソッドを使用できます。また、購入応答の場合と同様に、確認済みのトランザクションを取得したら、コンテンツをユーザーに配信する必要があります。 そしてもちろん、私は常に取引を完了する必要があります。
アプリが起動したらすぐにトランザクション更新リスナーを開始して、1つも見逃さないようにすることが非常に重要です。これは、ストアが作成されたらすぐに実行します。
これは、アプリの起動直後に発生します。更新リスナーをテストするために、Xcodeテスト環境でAsk To Buyを有効にして、保留状態での購入応答をシミュレートします。
これを行うには、StoreKit構成ファイルを選択し、[エディター]メニューで[購入を依頼を有効にする]を選択します。アプリをもう一度実行して購入しましょう。
今回は、支払いシートで確認した後、StoreKitから購入を完了するために許可を求める必要があるという新しいアラートが表示されます。先に進み、[質問]をタップします。購入応答は、保留状態でアプリに返されます。購入を承認するには、XcodeトランザクションマネージャーでStoreKitテストを開き、右上隅にある[承認]ボタンをクリックします。
すごい！トランザクションを承認した直後に、更新リスナーが確認結果を受け取り、UIがすぐに変更され、承認された購入が表示されました。
これで、新しい標準の5人乗りで巡航できます。商品のリクエスト、購入の開始、さまざまな購入結果への対応、トランザクションの整合性の確認、からの更新の受信がいかに簡単かをお見せしました。保留中のトランザクション用のAppStore。すべてStoreKit2を使用します。
次に、Rossに戻って、ユーザーのトランザクション履歴とサブスクリプションステータスの操作の概要を説明します。
ロス：うわー！これらの新しいAPIが実際に動作しているのを見るのは非常に驚くべきことです。そして自動検証、これ以上何が欲しいですか？
あれは何でしょう？あなたは暗号化が大好きで、それでも自分でデータを検証したいですか？
心配無用。StoreKit 2の自動検証はセキュリティの水準を引き上げますが、それはあなた自身の検証を完全に置き換えることを意図したものではありません。
いつものように、セキュリティは、強度、時間、および複雑さのスペクトルにあります。
検証については、少し後で説明します。まず、私と同じようにStoreKit 2トランザクションに興奮している場合は、それらを操作するための新しい方法がたくさん提供されていることを聞いていただければ幸いです。
完了したトランザクションをクエリするための新しいAPIセットを追加しますユーザーのトランザクション履歴。
StoreKit 2では、1回のAPI呼び出しでユーザーの過去のすべてのトランザクションにアクセスできます。製品の最新のトランザクションにアクセスすることもできます。
したがって、サブスクリプションの最新の更新だけを確認したい場合は、それが可能です。そして、あなたが知る必要がある一番のことは、ユーザーが現在アクセスするために支払った製品です。
そのため、その情報をCurrentEntitlementsと呼ばれる単一の関数にまとめました。
現在の資格には、ユーザーのトランザクション履歴にあるすべての非消耗品と、現在アクティブなすべてのサブスクリプショントランザクションが含まれます。
これにより、ユーザーがアプリで支払ったすべてのロックを解除するために必要なすべての情報が得られます。
また、これはユーザーが現在アクセスできる必要があるもののみを表しているため、取り消されたトランザクションは応答に含まれません。
消耗品もトランザクション履歴の永続的な部分ではないため、含まれていません。
さて、あなたは「待ちきれません！いつアプリでこれらを呼び出し始めることができますか？」と考えているに違いありません。
そうですね、StoreKit 2を使用すると、ユーザーがこれまでに完了したすべてのトランザクションを、要求するとすぐにアプリで利用できるようになります。
つまり、ユーザーがアプリを新しいデバイスにインストールすると、次のことがわかります。アプリを初めて開いたときにアクセスできる製品。
さらに、トランザクション履歴はユーザーのデバイス間で自動的に更新されます。顧客が1つのデバイスで購入すると、アプリはインストールされている他のすべてのデバイスで購入を確認できるようになります。
実際、別のデバイスで購入したときにアプリが実行されている場合は、新しいトランザクションについて通知されます。
Jakobは、アプリが起動したらすぐにトランザクションをリッスンすることが重要であると述べました。
これは、もう1つの理由です。
つまり、これはすべて、ユーザーが完了したトランザクションを復元する必要がないことを意味しますアプリが新しいデバイスに再インストールまたはダウンロードされたとき。すべてがStoreKitによって自動的にフェッチされ、最新の状態に保たれます。
しかし、人々は何百万もの場所で何百万もの方法でAppleデバイスを使用しています。
まれに、ユーザーがトランザクションを実行する必要があると考えているのにトランザクションが表示されない場合は、AppStore同期APIを使用できます。
これにより、すべてのStoreKit2トランザクションが即座に再同期されます。
これはrestoreCompletedTransactionsAPIの代わりであり、ユーザーが同期を開始できるようにするUIをアプリに提供する必要があります。
ただし、StoreKit 2の自動同期のおかげで、非常にまれなはずです。
ユーザーが手動で同期を開始する必要があること。
自動同期は、ほとんどの場合をカバーする必要があります。
ユーザーが手動同期を開始する必要がある場合は、アカウントを認証する必要があります。
このため、このAPIはユーザー入力に応じてのみ使用する必要があります。
最後に、StoreKit 2 APIを使用して行われたすべてのトランザクションは、元のStoreKit APIで利用でき、その逆も同様です。
そのため、アプリに既存のトランザクションがある場合は、使用を開始するとすぐにStoreKit 2APIでそれらを確認できます。
元のStoreKitAPIで行われた新規購入は、StoreKit 2 APIを介してすぐに利用可能になり、StoreKit2で行われた購入はすぐに利用可能になります。
更新されると、統合レシート内でも利用できるようになります。
StoreKit 2は、トランザクション履歴に加えて、ユーザーのサブスクリプションステータスに関する詳細情報を取得する方法も追加しています。
サブスクリプションステータスには3つの部分があります。
1つ目は最新のトランザクションです。これにより、このサブスクリプションで発生した最後のトランザクションに簡単にアクセスできます。これは、前に説明した最新のトランザクションを呼び出した場合と同じです。
二つ目は更新状態です。これは、サブスクリプションの現在の状態を示す列挙です。何が起こっているのか知りたいだけなら今のサブスクリプションで、この値を見てください。現在サブスクライブされているか、期限切れであるか、猶予期間内であるかなどがわかります。この値に基づいてアプリロジックを簡単に作成できるように、1か所で確認できるように設計されています。そして、サブスクリプションステータスの最後の部分は更新情報です。ここで、ユーザーのサブスクリプションに関するすべての詳細を確認できます。このデータは実際にはトランザクションなしで変更される可能性があるため、トランザクション情報には含まれていないすべての種類の情報が含まれています。
たとえば、更新情報では、自動更新ステータスを確認できます。これにより、ユーザーが自動更新をオンまたはオフにしたかどうかがわかります。
このサブスクリプションの場合。自動更新が設定されている製品IDも表示されます。したがって、ユーザーが最近サブスクリプションをダウングレードした場合は、ここでそれを確認でき、上位Tierにとどまるためのウィンバックオファーを提示する機会として使用できます。
サブスクリプションの有効期限がすでに切れている場合は、更新情報を使用して有効期限の理由を確認できます。そして、完全な更新情報には、これらすべてのデータとその他のデータに加えて、もう1つの重要な機能が含まれています。そうです、すべての暗号化マニア、更新情報はJWSを使用して署名されています！
取引情報と同様に、更新情報はサービスのロック解除の重要な部分ですマーケティングの意思決定を行います。
だから私たちはあなたにそれが有効であり、Appleから直接であることを知っているという自信を与えています。
そして、今あなたの頭の中を駆け巡っていると確信している質問に答えるために、はい、StoreKit2は自動的に更新情報を検証します。
サブスクリプションステータスAPIについて知っておくべき最後のことの1つは、ステータスの配列を返すことです。
これは、場合によっては、ユーザーが同じ製品に対して複数のサブスクリプションを持つことができるためです。
たとえば、ユーザーが製品を購読していて、ファミリー共有を通じて購読を受け取っている場合があります。
配列を確認する必要があります彼らが受ける資格のある最高レベルのサービスが何であるかを見るために。
次に、Jakobに返送して、アプリコードでこれらのトランザクション履歴とサブスクリプションステータスAPIを操作する様子を示します。
ヤコブ：ありがとう、ロス。私が取り組んでいるアプリに戻り、Rossが今話した新しいトランザクション履歴とサブスクリプションステータスAPIを使用するように更新しましょう。
以前に購入したモーターサイクルには緑色のチェックがなく、ストアビューから移動して戻った後、標準の5人乗りにも緑色のチェックがありません。
ユーザーとして、私はすでに何を購入したのかわかりません。
私のアプリはいつでも、購入した製品をStoreKitに照会できるため、アプリのUIを常に最新の状態に保つことができます。
私のStore.swiftファイルでは、isPurchasedメソッドは現在falseのみを返します。Transaction.latest（for :)を呼び出すだけで修正できます。
次に、製品IDを渡して、最新のトランザクションを取得します。
このStoreKitメソッドは、トランザクションがStoreKit2の検証チェックを通過したことを示す別の検証結果を返します。
トランザクションが検証されたことを確認し、前に作成したcheckVerifiedメソッドを使用してラップを解除します。
次に、アプリがコンテンツを配信しないことを確認します revocationDateがnilに等しいことを確認して返金されたトランザクションの場合。
また、期間の途中で顧客がより高いレベルのサービスにアップグレードしたサブスクリプションでは、isUpgradedフラグがtrueに設定されます。
アプリが顧客がサブスクライブした最高レベルのサービスを提供していることを確認したいので、isPurchasedメソッドはアップグレードされたトランザクションを無視する必要があります。
サブスクリプション製品の場合、トランザクションタイプはストーリーの一部のみを伝えます。
取引日とサブスクリプションの有効期限に加えて、次の更新日がいつか知りたいのですが、 また、顧客がサブスクリプションの自動更新をオフにしたかどうか、または次の更新期間によってサブスクリプションされているサービスのレベルが変更されるかどうか。
このすべての情報を取得するために、StoreKit2はサブスクリプションステータスAPIを提供しています。私のSubscriptionsView.swiftファイルでは、updateSubscriptionStatusメソッドがStoreKitからサブスクリプションステータスを取得し、それをユーザーに表示する役割を果たします。すべてのサブスクリプション製品は同じグループに属しているため、それらのいずれかを使用して、グループの現在のステータスを取得できます。
ストアから最初のサブスクリプション製品を選択します。製品を手に入れたら、 サブスクリプションからstatusプロパティを取得できます。とても簡単です。
ロスが述べたように、ユーザーが家族によって共有されているサブスクリプションを持っている間に、ユーザーが自分の個人的なサブスクリプションの料金を支払うことは可能です。
したがって、statusプロパティは、各サブスクリプションのすべてのステータスを含む配列を返します。
今では、プロ層に個人的にサブスクライブしている間、標準層を共有することができます。
ユーザーがアクセスできる最高レベルのサービスを利用できるようにしたいので、各ステータスを繰り返します。
次に、ステータスの状態が期限切れか取り消されているかを確認します。
これらのケースを無視し、ユーザーに何も表示したくない。それ以外の場合はすべて、renewalInfoを取得し、ストアのcheckVerifiedメソッドを使用して検証されていることを確認します。
renewalInfoが検証されたことを確認したら、サービスのレベルを以前の製品と比較します。
このチェックでは、サブスクリプションステータスに対応する製品を取得し、以前の製品と比較します。
それが上位Tierの場合は、highestStatusとhighestProductを新しいサブスクリプションに設定します。
すべてのステータスを確認し、最高レベルのサービスを決定したら、ビューのステータスと現在のサブスクリプションを設定します。 ビルドして実行しましょう。
ストアビューで、以前に購入した製品に緑色のチェックマークが表示され、すでに所有しているため、再度購入する必要がないことを示します。サブスクリプション製品の1つを購入するとどうなるか見てみましょう。
購入を確認すると、ストアにステータスが表示されます。StoreKit 2に組み込まれているAPIを使用して、ユーザーが何をサブスクライブしているのか、いつサブスクリプションが更新されるのかをユーザーに知らせることができます。
では、このMyCarsビューはどうでしょうか。購入したすべての製品が表示されるはずですが、現在は空です。これを記入するために、すべての製品を繰り返し処理してから、それぞれの最新のトランザクションを取得し、トランザクションの有効期限と返金されているかどうかを確認できますが、それは大変なことのように思えます。
ありがたいことに、StoreKit 2の機能と新しいシンプルで便利なAPIを使用して、ユーザーの有効なトランザクションをすべて取得できます。currentEntitlementsと呼ばれます。
My Carsビューで、ビューがロードされたときに購入した製品を更新するこのメソッドがあります。トランザクションの更新と同様に、現在の資格を繰り返し処理します。
ただし、トランザクションの更新とは異なり、現在のエンタイトルメントの非同期シーケンスは有限であるため、forループで永久に待機することはなく、ユーザーがさらに購入すると新しいエンタイトルメントが配信されます。
資格ごとに、他のすべてのトランザクションと同じように検証結果を確認したいと思います。
検証済みであることがわかったら、productTypeプロパティを切り替えて、資格をさまざまな配列にフィルタリングします。
元の商品リクエストで行ったのと同じです。現在の資格では、非消耗品および自動更新可能な製品のトランザクションのみが返されます。
他の製品タイプを無視して、switchステートメントを完成させ、Swiftコンパイラーを満足させることができます。
トランザクションを取得したら、関連する製品をUIに表示する必要があります。非消耗品のトランザクションについては、cars製品配列で、このトランザクションに一致する製品IDを検索します。同様に、サブスクリプションの製品配列を検索して、自動更新可能なトランザクションと一致させます。もう一度実行して、UIを確認してみましょう。
これで、[マイカー]ビューに移動すると、購入したものがすべて表示されます。
私の車はすべて上部にグループ化されており、サブスクリプションは下にあります。
今、私のアプリは完全に機能するストアを持っており、それは素晴らしく見えます！
これが、トランザクション履歴とサブスクリプションステータスAPIを使用して、ユーザーに表示されるUIについてアプリ内で情報に基づいた決定を行う方法です。
それでは、JSONWeb署名オブジェクトについてさらに詳しく説明するRossに戻りましょう。
ロス：素晴らしいデモをありがとう、ヤコブ。新しいトランザクションAPIとサブスクリプションAPIがどのように役立つかを実際に確認できます。
StoreKit 2がセキュリティのためにJWSを使用する2つの方法を見てきましたが、それを詳しく見て、独自の検証を行う方法を検討することを約束しました。
JSONWeb署名は3つの部分で構成されています。
1つ目はヘッダーで、オブジェクトに関するメタデータが含まれています。これには、署名に使用されるアルゴリズムや、署名の検証に使用される証明書の場所などの重要な情報が含まれています。
StoreKit 2は現在、CryptoKitを使用してSwiftでネイティブにサポートされているECDSAアルゴリズムを使用しています。
証明書の場合、StoreKit 2はx5cヘッダーを使用します。
これは、証明書チェーン全体がJWSデータに含まれていることを示します。
これは、インターネット接続が必要ないことを意味しますこれらのJWS署名を検証するため。
JWSデータの次の部分はペイロードです。
これは、トランザクションID、製品ID、購入日などの主要な情報です。
署名を検証したら、ここでトランザクションまたはサブスクリプションについて知りたいすべてのデータを読み取ります。
そして、JWSデータの最後の部分は署名そのものです。
これは、ヘッダーとペイロードの両方を使用して生成されます。JWS署名の検証は、標準の十分に文書化された部分であるため、独自の実装を作成することに興味がある場合は、元のソースに直接アクセスすることをお勧めします。
このドキュメントへのリンクをリソースに含めましたこのセッションに関連付けられています。
JWSデータから署名を検証したら、署名された情報がアプリと現在のデバイスで有効であることを確認するために、さらにいくつかのことを行う必要があります。
まず、署名された情報ペイロードに存在するバンドルIDがアプリのバンドルIDと一致することを確認する必要があります。
セキュリティを強化するために、API呼び出しに依存するのではなく、アプリのバンドルIDをアプリのどこかに埋め込み、その値を使用してペイロードのバンドルIDと比較することをお勧めします。
そして、最後にすべきことは、デバイス検証チェックを実行することです。これにより、署名された情報が実際に生成されたことが保証されます現在オンになっているデバイスの場合。
StoreKit 2 API AppStore.deviceVerificationIDを使用して、現在のデバイス検証識別子を取得します。
次に、署名された情報からデバイス検証ナンスを取得し、StoreKitから取得したデバイス検証識別子を追加します。
この値に対してSHA384ハッシュを実行し、その結果を署名された情報のデバイス検証フィールドと比較します。それらが一致する場合、署名された情報がこのデバイス用に生成され、署名された情報の検証が完了します。
最後に注意すべき点は、これらの新しいJWSオブジェクトはアプリ内購入専用であるということです。したがって、アプリの領収書を検証する必要がある場合は、そのために既存のAPIとプロセスを使用する必要があります。
そしてもちろん、これらの新しいJWSオブジェクト用の新しいApp StoreサーバーAPIを提供しているため、サーバー上で直接それらを取得して検証できます。
さて、今日紹介したのと同じように、StoreKit2に会えて興奮していたことを願っています。
StoreKit 2は、より多くの情報を提供し、かつてないほど使いやすい新しいAPIを使用して、アプリ内購入をさらに改善しています。
これには、各トランザクションの新しいJSONベースの情報オブジェクトと、ネイティブコードでトランザクションの詳細と履歴トランザクションデータを提供するAPIが含まれます。
それを新しいサブスクリプションステータスAPIと組み合わせて、StoreKit 2は、アプリ内購入のさまざまな可能性を解き放ちます。
アプリ内購入の詳細については、サーバー側のコーディングと顧客のサポートに関するこれらの他のセッションをご覧になることをお勧めします。
Jakobと私はStoreKit2を紹介できることに興奮しています。WWDC21にご参加いただきありがとうございます。♪
コメント