Nouveautés dans StoreKit et les achats intégrés

Bonjour, je m’appelle Rudy. Je suis ravi de vous présenter les nouveautés dans StoreKit et de vous montrer comment intégrer la bibliothèque de serveur App Store et les nouvelles API de StoreKit 2 à votre workflow de développement. Je vais commencer par vous présenter les nouvelles fonctionnalités fondamentales du framework dans StoreKit. Je vous montrerai ensuite comment signer vos demandes d’achat intégré à l’aide de la bibliothèque de serveur App Store.

Pour finir, nous verrons comment mettre en avant des abonnements dans votre app grâce à SwiftUI et aux vues StoreKit.

Pour commencer, parlons des mises à jour apportées à trois types essentiels : AppTransaction, Transaction et RenewalInfo. Ils vous offrent de la visibilité sur les achats effectués dans votre app, permettent de suivre l’historique des transactions et de gérer le statut des abonnements. AppTransaction fournit des informations sur l’achat initial de votre app. Vous pouvez ainsi connaître la date d’achat initial, la version de l’app téléchargée par le client, ou la date de précommande avant la sortie officielle. Par exemple, vous pouvez utiliser le champ appVersion pour inviter les utilisateurs à mettre à jour leur app vers la dernière version. Pour obtenir un AppTransaction, interrogez l’API AppTransaction.shared et utilisez le résultat vérifié. StoreKit valide automatiquement la signature web JSON de l’AppTransaction et renvoie une valeur vérifiée. Une AppTransaction vérifiée signifie que StoreKit a validé que la transaction est bien signée par l’App Store et qu’elle est liée à votre app et à l’appareil de l’utilisateur. Nous souhaitons vous donner un maximum d’infos sur les abonnements et les offres pour enrichir votre stratégie commerciale. Cette année, nous avons ajouté deux nouveaux champs au type AppTransaction. À partir d’iOS 18.4, AppTransaction inclut le champ appTransactionID, rétrocompatible jusqu’à iOS 15. appTransactionID est une valeur unique au niveau mondial pour chaque compte Apple ayant téléchargé votre app. Elle est aussi unique pour chaque membre d’un groupe familial, si l’app prend en charge le Partage familial. Grâce à ce champ, vous pouvez, par exemple, associer des ID de transaction distincts sans passer par un appel serveur à serveur.

iOS 18.4 introduit aussi le champ originalPlatform. originalPlatform est d’un type nouveau appelé AppStore.Platform. Il indique la plateforme d’achat d’origine de votre app par le client. iOS, macOS, tvOS ou visionOS. Ces valeurs correspondent aux plates-formes cibles configurées dans App Store Connect. Pour les apps téléchargées sur watchOS, originalPlatform est défini sur iOS. Avec originalPlatform, il est plus simple d’adapter votre modèle économique, par exemple en passant d’une app payante à une app gratuite avec achats intégrés. Ce champ permet aussi d’attribuer des droits à vos clients de façon adaptée au fil de l’évolution de votre modèle. Ensuite, passons aux nouveautés concernant le type Transaction. Une Transaction représente un achat intégré réussi et contient des infos précieuses sur cet achat. Elle inclut la date de l’achat, le productID de l’achat intégré, et pour les abonnements à renouvellement automatique, la date d’expiration. Le type Transaction est principalement utilisé pour valider les droits des utilisateurs et déverrouiller du contenu. Votre app identifie le contenu à déverrouiller via le champ productID. Le système renvoie une Transaction immédiatement après un achat réussi ou via une séquence comme Transaction.currentEntitlements. Quel que soit le mode d’obtention, les Transactions sont toujours enveloppées dans une valeur vérifiée, comme pour AppTransaction. Cela signifie que vous n’avez pas besoin de valider manuellement la transaction : StoreKit 2 s’en occupe automatiquement. À propos des droits, depuis iOS 18.4, l’API Transaction.currentEntitlement est obsolète. Elle est remplacée par Transaction.currentEntitlements. Appelez cette nouvelle API en lui passant un productID. Elle renvoie une séquence asynchrone de transactions accordant les droits sur un produit donné. Comme un utilisateur peut avoir droit à un produit via différentes Transactions par exemple via un abonnement actif et le Partage familial, il est préférable d’adopter cette API. Cette année, le modèle Transaction comporte trois nouveaux champs.

