StoreKitとアプリ内課金の新機能

こんにちは Rudyです StoreKitの新機能を紹介し App Store Serverライブラリと 新しいStoreKit 2 APIを 開発のワークフローに 組み込む方法を説明できる のを嬉しく思います まず StoreKitの新しいコアフレームワーク 機能について紹介します 次に App Store Serverライブラリを使って アプリ内課金のリクエストに 署名する方法を説明します

最後に SwiftUIとStoreKitビューを 使ってアプリ内でサブスクリプションの 販売促進を行う新しい方法を確認します

始めに 重要な次の3つのデータ型に 関するアップデートについて説明します AppTransactionとTransaction RenewalInfoです これらのデータ型によりアプリの 購入に関する情報を取得でき 購入履歴の監視やサブスクリプションの ステータスの管理ができます AppTransactionは アプリの最初の 購入に関する情報を提供します これにより 最初の購入日や お客様がダウンロードした アプリのバージョン App Storeでのリリース前にお客様が アプリの予約注文をした日がわかります appVersionを使うと 例えば お客様に アプリのアップグレードを促す メッセージを表示して 最新バージョンを 実行してもらうことができます AppTransactionを取得するには AppTransaction.shared APIを使用し 検証済みの結果を使用します StoreKitは自動的にAppTransactionの JSON Web Signatureを検証し verificationResultに 検証済みの値を返します 検証済みのAppTransactionとは AppTransactionにApp Storeの署名が あること および対象のアプリと お客様のデバイスに関する情報であることを StoreKitが確認できたことを意味します 皆さんのビジネス戦略策定に役立つように サブスクリプションやオファーに関して できる限り多くの情報を提供したいと 私たちは考えています 今年は AppTransaction型に 2つのフィールドを追加しました iOS 18.4の時点で AppTransaction型に appTransactionIDフィールドが含まれます これはiOS 15までさかのぼって導入されます appTransactionIDは アプリをダウンロードした 各Apple Accountに対応する グローバルに一意な値です ファミリー共有に対応するアプリでは appTransactionIDは ファミリー共有 グループのメンバーごとに一意でもあります appTransactionIDを使用すると サーバ間呼び出しを使用せずに 個別のオリジナルトランザクションIDを 関連付けることなどが可能になります

iOS 18.4ではoriginalPlatform フィールドも導入されました originalPlatformはAppStore.Platformと 呼ばれる新しいデータ型です この値は お客様が最初に そのアプリを購入した プラットフォームを示します iOS、macOS、tvOS またはvisionOSです この値はApp Store Connectで使用可能な ターゲットプラットフォームと一致します watchOSでダウンロードしたアプリの場合 originalPlatformフィールドの値はiOSです originalPlatformフィールドを使用すると 有料アプリからアプリ内課金ありの 無料アプリへの移行など ビジネスモデルの変更に簡単に対応できます originalPlatformフィールドは 時間とともにビジネスが変化しても 適切な権限をお客様に 付与するのに役立ちます 次に Transaction型が アップデートされています Transactionは 正常に処理された アプリ内課金を示し 購入に関する有益な情報を含んでいます Transactionには 購入の日時と アプリ内課金のプロダクトIDに加え 自動更新サブスクリプションの場合は サブスクリプションの有効期限が含まれます お客様の権限を確認して コンテンツの ロックを解除するのが主な用途です アプリでは productIDフィールドを使って ロックを解除するコンテンツを識別します 購入が正常に完了した直後 または Transaction.currentEntitlementsなどの トランザクションシーケンスの1つを介して Transactionが生成されます Transactionの取得方法にかかわらず Transactionは AppTransactionと同様 必ずverificationResultにラップされます そのため Transactionの検証を 手動で行う必要はありません StoreKit 2によって自動で処理されます エンタイトルメントについては iOS 18.4以降 productIDに対する Transaction.currentEntitlement APIは 非推奨となり 新しい Transaction.currentEntitlements APIに置き換えられています productIDを渡して新しいAPIを呼び出します このAPIは 非同期の Transactionのシークエンスを返し それによりお客様に 対象プロダクトの権限が付与されます 例えば お客様がサブスクリプションに 登録していて ファミリー共有でも 同じプロダクトにアクセスが可能な場合など 複数のトランザクションでプロダクトの 権限が付与される場合もあるため プロジェクトにこのAPIを 取り入れることをお勧めします 今年の新機能として Transactionモデルに 3つのフィールドが追加されています

