[Apple Pay]アプリ内購入の新機能2022

Apple Payアプリ内課金の新機能を知る

iPhone、iPad、Mac、Apple Watchアプリで素晴らしいアプリ内購入体験を作りましょう。

払い戻しを処理する方法
新しいApp Storeサーバー通知を統合する方法
領収書とサーバー通知を使用して加入者ステータスを管理する方法

また、Apple Watchでのアプリ内課金、ファミリー共有、SKOverlay、SKAdNetworkなど、StoreKitの最新のアップデートについても説明します。

こんにちは、WWDCへようこそ。

こんにちは、WWDCへようこそ。私はToriです。また、同僚のRossと一緒にプレゼンテーションをします。

アプリ内購入であなたに新しいものを共有することにとても興奮しています。

そして、今日はカバーすることがたくさんあります。

このセッションは2つのセクションに分かれます。

サーバー側の最新情報をカバーすることに集中します。

そして後で、StoreKitのアップデートをカバーするためにロスに渡します。

では、サーバーのアップデートを始めましょう。

サーバー側では、まず払い戻しと、返金された取引の処理方法について説明します。次に、顧客のサブスクリプションステータスを管理するのに役立つ新しい方法と、App Storeサーバー通知を使用して通知を受け取り、さまざまなサブスクリプション請求イベントに応答する方法について説明します。

また、最新のステータスを取得するために領収書の確認を使用する必要があるさまざまなシナリオも説明します。そして最後に、ファミリー共有に飛び込みます。私たちはカバーすることがたくさんあるので、間違いなく今日私たち全員をここに連れてきたもの、アプリ内購入に飛び込みましょう。

だから、これは私のアプリの1つでアプリ内購入です。これを使うのがとても楽しみです。しかし、気が変わったら、コンテンツに問題があり、Appleに電話して払い戻しを要求した場合、開発者として何をすべきですか?そのため、払い戻しの処理はとても重要です。しかし、それは重要ですが、取引のごく一部にしか影響しないことに注意してください。しかし、適切な払い戻し管理により、その割合が低下する可能性があります。

では、典型的な払い戻しのシナリオを見て、それに飛び込みましょう。

まず、顧客は100 Gemsのようなアプリでいくつかのコンテンツを購入します。

しかし、購入は事故だったので、彼らはサポートのためにアップルに電話します。彼らのケースを検討した後、私たちは払い戻しを行います。その後、顧客は返金された宝石がまだあることに気付いたので、サポートのためにあなたに連絡します。

Appleがコンテンツを返金したことを知らない場合、どのように対応するかを判断することは困難です。適切に行動を起こすことができるように、すでにその購入を返金したかどうかを簡単に判断できれば、はるかに良いでしょう。

払い戻しを認めるが、顧客に宝石を保管させたり、残高を差し引いたりするなど。そのため、コンテンツの払い戻しを管理する新しい方法を提供するために取り組んでいます。返金された購入を管理する能力を持つことは、多くの理由で重要です。

最も重要なことは、あなたが適切だと思うように行動を起こすためのコントロールを与えることです。顧客にメッセージを送ったり、必要に応じてコンテンツを取り戻したりするなど。また、Appleから払い戻しを受けた後にコンテンツを保持しようとする顧客など、コンテンツの潜在的な悪用にも対処できます。また、前のような顧客の問題を迅速に解決できます。

これにより、ゲーム内の経済を管理することができ、払い戻しに影響があるため、すべてのプレイヤーにとってゲームプレイをより公平にすることができます。したがって、これらすべての理由から、アプリでの購入の払い戻しを管理できるようにしたいので、新しいApp Storeサーバー通知と、自動更新可能なサブスクリプション以外のコンテンツタイプに対する史上初の通知をお届けします。払い戻し通知。

では、なぜ私たちはこれに対するApp Storeサーバーの通知を決めたのか。主な理由は、私たちに情報を求める必要がないからです。私たちはただあなたに話します。ステータス変更時にJSON投稿ですぐに通知され、HTTP OKが返ってこない場合は、最大3回再試行します。サブスクリプションの自動更新に関するApp Storeサーバー通知をすでに受信している場合は、他のコンテンツタイプの新しい払い戻し通知が届きます。

また、記録を更新できるように、キャンセルされた取引を含む更新された統一領収書をお送りします。また、このソリューションは、当社のプラットフォームでビジネスを成長させるにつれてスケーラブルです。したがって、すべてのコンテンツタイプの目標は、App Storeサーバー通知を通じて返金された購入に関する情報を入手できるようにすることです。消耗品、非消耗品、非更新サブスクリプションの場合、まったく新しい払い戻し通知が届きます。サブスクリプションの場合、引き続きキャンセル通知を受け取ります。

App Storeサーバー通知を有効にすることは、これまでにやったことがなく、いくつかのステップで実行できる場合は簡単です。まず、通知とApp Store Connectの希望するエンドポイントを設定します。次に、開発者ドキュメントに概説されているように、エンドポイントがアプリトランスポートのセキュリティ要件を満たしていることを確認してください。その後、通知の受信を開始する準備が整います。

App Store Connectでは、アプリページに移動して、App Storeサーバー通知セクションのURLを見つけるだけです。通知の送信先がわかるように、ここにご希望の終了地点を入力してください。エンドポイントがすでにセキュリティ要件を満たしている場合は、すぐに通知を受け取り始めることを知ってください。では、払い戻し通知を詳しく見てみましょう。