Le champ appTransactionID, rétrocompatible jusqu’à iOS 15, est un identifiant unique pour la Transaction de téléchargement de l’app. Il s’agit de la même valeur que celle du type AppTransaction, mentionnée précédemment. iOS 18.4 introduit également le champ Période de l’offre, qui fait partie du membre offre. La période de l’offre représente la période liée à une offre d’abonnement souscrite par l’utilisateur au moment de l’achat. Le dernier champ ajouté dans iOS 18.4 est advancedCommerceInfo. Ce champ s’applique uniquement aux apps qui utilisent l’API Advanced Commerce. Pour les autres apps, cette valeur est toujours nulle. L’API Advanced Commerce permet de mieux prendre en charge les achats intégrés sur des catalogues volumineux, des expériences de créateurs ou des abonnements avec options. Pour en tirer parti, StoreKit 2 propose de nouvelles API natives comme AdvancedCommerceProduct en plus des API existantes telles que Transaction et SubscriptionStatus. Pour en savoir plus sur l’API Advanced Commerce, consultez la liste des ressources web fournies pour cette séance. Pour finir, passons en revue les mises à jour apportées au type RenewalInfo. Le type RenewalInfo est spécifiquement destiné aux abonnements à renouvellement automatique. Il contient des informations telles que si l’abonnement se renouvellera automatiquement, la date du prochain renouvellement, et pour les abonnements expirés, la raison de leur expiration. Par exemple, si vous avez récemment augmenté le prix de votre service et que la raison de l’expiration est didNotConsentToPriceIncrease, cela vous donne une information importante. C’est l’occasion idéale de proposer une offre de reconquête et d’inciter le client à se réabonner. StoreKit fournit les valeurs RenewalInfo encapsulées dans un VerificationResult associé à des instances de SubscriptionStatus. Vous pouvez obtenir un SubscriptionStatus via plusieurs méthodes, comme l’API SubscriptionStatus updates, ou en interrogeant StoreKit à l’aide d’un identifiant de groupe d’abonnement. Petit rappel : quand vous interrogez StoreKit avec un ID de groupe d’abonnement, veillez à accorder les droits utilisateurs selon le SubscriptionStatus qui offre le meilleur niveau de service, selon votre modèle économique. Autre nouveauté d’iOS 18.4 : une nouvelle API SubscriptionStatus acceptant un ID de transaction. Désormais, vous pouvez interroger StoreKit pour obtenir l’état d’un abonnement à l’aide de l’ID de transaction de toute transaction associée à un abonnement. Cette année, quatre champs supplémentaires ont été ajoutés au type RenewalInfo. Le champ appTransactionID, rétrocompatible jusqu’à iOS 15, et les champs Période de l’offre et advancedCommerceInfo, disponibles à partir d’iOS 18.4. Nous avons aussi ajouté le champ appAccountToken, qui relie un abonnement à un compte utilisateur sur votre service. Vous pouvez fournir cette valeur facultativement au moment de l’achat en utilisant l’option appAccountToken. L’App Store renvoie cette même valeur dans le champ appAccountToken du RenewalInfo associé à l’abonnement. Pour exploiter ces nouveaux champs, il suffit de compiler votre app avec la dernière version de Xcode. Ces ajouts simplifieront encore plus le développement de votre app et amélioreront l’expérience utilisateur. Changeons de sujet et parlons maintenant des codes d’offre. Ce sont des codes alphanumériques qui permettent de proposer des abonnements à tarif réduit ou gratuitement pendant une durée définie. Les utilisateurs peuvent les utiliser via des URL uniques ou directement dans votre app si vous implémentez les API StoreKit dédiées. Bonne nouvelle : les codes d’offre sont désormais disponibles pour les consommables, les non-consommables et les abonnements non renouvelables. Les utilisateurs peuvent les saisir directement dans votre app via l’API offerCodeRedemption. Si votre app utilise UIKit, utilisez l’API presentOfferCodeRedeemSheet. La prise en charge des codes d’offre pour les consommables, non-consommables et abonnements non renouvelables est rétrocompatible jusqu’à iOS 16.3. La Transaction générée par l’utilisation réussie du code d’offre est accessible sur n’importe quelle version d’OS via les API StoreKit 2. Si votre app cible des versions encore plus anciennes, les utilisateurs peuvent réclamer des codes d’offre pour des abonnements à renouvellement automatique jusqu’à iOS 14.2. Pour les types de produit autres que les abonnements à renouvellement automatique, nous avons introduit un nouveau mode de paiement sur le type Transaction.Offer.PaymentMode. Ce champ décrit comment l’utilisateur est facturé, ou non, pendant la période de l’offre, selon le type d’offre utilisé. Il représente plusieurs modes de paiement, tels que freeTrial où aucun paiement n’est requis. Les autres modes de paiement incluent payAsYouGo et payUpFront. Désormais, iOS prend en charge le mode oneTime pour les codes d’offre d’achat intégré, rétrocompatible jusqu’à iOS 17.2. Si votre app prend en charge des versions antérieures à iOS 17.2, vous pouvez accéder à ce nouveau mode de paiement via le membre offerPaymentModeStringRepresentation de Transaction, disponible depuis iOS 15. Pour approfondir la configuration des codes d’offre pour achats intégrés, regardez « What’s news in App Store Connect » de la WWDC 25. Par ailleurs, à partir d’iOS 18.2, StoreKit introduit de nouvelles méthodes d’achat nécessitant un contexte UI. Votre app doit spécifier le contexte UI à partir duquel l’achat est initié, afin que le système affiche la notification de paiement et la confirmation de manière optimale dans la scène active. Ces méthodes d’achat sont disponibles depuis iOS 18.2 et ses versions associées. Le type de contexte UI à fournir varie selon la plate-forme. Sur iOS, macCatalyst, tvOS et visionOS, le contexte UI est un UIViewController. Sur macOS, il s’agit d’un NSWindow. Sur watchOS, aucun contexte UI n’est requis. Depuis une vue SwiftUI, vous n’avez pas à déterminer vous-même ce contexte. Lisez simplement la valeur de l’environnement d’achat pour obtenir une instance de PurchaseAction. Lorsque vous êtes prêt à déclencher l’achat, vous appelez directement l’instance de PurchaseAction, qui implémente la méthode callAsFunction. Si vous utilisez les vues StoreKit, vous n’avez pas à vous soucier de fournir le contexte UI.