iOS 15にさかのぼって導入される appTransactionIDフィールドは アプリのダウンロードトランザクションを 示す一意の識別子です これは 先ほど説明した AppTransaction型に含まれているのと 同じ値です iOS 18.4では Offer Periodフィールドも 導入されました これは Offerに含まれるメンバーです Offer Periodは 購入時にお客様が 利用したサブスクリプションオファーに 関連付けられたサブスクリプション期間です iOS 18.4で新たに導入されたフィールドの 最後はadvancedCommerceInfoです AdvancedCommerceInfoは Advanced Commerce APIを使用する アプリにのみ適用されます Advanced Commerce APIを使用しない アプリではこのフィールドは 必ずnilになります Advanced Commerce APIにより 大規模なコンテンツカタログや クリエイターエクスペリエンス オプションのアドオン付きサブスクリプションに 関するアプリ内課金の対応が容易になります Advanced Commerce APIをサポートするため StoreKit 2では iOS 18.4で利用可能なAdvancedCommerceProduct などの新しいネイティブAPIと TransactionやSubscriptionStatusなどの 既存のAPIが提供されます Advanced Commerce APIの詳細については このセッションのWebページリソースの 一覧をご覧ください 最後に RenewalInfo型の 変更点を確認しましょう RenewalInfo型は 自動更新サブスクリプション用です RenewalInfoには サブスクリプションが 自動更新されるかどうか 次のサブスクリプション更新の日時 サブスクリプションが期限切れの場合は 有効期限が切れている理由 などの情報が格納されます この有効期限切れの理由の 使用方法の例としては 最近サービスの価格を引き上げていた場合の 期限切れの理由は didNotConsentToPriceIncreaseです この場合は ウィンバックオファーを アピールして 再度サービスのサブスクリプションを 購入するよう促すよい機会となります StoreKitでは SubscriptionStatusインスタンスの ラップされたVerificationResultのメンバー としてRenewalInfoの値を利用できます SubscriptionStatusを 取得するにはいくつかの方法があり SubscriptionStatus.updates APIを 使用する方法や StoreKitで サブスクリプションのグループIDを使って ステータスを照会する方法があります 注意事項として StoreKitで サブスクリプションのグループIDを使って サブスクリプションステータスを 照会する場合は ビジネスモデルの規定に沿って 最上位のサービスレベルを提供する サブスクリプションのステータスをもとに アプリのサービスへのアクセスを提供します Transaction IDを引数に取る SubscriptionStatus APIも iOS 18.4からの新機能です これにより StoreKitでサブスクリプションに 関連付けられた任意のトランザクションの トランザクションIDを指定して サブスクリプションステータスを照会できます 今年は RenewalInfo型に4つの フィールドが追加されています appTransactionIDはiOS 15まで さかのぼって導入され Offer PeriodおよびadvancedCommerceInfo フィールドはiOS 18.4以降で利用できます サブスクリプションと対象サービスの ユーザーアカウントを関連づける appAccountTokenフィールドも追加されます オプションで PurchaseOptionの appAccountTokenを使って 購入時にappAccountTokenを 付与できます App Storeでは サブスクリプションに 関連付けられたRenewalInfoで この新しいappAccountTokenフィールドと 同じ値が返されます 最新のXcodeを使ってアプリを開発すると 新しいフィールドにアクセスできます これらの新しいフィールドにより アプリ開発がさらに容易になり より良いカスタマーエクスペリエンスを 実現する助けになると思います ここからは オファーコードについてお話しします これは英数字のコードで サブスクリプションを一定期間 割引価格または無料で 提供するためのものです お客様は App Storeで1回限りのコード利用 URLを使用するか またはStoreKit APIの offerCodeRedemptionが実装されていれば アプリ内で オファーコードを使用できます オファーコードが 消耗型アイテム 非消耗型アイテムおよび 非自動更新サブスクリプションに 使用できるようになります offerCodeRedemption APIを 使用することにより お客様はアプリ内で オファーコードを使用できます アプリでUIKitを使用する場合は presentOfferCodeRedeemSheet APIを使います 消耗型アイテム 非消耗型アイテムおよび 非自動更新サブスクリプションでの オファーコードの使用は iOS 16.3にさかのぼって可能になります offerCodeRedemptionが正常に実行されて 生成されたTransactionは StoreKit 2 APIを使用する すべてのOSバージョンで使用できます アプリでさらに以前のOSバージョンを サポートしている場合 iOS 14.2までさかのぼって 自動更新サブスクリプションの オファーコードの使用が可能です 自動更新サブスクリプション以外の プロダクトタイプ用の オファーコードの使用に対応するため Transaction.Offer.PaymentMode型に 新しい支払いモードが導入されています これは オファータイプに応じて オファー期間中に どのようにお客様への 請求が行われるか または行われないか を示します 様々な支払いモードがあり 例えばfreeTrialは支払いが不要の場合です 他の支払いモードとしてpayAsYouGoと payUpFrontがあります iOSでは アプリ内課金のオファーコードで oneTimeの支払いモードを iOS 17.2までさかのぼって 使用できるようになります アプリで17.2より前のOSバージョンを サポートする場合 この新しい支払いモードにアクセスするには Transactionの offerPaymentModeStringRepresentation メンバーを使用します これはiOS15までさかのぼって利用できます アプリ内課金のオファーコードの設定の 詳細については 2025年のセッション 「App Store Connectの新機能」を ご覧ください また iOS 18.2以降では StoreKitに UIコンテキストを必要とする purchaseメソッドが追加されています システムがデバイスのアクティブなシーンの 直感的にわかりやすい領域に ペイメントシートと成功のダイアログを 表示できるように 購入が行われるUIコンテキストを アプリで指定する必要があります これらの新しいpurchaseメソッドは iOS 18.2以降および対応するリリースで 使用できます 指定するUIコンテキストは プラットフォームによって異なります iOS、macCatalyst、tvOS、visionOSでは UIコンテキストはUIViewControllerです macOSでは NSWindowです watchOS向けの開発では UIコンテキストを指定しません SwiftUIビューからの購入の場合は この計算を行うのは デベロッパではありません purchaseのEnvironment値を読み出して PurchaseActionインスタンスを取得します purchaseを実行する準備ができたら 直接 PurchaseActionインスタンスを 呼び出します ここで インスタンスを呼び出したときに Swiftが呼び出す callAsFunctionメソッドが 定義されているためです StoreKitビューを使用している場合 UIコンテキストの指定を行う 必要はありません

