MonétisationMis à jour le 23 octobre 202612 min de lecture

Achats intégrés et abonnements iOS : comment StoreKit fonctionne dans une app Expo

Produits, transactions, droits d'accès, restauration, test en Sandbox, validation côté serveur : la mécanique des achats intégrés StoreKit dans une app Expo.

Sources Apple vérifiées le 23 octobre 2026 · relu par Équipe Briksell

Sommaire

Réponse courte

StoreKit est la bibliothèque d'Apple qui gère les achats intégrés dans une app iOS. Elle affiche la fenêtre de paiement d'Apple, traite le paiement, puis prévient ton app qu'un achat a eu lieu. C'est ensuite à ton app de débloquer ce qui a été acheté.

Dans une app Expo (React Native), tu n'appelles pas StoreKit directement : tu passes par une bibliothèque qui le fait pour toi. La documentation d'Expo en cite deux :

  • react-native-purchases (RevenueCat), qui s'appuie sur StoreKit et Google Play Billing, avec les services de RevenueCat (gestion des produits, statistiques, validation des achats côté serveur) ;
  • expo-iap, une bibliothèque qui suit la spécification OpenIAP.

Les quatre points à retenir :

  1. Ces bibliothèques contiennent du code natif : elles ne fonctionnent pas dans Expo Go. Il faut une version de développement (« development build ») ou une version TestFlight.
  2. Chaque produit a un identifiant (Product ID) qui doit être identique dans App Store Connect et dans le code.
  3. Les achats se testent sans payer, dans la Sandbox d'Apple, avec un compte de test.
  4. Ton app doit permettre de restaurer les achats (section 3.1.1 des règles d'Apple).

Ce guide explique la mécanique. Les règles commerciales (cas obligatoires, commission, accord Paid Apps) sont dans Abonnements et achats intégrés Apple.

Qui est concerné, et les exceptions

Concerné : toute app qui vend du numérique

Accès premium, crédits, contenu, abonnement : la section 3.1.1 des règles d'Apple impose en règle générale l'achat intégré. Les biens physiques et les services consommés hors de l'app n'y passent pas (3.1.3(e)). Aux États-Unis et dans l'Union européenne (depuis le 1er octobre 2026), d'autres options existent : voir Règles UE sur les paiements d'octobre 2026. Ce guide n'est pas un conseil juridique.

Les quatre types de produits

D'après l'aide App Store Connect :

TypeCe que dit AppleCe que l'app doit faire
ConsommableUtilisé une fois, puis à racheterCréditer le solde, sans le faire expirer
Non consommableAcheté une fois, n'expire pasDébloquer pour toujours, et pouvoir restaurer
Abonnement auto-renouvelableAccès pour une période, renouvelé jusqu'à résiliationVérifier que l'abonnement est toujours actif
Abonnement non renouvelableAccès pour une durée limitée, sans renouvellementGérer toi-même la durée et l'accès sur tous les appareils

Deux règles d'Apple à garder en tête : les crédits achetés ne doivent pas expirer (3.1.1), et un abonnement auto-renouvelable doit durer au moins sept jours et être disponible sur tous les appareils de l'utilisateur (3.1.2(a)).

Prérequis côté Apple

Il te faut un compte Apple Developer actif et l'accord Paid Apps signé, avec banque et fiscalité renseignées : Apple précise que l'accord doit être actif pour tester en Sandbox. Selon la règle 4.2.6, une app créée avec un service de génération d'apps est soumise par celui qui en fournit le contenu : les produits se créent donc dans ton App Store Connect.

Procédure pas à pas

Étape 1 : créer les produits dans App Store Connect

Crée tes produits dans ton app, menu Monetization (le détail des écrans est dans le guide de configuration). Pour chaque produit, choisis l'identifiant avec soin. D'après Apple :

  • il peut contenir des lettres, des chiffres, des tirets, des points et des tirets bas, jusqu'à 100 caractères ;
  • il ne se modifie plus une fois le produit enregistré ;
  • il ne peut pas être réutilisé dans la même app, même si tu supprimes le produit.

Une convention simple : nomdelapp.premium.mensuel, nomdelapp.premium.annuel, nomdelapp.credits.100. Note ces identifiants : tu vas les recopier tels quels dans le code. Apple indique aussi que les changements de produits peuvent mettre jusqu'à une heure à apparaître dans la Sandbox.

Étape 2 : comprendre ce que StoreKit fait dans l'app

Apple propose deux versions de StoreKit. La version récente (souvent appelée StoreKit 2) existe depuis iOS 15. L'ancienne, basée sur des reçus (« receipts »), est marquée obsolète par Apple. Les achats faits avec l'une sont visibles avec l'autre. Quelle que soit la bibliothèque que tu utilises, le parcours suit les mêmes étapes :

  1. Charger les produits depuis l'App Store avec leurs identifiants. Apple demande de récupérer ces informations avant d'afficher l'écran d'achat, pour que les détails affichés correspondent à App Store Connect.
  2. Lancer l'achat : la fenêtre de paiement d'Apple s'ouvre.
  3. Recevoir la transaction : chaque achat ou renouvellement crée une « transaction », signée par l'App Store (format JWS, une signature numérique). StoreKit la vérifie et indique si elle est valide.
  4. Débloquer le contenu ou le service acheté.
  5. Terminer la transaction (finish()), une fois le contenu livré. Une transaction non terminée est renvoyée à l'app au lancement suivant.

Deux mécanismes complètent ce parcours :

  • L'écoute des transactions (Transaction.updates) : Apple demande de l'activer dès le lancement de l'app. Elle reçoit les achats faits ailleurs : sur un autre appareil, un code d'offre utilisé, un achat fait dans l'App Store. Sans elle, ton app peut rater des achats.
  • Les droits actuels (Transaction.currentEntitlements) : la liste de ce que l'utilisateur possède en ce moment. On y trouve les achats non consommables, les abonnements auto-renouvelables actifs (ou en période de grâce) et les abonnements non renouvelables. Les produits remboursés ou révoqués n'y sont plus. Les consommables n'y figurent pas : c'est à ton app de tenir le solde de crédits.

Ces noms sont ceux d'Apple ; ta bibliothèque React Native les expose sous ses propres noms.

Étape 3 : installer la bibliothèque dans une version de développement

La documentation d'Expo est claire : le code natif ne peut pas être configuré dans Expo Go. Concrètement :

  1. Ajoute la bibliothèque à ton projet (react-native-purchases ou expo-iap). Expo indique que les deux sont compatibles avec ses « config plugins », le mécanisme qui règle la partie native du projet.
  2. Fabrique une version de développement avec EAS Build, ou une version de test à envoyer sur TestFlight. Le détail est dans Publier une app Expo avec EAS Build et EAS Submit.
  3. Vérifie que le bundle ID de l'app est exactement celui de ta fiche App Store Connect : Apple demande que bundle ID et identifiants de produits correspondent.

Avec Briksell, l'aperçu de ton app s'ouvre dans le navigateur du téléphone (voir Aperçu et test sur téléphone) : ce n'est pas une app native, donc aucun achat intégré ne peut y être testé.

Étape 4 : tester en Sandbox

La Sandbox est l'environnement de test d'Apple : vrais produits d'App Store Connect, aucun prélèvement. Apple précise que les apps signées pour le développement et les apps installées depuis TestFlight utilisent la Sandbox.

  1. Dans App Store Connect, Users and Access, onglet Sandbox, crée un compte de test. Il ne fonctionne que pour les apps de ton propre compte développeur.
  2. Sur une version de développement : au premier achat, connecte-toi avec ce compte de test. Le compte apparaît ensuite dans Réglages > Développeur. La mention [Environment: Sandbox] confirme que tu es en test.
  3. Sur une version TestFlight : les achats sont toujours en Sandbox. Pour accéder aux réglages de test, Apple demande de se déconnecter de Contenu multimédia et achats, puis de se connecter au compte de test dans Réglages > Développeur. Un appareil dédié aux tests est conseillé.
  4. Dans les réglages du compte de test, tu peux accélérer les renouvellements d'abonnement et effacer l'historique d'achats pour rejouer un test.

Teste au minimum : un achat par produit, une annulation, un renouvellement, une expiration, une réinstallation de l'app. Voir aussi TestFlight : tester ton app sur iPhone.

Étape 5 : gérer la restauration

La section 3.1.1 demande un moyen de restaurer tous les achats « restaurables » : en pratique, un bouton Restaurer les achats sur l'écran d'achat.

Avec la version récente de StoreKit, une app réinstallée ou installée sur un nouvel appareil retrouve automatiquement ses transactions au premier lancement : il suffit de relire les droits actuels. Le bouton, lui, déclenche une synchronisation forcée avec l'App Store (AppStore.sync()). Apple précise que cette synchronisation affiche une demande d'identifiants App Store : ne l'appelle que quand l'utilisateur touche le bouton, jamais automatiquement. Pour l'écran lui-même, voir Paywall, essai gratuit et bouton Restaurer.

Étape 6 : décider si tu as besoin d'un serveur

Apple laisse le choix : tu peux t'appuyer sur la vérification faite par StoreKit, ou vérifier les transactions sur ton serveur. Un serveur devient utile quand l'accès doit suivre l'utilisateur hors de l'iPhone (un compte web, une app Android) ou quand tu veux réagir aux remboursements.

Apple fournit deux outils côté serveur :

  • App Store Server API : ton serveur interroge Apple sur l'historique des transactions, le statut d'un abonnement ou les remboursements d'un client.
  • App Store Server Notifications : Apple prévient ton serveur en temps réel (achat, renouvellement, remboursement…). Tu renseignes l'adresse de ton serveur dans App Store Connect, pour la production et pour la Sandbox. La version 1 de ces notifications est obsolète : utilise la version 2.

Si tu passes par RevenueCat, son service peut assurer cette validation côté serveur, d'après la documentation d'Expo.

Point clé pour la revue : Apple teste tes achats dans la Sandbox. Ton serveur doit donc accepter les transactions de test. Chaque transaction indique son environnement ; si tu ne le connais pas, Apple conseille d'interroger d'abord la production, puis la Sandbox si la transaction est introuvable.

Étape 7 : soumettre avec la version de l'app

Le premier produit de chaque type doit être soumis avec une nouvelle version de l'app, et un nouvel abonnement avec son groupe d'abonnements. Apple précise que les achats intégrés n'ont pas besoin d'être déjà validés pour fonctionner pendant la revue. Si tes achats sont limités à certains pays ou appareils, indique-le dans les notes pour l'équipe de revue : voir Notes pour App Review et compte de démo.

Erreurs fréquentes

  • Tester dans Expo Go : la bibliothèque d'achats n'y fonctionne pas.
  • Un identifiant mal recopié : l'App Store ne renvoie pas le produit, et l'écran d'achat n'a rien à afficher.
  • Un accord Paid Apps non actif : pas de test possible en Sandbox, et aucun achat payant pendant la revue.
  • Des produits trop récents : jusqu'à une heure avant leur apparition en Sandbox.
  • Oublier d'écouter les transactions au lancement : un achat fait sur un autre appareil ou approuvé plus tard par un parent n'est pas débloqué.
  • Ne jamais terminer la transaction : elle revient à chaque lancement.
  • Débloquer une transaction non vérifiée : StoreKit signale celles qui échouent à sa vérification ; ne donne accès qu'aux transactions vérifiées.
  • Écrire le prix en dur dans l'écran au lieu d'afficher celui renvoyé par l'App Store.

Vérification

Avant de soumettre ta version, coche chaque point. La liste est enregistrée seulement dans ton navigateur.

Ta checklist0/10

Tes cases sont gardées dans ce navigateur. Cocher une case ne prouve rien à Apple : vérifie chaque point pour de vrai.

Sources Apple et date de vérification

Vérifié le 23 octobre 2026 sur les pages officielles :

FAQ

StoreKit, RevenueCat, expo-iap : quelle différence ?

StoreKit est l'outil d'Apple, intégré à iOS. RevenueCat (react-native-purchases) et expo-iap sont des bibliothèques qui permettent de l'utiliser depuis React Native. RevenueCat ajoute un service en ligne, notamment pour valider les achats côté serveur. Dans tous les cas, le paiement passe par Apple.

Comment tester un achat sans payer ?

Avec un compte Sandbox créé dans App Store Connect, sur une version de développement ou une version TestFlight. Aucun prélèvement n'a lieu, et Apple n'envoie pas d'e-mail pour les achats faits en test.

Mes produits doivent-ils être validés séparément ?

Le premier produit de chaque type est soumis avec une nouvelle version de l'app. Il n'a pas besoin d'être validé avant pour fonctionner pendant la revue : l'équipe d'Apple l'achète dans la Sandbox.

Passer à l'action

Soyons clairs sur ce que fait Briksell aujourd'hui : l'écran d'abonnement que Briksell peut générer est une démonstration, aucun vrai paiement n'y est branché. Pour vendre, il faut intégrer une des bibliothèques citées par Expo dans le code de ton app, que tu peux exporter, puis suivre les étapes de ce guide depuis ton propre compte Apple. Pour choisir ce que tu vends, lis Comment monétiser son application, puis prépare ta fiche avec Créer la fiche de ton app dans App Store Connect. Et si tu n'as pas encore d'app : Créer mon app.

Sources officielles

À lire ensuite

← Tous les guides « Monétisation »Tous les thèmes