消耗品、非消耗品、または非更新のサブスクリプションがアプリの返金されたときに、その購入に対して顧客に払い戻しを行った後、この通知をお送りします。この方法で通知を受けると、返金されたコンテンツに対してすぐに行動を起こすことが容易になります。この通知は、購入についてすでに持っている顧客に関する情報のみを提供していないため、プライバシーに配慮した方法で実装されています。払い戻し通知は今日公開されているので、すでにApp Storeサーバー通知を受信している場合は、それを探していることを確認してください。この通知を受け取ったときにそれを念頭に置いて、ペイロードで注意してほしいことがいくつかあります。

original_transaction_idを探して、どのトランザクションを返金したかを指示する必要があります。返金した日とキャンセル理由を知るためのキャンセル日。理由は0または1の値を持つことができ、1の値は、あなたが調査できるアプリ内の問題のために顧客が払い戻しを要求したことを示すことができます。また、入札とproduct_idを探して、通知を受け取ったアプリと製品を確認します。これらのフィールドはすべて、App Storeサーバー通知ペイロードと最新_receipt_infoセクションのunified_receiptオブジェクトにあります。ペイロードの最上位レベルにある入札を除きます。では、App Storeサーバーの通知はどのようなものですか。まあ、こんな感じです。すべてのフィールドがここにリストされているわけではありませんが、開発者ドキュメントにすべての可能なフィールドの説明があります。

今、先ほど話し合ったものと、他にもいくつか見てみましょう。これらのトランザクション識別フィールドに加えて、パスワードとペイロードを探します。これは、App Store Connectを見つけることができるアプリの共有秘密であり、ペイロードがAppleからのものであり、信頼できることを確認することができます。パスワードと同じレベルで、バンドル識別子があります。このフィールドを確認して、どのアプリが払い戻しを受けたかを知ることができます。

次に、払い戻し取引に関する情報については、特に最新の_receipt_info配列のunified_receiptオブジェクトを参照してください。この配列には、アプリの100件の最新のトランザクションと、お探しの4つのフィールド、キャンセル日、キャンセル理由、元の取引ID、製品IDが含まれています。それでは、以前の払い戻しシナリオを再検討し、払い戻し通知がわずかに異なる状況でどのように役立つかを見てみましょう。この状況では、顧客はまだ100個の宝石を購入しますが、宝石を消費し、それでもAppleに購入のサポートを求めています。

もう一度、お客様が宝石を消費したかどうかわからないため、払い戻しを尊重するか拒否するかを決定します。私たちはまだ払い戻しを尊重する可能性があり、その場合は払い戻し通知をお送りします。その後、顧客があなたに連絡し、ゲーム内補償などのさらなるサポートを求めた場合。しかし、これで、購入が返金されたことがわかり、アプリにアプリ内メッセージを提供するなどの積極的な行動を取ることを選択できます。

このようなメッセージは、購入の払い戻しを観察したことを顧客に通知するので、素晴らしいです。あなたが取った行動と、コンテンツへのアクセスを取り戻すために彼らができること。アプリ内メッセージングは、払い戻しを観察する際に実行できる多くのアクションの1つにすぎません。今、それらを簡単に見てみましょう。したがって、中程度から重度のコンテンツタイプに応じて、実行できるアクションはたくさんあります。

すべてのコンテンツタイプで、払い戻しの監視に使用できます。アプリ内メッセージングと返金された購入へのアクセスの制限。サーバーからサーバーへの通知を送信しているため、必要に応じてクロスプラットフォームへのアクセスを制限することができます。

消耗品の場合、アプリ内の通貨残高を差し引くなど、実行できる追加のアクションがあります。開発者として、どのような措置を講じるか、どのように実装するかを決定する責任があります。だから、アプリ内で健全なコミュニティを促進するために、どの行動を取ることにしたかを慎重に考えてください。だから今、私たちは払い戻しとそれらを適切に扱う方法について多くのことをカバーしました。では、ギアを切り替えて、サブスクリプションの管理を容易にする方法に飛び込みましょう。まず、サブスクリプションライフサイクルの重要なイベントのいくつかを見てみましょう。

これらには、初めて加入者の獲得、自動更新の成功または失敗、自動更新のアップグレードまたはダウングレードおよびキャンセルの無効化または有効化が含まれます。では、これらすべてのイベントは、顧客とあなたにとってどのように見えますか。したがって、お客様が最初に購読するときは、更新後に更新を繰り返すために、サブスクリプション期間と固定自動更新期間を確立します。最初のサブスクリプション期間内に、顧客はサブスクリプションを十分に使用していないと思って自動更新をオフにすることを決定しますが、後でサブスクリプションでもう少し時間後にオンに戻します。

その後、最初のスケジュールされた自動更新に近づきます。しかし、請求の問題により自動更新の失敗があります。この時点で、請求再試行期間中の自動更新を試みます。また、猶予期間を確立します。幸いなことに、サブスクリプションは猶予期間中に回復されるので、更新サイクルは同じままです。その後まもなく、顧客はサブスクリプションを楽しんでいるため、アップグレードしたいと判断します。アップグレードのために、私たちはすぐにより高い層で顧客を開始し、今後の更新をシフトします。

後で、その高い層を期待どおりに使用しなかった後、顧客はより基本的な層にダウングレードすることにしました。ダウングレードはサブスクリプション期間の終了時に行われます。そのため、お客様は、次のスケジュールされた自動更新まで、より高いレベルのサービスにアクセスできます。では、サブスクリプションのこれらの重要なイベントをすべて追跡するにはどうすればよいですか。推奨されるのは、ステータスの更新にApp Storeサーバー通知を使用することです。これはプッシュアプローチです。