Le système s’en charge automatiquement. Pour apprendre à proposer une expérience d’achat intégré exceptionnelle via ProductView, StoreView et SubscriptionStoreView, consultez la séance « Meet StoreKit for SwiftUI » de la WWDC 23. Maintenant que nous avons exploré les principales améliorations d’API, voici une autre mise à jour importante. Cette année, de nouvelles API nécessitant une signature web JSON (JWS) ont été introduites. Voyons comment utiliser ces API et intégrer la bibliothèque de serveur App Store dans votre workflow pour simplifier la signature. Nouvelle fonctionnalité cette année : vous pouvez définir l’éligibilité d’un client à une offre de lancement avec l’option d’achat introductoryOfferEligibility. Vous pouvez également signer vos offres promotionnelles au format JWS en utilisant la nouvelle option promotionalOffer. Ces deux options requièrent une chaîne JWS compacte et sont rétrocompatibles jusqu’à iOS 15. Des modificateurs SwiftUI ont aussi été ajoutés pour accompagner chacune de ces options d’achat. L’utilisation du JWS permet à l’App Store de vérifier que vous avez bien autorisé l’achat dans des cas spécifiques, comme accorder une offre promotionnelle ou d’intro. Pour simplifier au maximum la signature de vos requêtes, nous mettons à disposition des outils open source, comme la bibliothèque de serveur App Store qui facilitent cette étape. Voyons à quel point il est rapide de générer une requête signée dans une app, avec un exemple dans SKDemo. Avant de commencer, vous devez récupérer votre clé de signature d’achat intégré depuis App Store Connect. Pour cela, allez dans l’onglet Utilisateurs et accès, cliquez sur l’en-tête Integrations, puis sélectionnez Achats intégrés dans le menu latéral. Vous pouvez utiliser une clé déjà active ou en créer une nouvelle. Pensez à noter l’ID de l’émetteur et l’ID de clé de votre clé de signature d’achat intégré. Une fois votre clé de signature obtenue, explorons la boutique d’abonnement intégré de SKDemo. Notre boutique commercialise les formules d’abonnement disponibles à l’achat. Je souhaite récupérer d’anciens abonnés dont l’abonnement a expiré. Pour cela, je vais mettre en avant une offre promo sur le forfait Pro à l’aide du nouveau modificateur subscriptionPromotionalOffer basé sur JWS. Ce modificateur attend deux closures. Dans la première closure, vous indiquez l’offre d’abonnement applicable à l’achat de l’abonnement. Dans mon exemple, je choisis l’offre promotionnelle avec la plus longue période d’essai gratuite, en utilisant une méthode d’aide que j’ai définie plus tôt. La deuxième closure attend une chaîne JWS compacte contenant les détails de l’offre signée. Ici, c’est notre type NetworkLayer qui fournit cette chaîne. Jetons un œil à son implémentation. Dans NetworkLayer, nous passons le productID et l’ID d’offre comme paramètres de requête. Nous effectuons une requête GET vers l’itinéraire de signature de l’offre promotionnelle sur notre serveur. Enfin, nous décodons la réponse. Côté serveur, ajoutez le package Swift de la bibliothèque de serveur App Store à votre projet et importez-la. Dans l’itinéraire qui gère la signature des offres, créez un contexte de signature via PromotionOfferV2SignatureCreator, en fournissant l’identifiant de lot, la clé, l’ID de clé et l’ID de l’émetteur récupérés plus tôt. Appelez ensuite la fonction createSignature, en passant le productID de l’abonnement et l’ID d’offre de l’offre d’abonnement. Il est recommandé d’inclure aussi une valeur pour le champ ID de transaction. Cette valeur peut être l’appTransactionID ou le TransactionID de n’importe quelle Transaction de l’utilisateur. Ce champ est optionnel, mais son usage est conseillé.