システムで自動的に処理されます ProductView、StoreView SubscriptionStoreViewを使って お客様向けに卓越したアプリ内課金の エクスペリエンスを 実装する方法については WWDC23のセッション 「SwiftUI向けのStoreKitについて」を ご覧ください ここまで コアAPIの機能強化について 説明しました ここでもう1つの重要なアップデートに 話題を移しましょう 今年は JSON Web Signatureを必須とする 新しいAPIが導入されています その新しいAPIについて また 開発ワークフローで App Store Serverライブラリを使って 署名プロセスを簡素化する方法を 見ていきましょう 今年の新機能として PurchaseOptionの introductoryOfferEligibilityを使って お試しオファーの利用条件を設定できます また 新しいPurchaseOptionの promotionalOfferでJWS形式を使用して プロモーションオファーに 署名することもできます これらの新しい購入オプションはいずれも コンパクトなJWS文字列を必須とし iOS 15までさかのぼって導入されます また これらの各購入オプションに対応する 新しいSwiftUIビュー修飾子も 導入されています JWSを使用すると プロモーションオファーや お試しオファーの利用条件の設定など 特定のユースケースについて 購入を承認したことを App Storeで検証するのに役立ちます リクエストへの署名をできる限り 簡単にするために 署名のプロセスを簡素化する App Store Serverライブラリなどの 優れたオープンソースツールがあります アプリ用の署名済みリクエストの作成が 短時間でできることを確認するため SKDemoでプロモーションオファーに 署名する方法を見てみましょう 始める前に まずApp Store Connectから アプリ内課金の署名鍵を 取得する必要があります それには 「ユーザーとアクセス」タブを開き 「統合」の見出しをクリックして