つまり、何かが起こったときに伝える情報を求めません。そして、私たちはそうします。サブスクリプションのステータスが変更されたときに通知し、その時点で記録の新しい領収書を提供しますが、必要な場合にのみ通知します。このソリューションは、より多くの加入者を必要とするため、よりスケーラブルになります。だから、今、App Storeサーバーの通知を掘り下げて、私たちが提供しているものを見て、それらについてもう少し学びましょう。

App Storeサーバーの通知を受け取り始めたとき、またはすでに受信している場合。これはあなたが期待できるペイロードです。これは可能なフィールドのサブセットであり、これらのすべてが常に存在するわけではないことに注意してください。ここにはたくさんの情報があるので、いくつかの重要な要素に焦点を当てたいと思います。このペイロードを受け取ったら、まずauto_renew_product_idを探して、通知が適用される製品と、次に自動更新する予定の製品を正確に確認します。

次に、notification_typeを確認してください。これは、あなたが受信しているイベントの種類を教えてくれるでしょう。また、値とパスワードフィールドが共有秘密と一致することを確認する必要があります。だから、あなたはコンテンツがAppleから直接来て、信頼できることを知っています。バンドル識別子も探す必要があります。これにより、どのアプリに通知が届いたかがわかります。

次に、unified_receiptを探したい場合、このオブジェクトはverify receiptからの応答を模倣するので、すでにverify receiptを使用している場合は、これは馴染みがあるはずです。unified_receiptオブジェクトの latest_receiptは、アプリのこの顧客の最新の精度を提供します。 latest_receipt_info配列には、アプリの100の最新のトランザクションが含まれています。元のトランザクションIDでここで検索して、この顧客のどのサブスクリプションがアクティブかを知ることができます。

最後に、pending_renewal_info配列を見て、顧客がアプリで使用している各サブスクリプションの今後の更新情報を見つけます。それでは、通知タイプフィールドをすばやく再検討しましょう。いくつかのイベントの通知を送信し、通知タイプフィールドは次の可能な値を持つことができます。顧客が最初に購読したときのINITIAL_BUY。

顧客がアプリまたは管理されたサブスクリプションを通じてサブスクリプションをアップグレードまたは更新するときのINTERACTIVE_RENEWAL。DID_CHANGE_RENEWAL_STAUS お客様が自動更新のオン/オフを切り替えるなどの更新ステータスを変更した場合。DID_CHANGE_RENEWAL_PREF 顧客がダウングレードなどのサブスクリプション期間の終了時に行われる変更を行った場合。

お客様がAppleサポートに電話したときにキャンセルし、以前の下位層のサブスクリプションをキャンセルしたため、サブスクリプションまたはアップグレードの払い戻しを行います。請求の問題により、予定通りに自動更新に失敗した場合のDID_FAIL_TO_RENEW。そして、DID_RECOVERは、請求再試行期間または猶予期間にサブスクリプションの請求を回復するとき。

これらの通知の詳細と、いつ観察できるかについては、WWDC 2019セッション「アプリ内購入とサーバー間通知の使用」を参照してください。また、サンドボックスで利用可能な通知の詳細については、こちらをご覧ください。今年のセッション「Introducing StoreKit Testing in Xcode」をチェックしてください。したがって、以前からタイムラインに戻ると、これらのイベントのほとんどすべてをカバーする通知があります。サブスクリプションの購入のための最初の購入は、無効化と自動更新の更新のステータスを変更しましたが、更新失敗の更新に失敗し、請求の回復、アップグレードのインタラクティブな更新、以前の下位層のサブスクリプションのキャンセルを回復し、ダウングレードの更新設定を変更しました。そのため、App Storeサーバーの通知を使用すると、サブスクリプションイベントを簡単に監視できます。しかし、私たちはこれを少しだけ良くすることができると決めました。そのため、今年は自動更新が成功するたびにApp Storeサーバー通知をお知らせします。

これは、DID_RENEWと呼んでいる新しい通知タイプです。今年後半に、自動更新が成功するたびに、毎回この通知をお送りします。他のすべての通知と同様に、更新されたサブスクリプションを識別するために必要なすべての情報を提供する統一された領収書が含まれています。これには、サブスクリプションの一意の識別子である元のトランザクションIDが含まれます。トランザクションID、新しいサブスクリプション期間の一意の識別子。新しい期間の有効期限と自動更新製品IDは、どの製品が自動更新されたかを正確に伝えます。

だから、私たちのタイムラインに戻ってください。更新通知の追加により、イベントが完了し、App Storeサーバー通知でサブスクリプションを監視するために必要なすべてをもたらすことに注意してください。しかし、この新しい通知に加えて、サブスクリプションに関してもう少し情報が必要だと思いました。そのオファーでサブスクリプションを更新する前に、顧客の1人がサブスクリプションオファーを適用することを決定したかどうかを知っておく必要があると思います。

そのため、保留中の更新情報セクションにプロモーションオファーIDを追加しました。これは、確認領収書とApp Storeサーバー通知と保留中の更新情報配列で利用できるので、そのサブスクリプションに保留中のオファーがあるかどうかを知ることができます。この機能は、今日保留中の更新情報セクションで公開されています。

