RevenueCat : mettre en place un abonnement in-app sur iOS

Pourquoi passer par RevenueCat plutôt que StoreKit seul

StoreKit, le framework d'Apple, permet de vendre un abonnement sans aucun service tiers. Mais pour un débutant, écrire soi‑même toute la logique d'achat, de restauration et de vérification des droits d'accès représente beaucoup de code à maintenir, avec des cas limites faciles à oublier : changement d'appareil, expiration, remboursement.

RevenueCat s'intercale entre App Store Connect et ton app : il lit tes produits, gère les abonnements actifs et t'évite d'écrire cette couche toi‑même. Tu gardes la main sur le prix et les offres depuis un tableau de bord, sans republier ton app à chaque changement.

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

Avant RevenueCat, les produits doivent exister côté Apple. Dans App Store Connect, crée un groupe d'abonnements, puis un ou plusieurs niveaux avec leur durée, mensuel ou annuel par exemple, et leur prix par territoire. Renseigne aussi les textes affichés à l'utilisateur pour chaque palier : Apple les demande avant d'accepter le produit en revue.

Un oubli fréquent à ce stade : un produit créé mais jamais soumis à la première revue de l'app avec sa version associée. Un produit en attente qui n'a jamais été inclus dans une soumission d'app reste invisible pour tes utilisateurs, même si RevenueCat le voit déjà.

Étape 2 : connecter RevenueCat à ton app

Dans RevenueCat, tu crées un projet, tu relies ta clé d'API App Store Connect pour que RevenueCat synchronise automatiquement tes produits, puis tu définis des "entitlements", les droits d'accès. Un entitlement représente ce que l'abonnement débloque, par exemple l'accès complet à l'app, indépendamment du produit exact qui l'a déclenché.

Cette indirection est utile : si tu changes la structure de tes offres plus tard, par exemple en ajoutant un palier annuel, tu relies simplement le nouveau produit au même entitlement, sans toucher au code qui vérifie l'accès dans ton app.

Côté app, le SDK RevenueCat pour React Native s'installe dans un projet Expo avec un plugin dédié, et expose une fonction simple pour savoir si l'utilisateur courant possède un entitlement actif.

Étape 3 : construire ton paywall

Le paywall est l'écran qui présente l'offre et déclenche l'achat. RevenueCat propose des paywalls configurables depuis le tableau de bord, modifiables sans republier l'app, ou tu peux construire le tien avec le SDK si tu veux un contrôle complet sur le design.

Le placement compte autant que le design. Un paywall affiché avant que la personne ait vu la valeur de l'app convertit généralement moins bien qu'un paywall placé juste après une première action réussie. Le guide des erreurs de paywall iOS pour débutants détaille les pièges les plus fréquents à ce stade, au-delà du seul branchement technique.

Étape 4 : tester l'achat, la restauration et l'expiration

C'est l'étape la plus souvent bâclée, et pourtant la plus vérifiée par Apple. Trois scénarios doivent fonctionner avant l'envoi :

L'achat. Avec un compte testeur sandbox, l'achat doit débloquer l'entitlement immédiatement, et ton app doit réagir à ce changement sans qu'il faille redémarrer l'app.

La restauration. Sur un nouvel appareil ou après réinstallation, avec le même compte Apple, un bouton "Restaurer mes achats" doit retrouver l'abonnement actif. Apple vérifie systématiquement ce parcours en revue, et son absence ou son mauvais fonctionnement est un motif de refus fréquent.

L'expiration. En environnement sandbox, les abonnements expirent en quelques minutes au lieu de plusieurs mois, ce qui te permet de vérifier que l'accès se referme correctement une fois la période terminée, sans attendre un vrai cycle de facturation.

Ce que RevenueCat ne remplace pas

RevenueCat gère la mécanique d'achat, pas la conformité de ta fiche. Il te revient toujours de décrire correctement l'abonnement dans ta description App Store, d'indiquer son prix exact et sa durée, et de renseigner tes conditions d'utilisation. La page abonnement ou achat unique sur iOS t'aide à choisir le bon modèle avant même d'arriver à cette étape technique.

RevenueCat prend par ailleurs une commission sur les revenus au-delà d'un certain seuil mensuel, en plus de la commission d'Apple sur les abonnements vendus dans l'app. Vérifie les paliers actuels sur leur propre site avant de construire ton modèle économique autour de ces deux commissions.

Les erreurs les plus fréquentes chez un débutant

Oublier l'état de chargement. Au lancement, RevenueCat a besoin d'un court instant pour récupérer les droits d'accès de l'utilisateur. Si ton app affiche le contenu payant par défaut avant cette réponse, un utilisateur sans abonnement peut voir, le temps d'un instant, du contenu qu'il n'a pas payé. Prévois un état de chargement explicite plutôt qu'un affichage par défaut optimiste.

Vérifier les droits au mauvais endroit. Un entitlement actif doit être revérifié à chaque ouverture d'un écran payant, pas seulement une fois au démarrage. Si l'utilisateur annule ou si son abonnement expire pendant qu'il utilise l'app, l'écran suivant doit refléter ce changement.

Confondre environnement sandbox et production. Les identifiants de produits et les comptes testeurs sandbox sont distincts de la production. Un test qui fonctionne en sandbox avec le mauvais compte Apple, ou un produit créé seulement en production, peut donner une fausse impression que tout est prêt.

Une app vérifiée, pas seulement une app qui compile

Un abonnement qui "marche" en test rapide sur ton propre compte ne garantit pas qu'il survit à une restauration sur un autre appareil ou à une expiration réelle. C'est exactement ce que vérifie un reviewer Apple, et c'est ce que je revois avant l'envoi avec les personnes que j'accompagne. La page abonnement in-app iOS détaille l'ensemble de cette chaîne, de la création des produits jusqu'à la vérification finale.

Si tu veux être accompagné sur cette étape précise, avec RevenueCat déjà branché sur ta propre app, découvre l'accompagnement et ses tarifs.