左側のナビゲーションで 「アプリ内課金」を選択します 任意のアクティブなキーを使用するか 新しいキーを作成します Issuer IDとアプリ内課金キーのキーIDを 記録しておくとよいでしょう アプリ内課金キーを用意できたので SKDemoでアプリ内サブスクリプション ストアを見てみましょう このサブスクリプションストアでは お客様が購入できる プランを扱っています サブスクリプションの期限が切れている お客様に再購入してほしいと考える場合 新しいJWSベースの subscriptionPromotionalOffer修飾子を使い Proプランのプロモーション オファーを宣伝します この修飾子ではクロージャを2つ指定します 1つ目のクロージャでは 所定のサブスクリプションの 購入に対して適用される サブスクリプションオファーを指定します この例では 前に作成しておいた ヘルパーメソッドを使って Proプランの無料トライアル期間が最も長い プロモーションオファーを選択します この修飾子の2つ目のクロージャでは 署名済みオファーの詳細を含む コンパクトなJWSを指定する必要があります ここでは NetworkLayer型で提供されます この実装がどのようになるか確認しましょう このNetworkLayerでは リクエストのクエリパラメータとして プロダクトとサブスクリプションオファーの productIDとofferIDを渡します 次に サーバ上のプロモーションオファーの 署名経路に対して GETリクエストを実行します 最後に 応答をデコードします サーバプロジェクトでは 初めに App Store Serverライブラリ Swiftパッケージの依存関係を追加し AppStoreServerLibraryを インポートします プロモーションオファーの 署名リクエストに対応する 経路の実装では プロモーションの 署名コンテキストを作成します それには PromotionOfferV2SignatureCreatorを 前の手順で App Store Connectから取得した アプリのバンドルID、署名鍵 キーID、Issuer IDで初期化します 次に createSignature関数を呼び出して 購入対象の サブスクリプションのproductIDと サブスクリプションオファーの offerIDを指定します また transactionIDフィールドの値を 含めることをお勧めします この値には appTransactionIDまたは お客様に関連付けられている トランザクションのTransactionIDを 使用できます TransactionIDフィールドは省略可能ですが 値を設定することをお勧めします

アプリに戻ると プロモーションオファーを 正常に使用できるようになり 問題なく購入が完了します これが App Store Serverライブラリを 使用して 署名済みのアプリ内課金 リクエストを作成する方法です アプリ内課金リクエストへの署名は 購入が承認されていることを App Storeで検証するのに役立ちます App Store Serverライブラリとの統合により リクエストへの署名が簡単になります 何よりも App Store Serverライブラリは Java、Python、Node.js、Swiftの 4つの言語で使用できます App Store Serverライブラリの 詳細については WWDC24のセッション 「アプリ内課金のためのApp Store Server APIの詳細」をご覧ください 最後のアップデートとして SwiftUIを 使用してアプリ内でお客様とやり取りする 新しい方法を説明します StoreKitビューファミリーの新しいメンバー SubscriptionOfferViewを紹介できて 嬉しく思います これは 販売促進および自動更新 サブスクリプション用の 新しいSwiftUIビューで アプリのサービスにお客様の注目を 集められるように設計されています 読み込み済みの自動更新サブスクリプション を使用するか または自動更新 サブスクリプションのproductIDを使用して SubscriptionOfferViewを宣言します このように宣言すると App Storeから プロダクトメタデータを読み込む処理は すべてビューによって行われます オプションで App Store Connectで設定した サブスクリプションの画像を使用して ビューを装飾できます それには prefersPromotionalIconフラグに trueを設定します システムでサブスクリプションの メタデータの読み込みが完了すると 装飾のアイコンが表示されます ビューの装飾にカスタムの アイコンを使用するには このAPIの代替表記を使用して トレイリングクロージャの ViewBuilderに渡します カスタムプレースホルダアイコンの指定も できます これは サブスクリプションの メタデータがApp Storeサーバから ダウンロードされている間表示されます SubscriptionOfferViewでは 個々のサブスクリプションプランの 販売促進ができるだけではありません subscriptionOfferViewDetailAction という新しい修飾子と組み合わせると このビューを使用して 例えば アプリ内のサブスクリプションストアに お客様のトラフィックを振り向けられます この修飾子を宣言するとビューに detailLinkボタンが描画されます お客様がdetailLinkボタンをタップすると ビューの呼び出しで この修飾子へのパスが閉じられます こちらはSKDemoの例です アプリのユーザーフローの表示方法を 制御するContentViewの状態を 少し変更します お客様がdetailLinkボタンをタップすると アプリのサブスクリプションストアに 移動し 購入可能なサブスクリプションプランが 表示されます このAPIの使用を決定する際に 重要な検討事項は どのサブスクリプションを販売するか そもそもこの表示が必要かどうかです コードに戻って このAPIの使用方法の 一例を確認しましょう SubscriptionOfferViewで販売する サブスクリプションプランを 判断するには お客様のサブスクリプションステータスを 確認することから始めます SwiftUIで開発されたアプリの場合 これを行うのに最適な場所は Appプロトコルの実装です このデータを使用して ビュー階層の 残りの部分に情報を伝えます それには iOS 17で導入された subscriptionStatusTask修飾子を 宣言します 次に この修飾子でStoreKitの サブスクリプションステータスを アプリで扱えるモデルに変換します SKDemoでは このモデルは SKDemoPlusStatusという名前です 次に ステータスを追跡するビューで 信頼できる情報源を更新し 環境変数を使用して environmentで販売します