だから、あなたがそれを探していることを確認してください。サブスクリプションオファーの使用の詳細については、こちらをご覧ください。WWDC 2019セッション「サブスクリプションオファーのベストプラクティス」をご覧ください。保留中の更新情報に更新通知とプロモーションオファーIDがあったので、この新しい情報で何をすべきですか？最も重要なことは、更新のためにApp Storeサーバーの通知に頼ることができ、領収書を確認するポーリングの必要性を排除します。

ただし、いくつかの重要なユースケースでは、確認レシートを使用する必要があります。次回顧客の1人がオンラインになったときにサーバーで停止が発生した場合は、領収書の確認に電話してステータスを確認できます。見逃した更新を埋め合わせる。

このようにして、リカバリモードのレシートオファーを確認します。次に、領収書の確認を使用して、顧客の資格をすぐに決定できます。資格の決定の詳細については、今年のサブスクリプションセッションのアーキテクトを視聴してください。

最後に、領収書の確認を使用して、自動更新が成功したことを確認できます。では、検証済みの領収書を使用して自動更新の成功を確認するとはどういう意味ですか。なぜなら、自動更新はとても重要だからです。アップデートを確実に入手したい。このため、ダブルチェックで自動更新をマークするアプローチです。

まず、App Storeサーバーの通知を購読すると、他の通知タイプに加えて更新通知が届きます。2つ目は、予定された有効期限の直後にサブスクリプションの領収書を確認するための電話をスケジュールします。期待どおりに更新通知を受け取ったら、このジョブをキャンセルできますが、遅延がある場合は、自動更新が成功したことを確認するために領収書を確認するためにフォールバックすることができます。

そこで、App Storeサービスの通知とサブスクリプションについて多くのことを取り上げました。それでは、App Storeサブスクリプションの新機能について話し合いたいと思います。News PlusやApple Arcadeなどのサブスクリプションについて、顧客が最も気に入っていることの1つは、家族と共有できることです。さて、今年、アプリストアがアプリ内購入のファミリー共有をサポートし、最大5人の追加家族が1回の購入を共有できることを発表できることを非常に嬉しく思います。

ファミリー共有は、自動更新サブスクリプションと、フル機能のロック解除を提供するために使用されるような非消費可能なアプリ内購入の両方で機能します。お客様は、家族と共有したいアプリ内購入を選択します。私たちは、これが開発者にとって何を意味するのか、そしてすでに設定されている何百万人もの家族を巻き込む能力にとても興奮しています。

家族の使用は非常に広く採用されているため、アプリ内購入のためのファミリー共有は、顧客エンゲージメントを高め、アプリの保持を向上させるのに役立ちます。まず、App Store Connectにアクセスして、特定の製品のファミリー共有をオンにすることができます。アプリページに移動し、「ファミリー共有」セクションで「オンにする」を選択できます。

一度製品のファミリー共有をオンにすると、それをオフにすることはできないことに注意してください。顧客が共有購入をどのように管理するかを見てみましょう。新規顧客が購読すると、サブスクリプションはデフォルトで共有されます。購読者は、後で管理されたサブスクリプションページで家族のために共有をオフにすることができます。

既存の購入者の場合、サブスクリプションの1つが共有可能になった場合に通知されます。その後、同じ管理対象サブスクリプションページから共有設定を管理できます。非消耗品の場合、顧客が設定で「家族と購入を共有」をオンにしている場合、すべての購入は家族と共有されます。では、アプリで何をする必要がありますか。

家族が共有購入にアクセスできるようにします。この機能を使用すると、購入者のトランザクションを作成するだけでなく、家族ごとにトランザクションも作成します。したがって、家族がアプリを開くと、各デバイスのトランザクションキューで利用可能なトランザクションがあり、最新のレシート情報配列に共有トランザクションを含む各ファミリーメンバーの一意のレシートがあります。

サブスクリプションの場合と同様に、各家族の元のトランザクションIDを追跡する必要があります。これは、共有が有効になった後に行われた新規購入にのみ適用されることに注意してください。共有が有効になる前に行われた非消耗性の購入については、家族全員が利用できるように購入を復元する必要があります。それでは、これが新しい購入者にとってどのように見えるかのアイデアを手に入れましょう。

App Store Connectでファミリー共有を有効にした後、家族が共有可能な購入を行うと、デバイスのトランザクションキューにトランザクションを入れるだけでなく、家族全員、すべてのデバイスのトランザクションキューにトランザクションを入れます。そのため、家族が後でアプリを開くと、サブスクリプションまたは非消耗性へのアクセスを即座にロック解除できます。それは魔法のようなものです。そして、これまで以上に多くの開発者に簡単にリーチできます。先に進む前に、サブスクリプションと非消耗品の両方の新規加入者と既存の加入者の両方について、これがどのように見えるかをすばやく確認しましょう。

したがって、新規購入者の場合、購入した共有可能なサブスクリプションは、デフォルトで家族と共有されます。iCloudで購入共有が有効になっている場合、購入した共有可能な非消耗物は家族と共有されます。家族が支払いを共有していて、アプリが購入履歴から隠されていない場合。共有可能なサブスクリプションを家族と共有するための既存の購入者は、管理されたサブスクリプションページからオプトインする必要があります。

既存の非消耗品を共有するには、同じ3つの条件を満たす必要があり、家族のコンテンツのロックを解除するために購入を復元する必要があります。家族全員のアクセスを管理するには、領収書を使用する必要があります。確認領収書またはApp Storeサーバー通知から更新された領収書を入手できます。さらに、お客様がアプリを開くたびに、デバイス上の領収書を更新して、各顧客のアクセスを確認できます。しかし、私はここで自分自身を先取りしています。それで、StoreKit内のファミリー共有についてもっと話す同僚のロスに引き渡します。