De retour dans l’app, l’offre promotionnelle peut être utilisée sans problème, et l’achat se termine correctement. Voilà comment créer des demandes d’achat intégré signées à l’aide de la bibliothèque de serveur App Store. Signer vos demandes permet à l’App Store de vérifier que vous autorisez bien l’achat. Intégrer la bibliothèque de serveur App Store simplifie grandement ce processus. Et le meilleur dans tout ça, cette bibliothèque est disponible en quatre langages : Java, Python, Node.js et Swift. Pour démarrer avec la bibliothèque de serveur App Store, consultez la séance « Explore App Store server APIs for In-App Purchase » de la WWDC24. Pour clore cette session, découvrons une nouvelle manière d’utiliser SwiftUI pour engager vos utilisateurs. Voici le petit nouveau dans la famille des vues StoreKit : SubscriptionOfferView. Cette nouvelle vue SwiftUI permet de mettre en avant un abonnement à renouvellement automatique et capte l’attention sur le service que propose votre app. Vous pouvez déclarer un SubscriptionOfferView en utilisant un abonnement à renouvellement automatique déjà chargé, ou un productID. Dans ce cas, la vue s’occupe automatiquement de charger les métadonnées du produit depuis l’App Store. Vous pouvez décorer la vue avec l’image d’abonnement configurée dans App Store Connect en activant l’option prefersPromotionalIcon. Cette icône s’affiche lorsque les métadonnées ont fini de charger. Si vous préférez utiliser une icône personnalisée, une variante de l’API permet de passer une closure ViewBuilder. Vous pouvez également fournir une icône de remplacement qui s’affichera pendant le chargement des données. SubscriptionOfferView permet de présenter bien plus qu’une simple formule d’abonnement. Avec le modificateur subscriptionOfferViewDetailAction, vous pouvez rediriger l’utilisateur vers votre propre magasin d’abonnements intégré. Déclarer ce modificateur ajoute un bouton detailLink à la vue. Lorsqu’un utilisateur appuie sur le bouton detailLink, la vue déclenche la closure liée à ce modificateur. Voici un exemple dans l’app SKDemo. Je modifie un état dans ContentView qui contrôle la manière dont l’expérience utilisateur est présentée dans l’app. Quand l’utilisateur appuie sur detailLink, il est dirigé vers le magasin d’abonnement de l’app pour consulter les formules d’abonnement disponibles. Un point important à considérer lorsque vous utilisez cette API est de savoir quelle formule mettre en avant, ou même si une formule doit être affichée. Replongeons dans le code pour voir un exemple d’implémentation. Identifier quelle formule d’abonnement afficher avec SubscriptionOfferView commence par déterminer le statut d’abonnement du client. Dans une app SwiftUI, le meilleur endroit pour faire cela est dans l’implémentation du protocole App. Vous utiliserez ensuite ces données pour piloter le reste de la hiérarchie de vues. Pour ce faire, déclarez le modificateur subscriptionStatusTask, introduit dans iOS 17. Dans ce modificateur, vous transformez les statuts fournis par StoreKit dans un modèle compris par votre app. Dans SKDemo, ce modèle s’appelle SKDemoPlusStatus. Vous mettez ensuite à jour une source de vérité dans votre vue, qui suit ce statut et le diffuse via une variable d’environnement.