お客様のステータスを確認できたら それを利用して ContentViewで SubscriptionOfferViewを表示します ここでは お客様の状態が格納された environmentの値を読み出し お客様がサブスクリプションを 利用中でない場合はスタンダードプランを サブスクリプションを利用中の場合は 上位のプランを宣伝します コードを簡潔にするため グループIDのイニシャライザを使って SubscriptionOfferViewを作成します このように宣言すると システムにより 自動的にサブスクリプショングループから プランが選択されます また お客様の現在のプランに対する 宣伝対象のプランの関係性を 指定する必要があります visibleRelationshipパラメータには upgrade、downgrade、crossgrade、current allの5つのうちいずれかの値を使用します このAPIの動作は お客様のステータスによって異なります それぞれのrelationshipについて詳しく 見てみましょう 最初はupgradeです デモの都合上 この例のお客様は 中間レベルのプランのサブスクリプションを 購入しているものとします upgradeを指定すると ビューで 現在のプランより1つ上のレベルの サブスクリプションプランが宣伝されます downgradeのrelationshipでは その逆になります この例では サブスクリプションを 登録済みのお客様と登録解除済みの お客様に同じプランが表示されます 自動更新を無効にしたお客様に 更新サイクルが終了する前に 再度購入してもらいたい場合は より手頃なプランを宣伝すると よいでしょう crossgradeのオプションでは グループ内に含まれる 現在のプランと同等レベルの 各プランを検討したうえで 最も価値の高い選択肢が選択されます currentのrelationshipでは お客様の現在のプランが 宣伝されます 使用できるサブスクリプション オファーが存在する場合を除き デフォルトではすべての インタラクションが無効になっています お客様にオファーの利用資格が あるかどうかのマーキングには オファーの修飾子を使用します 新しいsubscriptionPromotionalOffer 修飾子や preferredSubscriptionOffer 修飾子があります relationshipの活用方法としては サブスクリプション登録者を維持するため 有効期限間近のサブスクリプションについて 割引の宣伝をすることが考えられます 最後は allのrelationshipです このrelationshipではすべての お客様に対する動作が同じになります このように初期化すると グループ内の すべてのプランの価格情報が ビューに表示されます ビューで実行されるアクションを 指定するには subscriptionOfferViewDetailAction 修飾子を宣言します SubscriptionOfferViewの作成に どのrelationshipを使用しても カスタムアイコンやプレースホルダ アイコンを使って装飾できます このセッションの前半の例と同様です アプリのアイコンを使用するための 便利な方法もあります useAppIconフラグをtrueに設定するだけです 新しいSubscriptionOfferViewの説明は 以上です お客様に効果的に働きかけることができます ここでは様々なStoreKit APIの 機能強化を取り上げました お客様に素晴らしいアプリ内課金の体験を 提供するためにお役立てください StoreKit 2をまだプロジェクトに 導入していない場合は ぜひ導入して これらの新機能を活用してください アプリに最新のデザインを取り入れ すばらしいストアを構築するために StoreKitビューを使用して アプリ内課金や サブスクリプションの宣伝をしましょう アプリ内課金リクエストへの署名を できる限り簡単にするには GitHubのApp Store Serverライブラリを 確認し プロジェクトに組み込みます App Store Server APIの詳細については 新しいWWDC25のセッション 「アプリ内課金のためのApp Store Server APIの詳細」をご覧ください StoreKit 2の導入については WWDC21の セッション「StoreKit 2について」が 入門編として最適です ご視聴ありがとうございました 皆さんがStoreKitで どのような体験を構築するか楽しみです