ありがとう、トリ。それでは、ファミリー共有のアプリ内購入がアプリ内でどのように機能するかを見てみましょう。まず、アプリが製品がファミリー共有をサポートしているかどうかをどのように確認できるか。さて、SKProductにisFamilySharableという便利な新しいプロパティを追加しました。App Storeに製品情報をリクエストし、このisFamilySharable booleanをチェックするのと同じくらい使いやすいです。

これを使用して、製品の1つが家族で共有可能であり、ロジックをハードコードする必要がないことをプログラムで顧客に表示できます。だから今、あなたの顧客の1人がこの家族の共有可能な製品を見て、それを購入するためにタップしました。次に何が起こりますか?さて、顧客が家族で共有可能なアプリ内購入を購入すると、すべてが通常どおりに始まります。アプリはStoreKitを使用して購入をApp Storeに送信し、購入日にトランザクションが戻ってきます。次回、家族がアプリを開くと、各家族は復元された購入のように見えるトランザクションを取得するので、既存のアプリロジックは追加のコーディングなしで処理できるはずです。今、Toriは、顧客が特定の製品の共有を有効または無効にすることもできると述べました。お客様が製品のファミリー共有を有効にすると、購入に似たことが起こります。彼らの家族のデバイスはすべて、復元された購入のように見えるトランザクションを取得します。だから、再びあなたのアプリは追加のコーディングなしでそれを処理できるはずです。反対のケースはどうですか。お客様がファミリー共有を無効にした場合はどうですか。

通常、非消耗品は永続的であり、自動更新サブスクリプションは有効期限が切れたときにのみ終了します。しかし、顧客がファミリー共有を無効にすると、アクセスがすぐに停止されることを期待しています。したがって、この場合、新しいAPIを追加しました。
これは、paymentQueue(didRevokeEntitlementsForProductIdentifiers:)と呼ばれるSKPaymentTransactionObserverプロトコルの新しい方法です。顧客がファミリー共有を無効にすると、StoreKitは自動的に領収書を更新し、このメソッドを呼び出します。メソッド内では、ローカルまたはサーバーにアップロードしてレシート確認エンドポイントを使用してレシートを検証する準備をする必要があります。

取り消された製品は、領収書にはなくなります。
次に、単に配列内の製品識別子を見て、それに基づいてアクセスを取り消すのではなく、確認する必要があります。お客様が購入した製品やその他の製品のセットアップによっては、取り消された購入と重複するアクセス権が引き続き付与される場合があります。そこで、ファミリー共有によって発生するいくつかの新しい状況を処理するために、このAPIを追加しました。私が述べたように、購入者が製品のファミリー共有を無効にしたときに呼び出されます。また、顧客が購入を共有していた家族グループを離れる場合にも呼び出されます。また、この機会に払い戻しのサポートを追加しました。顧客が非消耗または自動更新サブスクリプションの払い戻しを受けた場合、StoreKitはこの方法を呼び出し、すぐにアクセスを取り消すことができます。そして、それはユーザーが気に入ると思うファミリー共有を締めくくります。

そして、顧客への価値を高め、エンゲージメントとリテンションを向上させる新しい機会を提供します。それでは、StoreKitに追加した他のいくつかの改善点や機能、そして最新のリリースで楽しみにしていることをご案内します。まず、昨年のWWDC以来、すでに出荷したものをいくつか捨てます。Apple Watchでアプリ内購入を行い、ストアのサブスクリプション価格の上昇フローを改善しました。次に、SKOverlayやSKAdNetworkの改善など、新機能に移ります。だから、この最初のものは、特にそこにいるすべてのApple Watch開発者のためのものです。

今年初めのwatchOS 6.2の時点で、watchOSにStoreKitとアプリ内課金を追加しました。これは、アプリの場合、顧客が主に時計で使用することを意味します。顧客がすでに使用しているwatchOSインターフェイスで、アプリ内購入を直接提供できます。
watchOSでStoreKitを使用することは、他のプラットフォームでの使用とほぼ同じです。
支払いキューを観察し、製品をリクエストし、他のプラットフォームと同じように支払いキューに追加できます。領収書の検証に関しては、もちろん、サーバーからサーバーへの検証を引き続き使用できます。

ただし、ローカル検証を行うことを好む場合は、注意すべき違いが1つだけあります。デバイス識別子を取得するときは、UIDeviceを使用する代わりに、WKInterfaceDevice APIを使用する必要があります。以下は、iOSとwatchOSの両方で実行されるコードの例です。デバイス識別子を取得すると、他のすべては同じです。そのデバイス識別子とレシートのPAKE値を使用して、ハッシュを作成します。次に、ハッシュが領収書のハッシュと一致することを確認してください。

そして、watchOSアプリにアプリ内購入を追加するために知っておくべきことはそれだけです。 iOS 13.3で展開したもう1つの機能は、サブスクリプション価格の上昇への対応の改善です。サブスクリプション価格の上昇は、より多くの料金を請求したい既存のサブスクリプション製品がある場合に発生します。