Une fois le statut utilisateur connu, je l’utilise dans ContentView pour afficher une SubscriptionOfferView. J’y lis la valeur d’environnement du statut client, et je décide d’afficher un plan standard (s’il n’est pas abonné) ou une formule supérieure (s’il l’est déjà). Pour raccourcir le code, j’utilise l’initialiseur par ID de groupe pour créer la SubscriptionOfferView. Avec cette déclaration, le système choisit automatiquement un plan dans le groupe d’abonnements. Il faut aussi indiquer la relation entre la formule affichée et celui que l’utilisateur possède déjà. Le paramètre visibleRelationship accepte cinq valeurs : upgrade, downgrade, crossgrade, current et all. L’API adapte son comportement selon le statut du client. Voyons de plus près chacune de ces relations. Supposons que l’utilisateur ait souscrit à une formule intermédiaire. Spécifier upgrade affichera une formule d’un niveau supérieur. À l’inverse, downgrade affiche une formule d’un niveau inférieur. Dans cet exemple, la formule affichée serait le même pour les abonnés et non-abonnés. Vous pouvez afficher une formule plus abordable pour tenter de retenir un client ayant désactivé le renouvellement automatique. L’option crossgrade se base sur les formules du même niveau que celui de l’utilisateur, et choisit le meilleur rapport qualité-prix. Avec current, c’est la formule actuelle de l’utilisateur qui est mise en avant. Par défaut, toutes les interactions sont désactivées tant qu’aucune offre d’abonnement n’est disponible pour être utilisée. Vous marquez un utilisateur comme éligible à une offre en utilisant n’importe quel modificateur d’offre, comme le nouveau subscriptionPromotionalOffer ou preferredSubscriptionOffer. Une excellente utilisation de cette relation est de proposer une remise lorsqu’un abonnement arrive à expiration, afin de fidéliser l’utilisateur. Enfin, parlons de la relation all. Cette relation fonctionne de la même manière pour tous les utilisateurs. Quand vous l’utilisez, la vue affiche les prix de toutes les formules d’abonnement du groupe. Vous définissez l’action à effectuer via le modificateur subscriptionOfferViewDetailAction. Quelle que soit la relation choisie dans SubscriptionOfferView, vous pouvez aussi personnaliser la vue avec une icône spécifique et une icône temporaire, comme montré plus tôt. Il est aussi possible d’utiliser l’icône de votre app. Il suffit pour cela d’activer l’indicateur useAppIcon sur true. C’est ainsi que se conclut la présentation de SubscriptionOfferView, une nouvelle façon enthousiasmante d’impliquer vos utilisateurs. Aujourd’hui, nous avons couvert de nombreuses améliorations de l’API StoreKit, pour vous aider à proposer une fabuleuse expérience d’achat intégré. Si vous ne l’avez pas encore fait, c’est le bon moment pour adopter StoreKit 2 dans votre projet. Pour profiter des derniers designs et créer une boutique performante dans votre app, utilisez les vues StoreKit pour mettre en avant vos achats intégrés et abonnements. Consultez la bibliothèque de serveur App Store sur GitHub et intégrez-la pour simplifier la signature de vos demandes d’achat intégré. Pour approfondir les API serveur de l’App Store, regardez « Dive into App Store server APIs for In-App Purchase » de la WWDC 25. Et si vous débutez avec StoreKit 2, « Meet StoreKit 2 » de la WWDC21 est un excellent point de départ. Merci de votre attention. J’ai hâte de découvrir ce que vous allez créer avec StoreKit.