値上げの設定は簡単です。App Store Connectにアクセスして価格を変更するだけですが、顧客に伝えずに自動更新サブスクリプションの価格を上げることはできません。そのため、App Storeでは各顧客が新しい価格に同意する必要があります。サブスクリプションの価格を下げた場合、顧客は行動を起こして新しい価格を自動的に見る必要がないことを知っておく必要があります。残念ながら、顧客に通知し、新しい価格に同意するように依頼するこのプロセスは、解約につながる可能性があります。チャーンは、顧客があなたの製品の使用を中止し、もはやそれを支払うのをやめたときです。そして今、あなたはよく考えています。もちろん、顧客はこれ以上お金を払いたくありません。しかし、実際には多くのケースで発見され、それは問題ではありません。

お客様は、App Storeが送信するメールを見逃すことがあります。あるいは、彼らはその時点で値上げの流れを望んでいないか、関与していないかもしれません。
そして時々、彼らはそれを後まで延期し、単に忘れます。さらに、顧客は、あなたが提供している付加価値について知らされないかもしれません。たとえば、ビデオサービスを実行し、新しいコンテンツを追加した場合。そのため、アプリを使用している値上げを経験しているユーザーのために、自動アプリ内値上げ同意書を実装しました。App Store Connectで値上げを開始した後、影響を受ける顧客は、アプリを開くときにこのApp Store UIが表示されます。このようにして、顧客は通知され、アプリを使用しているときにサブスクリプションを継続することに同意することができます。これは、おそらく彼らがあなたの製品に価値を見つけていることを意味します。彼らがシートに同意または却下すると、アプリのUIはその下にあり、通常どおり継続します。今、すべてのアプリが開いたときにすぐにシートを表示したいわけではないことに気付いたので、フローを制御できるようにいくつかのツールを追加しました。まず、この新しいSKPaymentQueueデリゲートメソッドを実装します。

StoreKitは、価格同意書を提示する前に、常にこのメソッドを呼び出します。
メソッド内では、今すぐシートを表示するかどうかを判断し、表示する場合はtrueを返し、表示しない場合はfalseを返すのはあなた次第です。
ここでfalseを返すと、後でより適切な時間にシートを表示する方法が欲しくなります。おそらく、あなたが提供している付加価値について顧客に教育した後です。
これを行うには、この他の新しいStoreKit APIを呼び出すだけです。SKPaymentQueue.showPriceConsentIfNeededNowは、以前に上記のメソッドにfalseを返した場合にのみ、これを呼び出す必要があります。しかし、あなたがそれを呼び出し、保留中の値上げがない場合は、心配しないでください。StoreKitは、シートを表示する前に、常に顧客に保留中の値上げがあることを確認し、表示されない場合はまったく表示されません。次に、最新のiOSリリースでまったく新しいAPIを紹介できることを嬉しく思います。

それはSKOverlayと呼ばれ、アプリを表示および宣伝するための洗練された新しいUI要素です。
見てください。SKOverlayは、UIの下部にフローティングビューを表示し、アプリに関する情報を表示します。 SKOverlayがアプリのUIとシームレスに連携するように設計されていることを除いて、今日のStoreKitに存在するSKStoreProductViewControllerクラスに似ています。さらに、SKStoreProductViewControllerとは異なり、SKOverlayはアプリの表示にのみ使用されます。

SKOverlayはまた、アプリクリップからフルアプリにユーザーを移行できるように、アプリクリップとシームレスに連携するように設計されています。しかし、それが使用されるのはそれだけです。完全なアプリ内でも完全に使用できます。表示したいアプリのアプリIDを入力するだけで、顧客はオーバーレイから直接インストールできます。新しいアプリクリップ機能について詳しく知りたい場合は、今年のWWDCの両方で「アプリクリップの探索」セッションと「アプリクリップエクスペリエンスを合理化」セッションをチェックすることを強くお勧めします。それでは、SKOverlay APIに飛び込んで、SKOverlayをアプリにうまく統合する方法を見てみましょう。SKOverlayの作成と提示はかなり簡単です。まず、SKOverlay設定オブジェクトを使用して初期化します。後でその設定オブジェクトに戻りますが、基本的にオーバーレイの詳細を設定できます。

次に、オーバーレイを表示したいウィンドウシーンで渡す現在のメソッドを呼び出します。SKOverlayを作成して提示するために必要なのはそれだけです。もちろん、オーバーレイフローをカスタマイズできるように、他の多くのツールも追加しました。まず、オーバーレイを手動で閉じることができる閉じる機能があります。この却下関数はクラス関数であり、引数としてオーバーレイを取るのではなく、別のUIWindowSceneを取ることに気づくでしょう。これは、一度に1つのオーバーレイしかシーンに表示できないため、これを行うと、現在のコードコンテキストが特定のオーバーレイオブジェクトにアクセスできない場合でも、シーンにある可能性のあるオーバーレイを削除できます。SKOverlayにはデリゲートもあります。

予想通り、このデリゲートを使用すると、オーバーレイステータスの変更に反応できます。
その詳細は後ほど見てみましょう。そして最後に、SKOverlayには設定オブジェクトがあります。これにより、設定に使用された設定を確認できます。構成に戻ったので、これら2つのオブジェクトを見てみましょう。SKOverlayは実際には2つのクラスで構成されています。1つ目はAppClipConfigurationと呼ばれ、この設定はユーザーをアプリクリップからフルアプリに移行するために使用されます。AppClipConfigurationは、オーバーレイが表示されている現在のアプリクリップの完全なアプリのみを表示できます。次のクラスはAppConfigurationです。そして、この設定は、任意のアプリを表示するために使用できます。

これら2つのクラスの多くは同じです。では、そこから始めましょう。どちらのクラスにもキャンペーントークンとプロバイダートークンがあり、アプリ分析でSKOverlayを使用できます。また、任意のキー値を設定して取得できる機能もあります。現在、ほとんどの開発者はこれらを使用する必要はありませんが、SKOverlayをSKAdNetworkなどの他のStoreKit APISと統合できます。

どちらのクラスにもポジションプロパティがあります。SKOverlayは常に画面の下部に表示されますが、タブバーを使用するアプリは、オーバーレイがタブバーの上ではなく、すぐ上に表示されるように、bottomRaisedプロパティを選択したいと思うでしょう。これらのプロパティと機能に加えて、アプリの構成は、これらの上に2つの追加のプロパティも提供します。

まず、アプリの識別子です。これを使用して、表示したいアプリのiTunes識別子を入力できます。AppClipConfigurationには、前に述べたように、その設定はオーバーレイが入っている現在のアプリクリップの完全なアプリを表示するためにのみ使用されるため、このプロパティはありません。また、アプリ設定には、ユーザーが無視できるブール値もあります。これはデフォルトでtrueに設定されています。つまり、ユーザーはオーバーレイを下にスワイプして画面から閉じることができます。これをfalseに設定すると、ユーザーは下にスワイプできなくなります。

そして、オーバーレイは、 dismiss関数を手動で呼び出す場合にのみ消えます。構成はそれだけです。では、デリゲートに移りましょう。最初のデリゲートメソッドは、単にエラーハンドラです。オーバーレイを表示しようとすると、予期しないエラーが発生すると、オーバーレイと特定のエラーを引数として渡すこのデリゲートメソッドが呼び起こされます。残りのデリゲートメソッドはすべて、オーバーレイのアニメーション化を回転しています。プレゼンテーションの開始と終了、および解雇の開始と終了の方法があることがわかります。

また、これらの各メソッドにSKOverlay TransitionContextオブジェクトが含まれていることも確認できます。これらのメソッドは、オーバーレイと一緒にUIアニメーションを調整するために使用されるためです。オーバーレイを提示し、これらのAPIを使用してアニメーションを調整する方法を見てみましょう。ここでは、アプリクリップ内でSKOverlayを作成して提示しています。まず、現在のウィンドウシーンをつかみ、次に下部の位置を使用してアプリクリップの設定を作成します。次に、その設定オブジェクトを使用してオーバーレイを初期化し、そのデリゲートを設定します。最後に、そのシーンでオーバーレイを提示します。

そして、アプリやアプリクリップでSKOverlayを使用するために必要なのはこれだけです。
オーバーレイと一緒に独自のUIをアニメーション化したい場合。デリゲートメソッドを使用してこれを行うことができます。まず、デリゲートメソッド内で直接UI要素の初期状態を設定できます。これらのデリゲートメソッドは常にメインキューで呼び出されるため、その内部でUIを操作できます。次に、トランジションコンテキストのアニメーションブロック内に必要なアニメーションを追加します。

繰り返しますが、ここでアニメーション可能なプロパティの変更を宣言するだけです。このブロック内のコードはオーバーレイによってアニメーション化されるため、UIビューアニメーションブロックを使用する必要はありません。アプリクリップを最適化する場合でも、自分のアプリ内で他のアプリを宣伝する場合でも、SKOverlayはシームレスな統合と美しいUIに最適なオプションです。最後に、SKAdNetwork APIに関する最新情報をお伝えしたいと思います。iOS 11.3で導入されたSKAdNetworkは、広告ネットワークが顧客のプライバシーを尊重しながら広告の効果を測定することを可能にします。最新のiOSリリースでは、顧客のプライバシーを妥協することなく、さらに強力にしました。SKAdNetworkの概要から始めましょう。

SKAdNetworkには3人の利害関係者が関与しています。広告ネットワーク、ソースアプリ、広告アプリ。各ステークホルダーは、機能を機能させる役割を担っています。広告ネットワークは、アプリ内に広告を配置し、広告がコンバージョンをもたらすときにポストバックを受け取ります。ソースアプリは、広告ネットワークから送信された広告を表示します。また、広告アプリは広告に表示され、開封後に投稿をSKAdNetworkに送信するアプリです。

この流れを最初から最後まで詳しく見てみましょう。まず、広告ネットワークは、広告アプリの広告内にSKAdNetworkデータを配置し、App Bと呼びます。次に、この広告をソースアプリに表示し、アプリAと呼ぶことができます。ユーザーが広告をタップし、App Bをインストールして開くと、App Bはポストバックを初期化するために別のSKAdNetwork APIを呼び出す必要があります。このAPIを呼び出すと、タイマーが設定されます。

そして、そのタイマーの有効期限が切れると、ユーザーのデバイスは広告ネットワークのURLにポストバックを送信します。広告ネットワークは、Appleの公開鍵を使用して、ポストバックのデータを確認し、それが正当であることを確認する必要があります。したがって、広告を表示するときに広告ネットワークが送信する最初のデータのバンドルは次のようになります。また、Appleに登録されている広告ネットワークIDと、広告ネットワークがキャンペーンの有効性を測定するために使用できる1から100までのキャンペーンIDが含まれています。

広告に表示される広告アプリのIDが含まれています。そして、タイムスタンプがあります。このタイムスタンプは、タイムスタンプが古すぎると広告データが拒否されるため、広告が表示されるときに生成する必要があります。ノンスは、各広告インプレッションが一意であることを確認し、ダブルカウントを防ぐために使用されるランダムなUUIDにすぎません。そして最後に、このバンドル内の他のすべてのデータを使用して署名が生成され、広告ネットワークのみが広告ネットワークIDを使用して広告を開始できるようにします。

最新のiOSリリースでは、2つの新しいデータが必要です。1つ目は、現在2.0になっているバージョンです。そして2つ目はソースアプリIDです。これは、広告を表示しているアプリのIDです。次に、ポストバックAPIは、アプリの最初の起動時に広告アプリ、アプリBによって呼び出されます。この方法は、ユーザーが広告を見た後にこのアプリをインストールして起動したことを検証する暗号署名されたデータであるポストバックを生成します。このAPIへの最初の呼び出しは、デバイスにアプリのアトリビューションデータがあり、その後の呼び出しが影響しない場合、ポストバックプロセスを開始します。最新のiOS広告アプリから始めて、彼らが選択した場合、updateConversionValue APIを呼び出すことができます。

これにより、アプリはアプリで実行されたアクションを表す追加の6ビット値を追加できます。たとえば、コンバージョンを数える前に、ユーザーがアプリでアイテムを購入したかどうかを知りたいとします。この場合、updateConversionValueを呼び出すことができ、アイテムの購入をマッピングした値を含めることができます。コンバージョン値は実行時に選択されるため、App Storeサーバーで署名することはできません。

だから、それは暗号で保護されていないポストバックの唯一の部分です。0から63の間の整数としての値自体は、購入、無料トライアルへのサインアップ、レベルの完了などのアクションを表す場合があります。アプリは、このAPIを複数回呼び出して、コンバージョン値を更新できます。ただし、前の値よりも高い値のみが受け入れられます。現在保存されている値よりも低い値は、単に無視されます。

これは、誤ってより低い値でコンバージョン値を書き込むことを心配する必要がないことを意味します。では、プロセスが完了したら、StoreKitが広告ネットワークに送信するポストバックの詳細を見てみましょう。広告ネットワークIDと広告で使用されたキャンペーンID、および広告アプリApp BのIDを送信します。トランザクションIDは、コンバージョンを二重カウントしていないことを確認するために使用できるもう1つの一意の識別子です。

また、Appleの公開鍵を使用して署名を確認し、それがすべて合法であることを知ることができます。
最新のiOSでは、ポストバックにも新しい情報を追加しました。まず、バージョンを追加しました。また、顧客がアプリを初めて購入したかどうか、または以前に購入して再度インストールするかどうかを示す再ダウンロードというキーを追加しました。この以前は、SKAdNetworkはアプリの最初の購入でのみ機能していました。

したがって、再ダウンロードを追加すると、広告の有効性についてより多くの洞察を得ることができます。さらに、最新のiOSでは、ポストバックに2つの新しいオプションアイテムを追加しました。1つ目は、どのアプリがコンバージョンをもたらした広告を表示したかを把握できるように、ソースアプリのアイデアです。
そして2つ目は、広告アプリによって選択されたコンバージョン値です。

これらの最後の2つのデータが常にポストバックに表示されるとは限らないことに注意することが重要です。顧客のプライバシーを保護するために、App Storeサーバーは、これらの値を共有して投稿がそれを生成した顧客にリンクされないように計算を行います。だから、私たちはできるときにそれらを共有します。しかし、サーバーは、それらの有無にかかわらず、ポストバックを処理する準備ができているはずです。では、どうやって始めるのですか。

SKAdNetworkを広告ネットワークとして使用することに興味がある場合は、お客様の情報を登録できるようにAppleにサインアップする必要があります。組織として開発者プログラムに登録し、フォームに記入してSKAdNetworkへのアクセスをリクエストする必要があります。
それでは、公開鍵と秘密鍵のペアを生成する方法に関する指示を送信し、公開鍵と一緒にポストバックを送信したいすべてのURLを送信します。秘密鍵は絶対に送らないことを忘れないでください。常にそれを安全に保つ。その後、登録され、SKAdNetworkの使用を開始する準備が整いました。ソースアプリで、広告ネットワークで作業したい場合は、広告ネットワークIDを尋ねて、info.plistファイルに入れてください。これにより、アプリに広告を表示するときに、StoreKitが広告データを受け入れることを知っているようになります。

そして最後に、広告アプリであり、広告のコンバージョンを測定したい場合は、アプリが最初に起動したときにポストバックを初期化するように設定してください。今日は、サーバー間および顧客デバイス環境の両方で、ベストプラクティスと新機能に関する多くの情報を取り上げました。返金された購入のために、新しいサーバーからサーバーへの通知を利用できるようになりました。また、確認レシートエンドポイントをポーリングすることなく、サブスクリプション通知を使用して最新情報を取得する方法を見ました。家族間でアプリ内購入を共有する新しい方法を導入し、顧客との価値とエンゲージメントを高めるための新しいツールを提供します。クライアント側では、watchOSアプリ内で直接アプリ内購入を提供できるようになりました。そして、サブスクリプション開発者は、私たちの新しい改善されたサブスクリプション価格の上昇フローの恩恵を受けるでしょう。

アプリクリップ内での使用など、アプリを宣伝するための新しいSKOverlay APIの詳細に入りました。最後に、SKAdNetwork APIが、広告主が顧客のプライバシーを損なうことなくコンバージョンデータを収集して使用するのにどのように役立つかを説明しました。これらのツールは、アプリ内購入でビジネスを成長させ続けるのに役立つと思います。詳細については、フォーラムやラボにご参加ください。ありがとうございます。

https://developer.apple.com/videos/play/wwdc2020/10661/
https://developer.apple.com/videos/play/wwdc2020/10661/