Alternatives à RevenueCat : gérer ses in-app subscriptions sans sacrifier ses marges

Pourquoi on cherche des alternatives à RevenueCat

RevenueCat a résolu un vrai problème. Avant son existence, implémenter des in-app subscriptions voulait dire se battre avec StoreKit 1 sur iOS (notoirement douloureux), Google Play Billing sur Android (notoirement confus), et construire sa propre validation de reçus côté serveur pour savoir qui paie réellement. RevenueCat a emballé tout ça dans un SDK propre avec une API unifiée cross-platform. Des milliers d'apps l'utilisent. Ca marche.

Alors pourquoi quitter ?

Le problème de la tarification au pourcentage. RevenueCat facture sur la base du monthly tracked revenue (MTR). Le plan gratuit couvre jusqu'à $2,500/mois, ce qui est généreux pour les apps en phase de lancement. Mais une fois ce seuil franchi, on paie environ 1 % de son revenu — et ça augmente linéairement. A $10k de MRR, les frais tournent autour de $100-120/mois. Agaçant mais tolérable. A $50k MRR, on est à $400-600/mois. A $100k MRR, $800-1,200/mois. Pour un fondateur bootstrapé qui surveille chaque point de marge, payer plus de $10,000/an pour de l'infrastructure d'abonnement, ça commence à piquer.

Soyons directs : on paie un pourcentage de son revenu pour un service qui valide des reçus et suit l'état des abonnements. La valeur est réelle au début — le SDK fait économiser des semaines de développement. Mais le coût augmente avec le revenu alors que la valeur qu'on en tire reste à peu près constante. Le 100 000e abonné ne rend pas l'infrastructure de RevenueCat 100 fois plus difficile à faire tourner que le 1 000e.

Le risque de dépendance. RevenueCat se place entre l'app et le revenu. Chaque achat, chaque renouvellement, chaque vérification de statut d'abonnement passe par leurs serveurs. Si RevenueCat a une panne, l'app ne peut plus vérifier qui a payé. S'ils changent leur API, il faut mettre à jour le SDK. S'ils augmentent les prix, on a peu de levier de négociation parce que migrer est douloureux.

Pour la plupart des apps indie qui font $5k-20k/mois, cette dépendance est un compromis raisonnable en échange de la vitesse de développement. Mais quand l'app devient le revenu principal — quand elle paie le loyer et nourrit la famille — avoir un tiers dans le chemin critique de son flux de revenus mérite réflexion.

Le plafond fonctionnel. RevenueCat a ajouté des paywalls et quelques fonctionnalités d'expérimentation, mais ce n'est pas un outil d'optimisation de paywall à la base. Si le levier de croissance principal est d'améliorer les taux de conversion du paywall, des outils dédiés comme Superwall ou le paywall builder d'Adapty offrent des capacités d'expérimentation plus profondes. Les fonctionnalités de paywall de RevenueCat sont correctes pour un usage basique mais limitées face aux alternatives spécialisées.

L'alternative native s'est améliorée. StoreKit 2, sorti avec iOS 15, est radicalement meilleur que StoreKit 1. L'API async/await, les transactions signées en JWS et les server notifications V2 rendent le passage au natif réellement faisable sans SDK tiers sur iOS. Google Play Billing Library s'est aussi amélioré. L'argument "passer au natif est trop douloureux" qui rendait RevenueCat indispensable est plus faible qu'il y a trois ans.

Comment on a évalué ces alternatives

On a regardé chaque outil du point de vue d'un fondateur d'app indie ou d'une petite équipe qui construit une app mobile par abonnement :

• Coût total à grande échelle : Pas juste le prix de base, mais ce qu'on paie à $10k, $50k et $100k de revenu mensuel.
• Qualité du SDK : L'intégration est-elle propre ? La doc est-elle bonne ? Le support est-il réactif ?
• Profondeur des analytics : Peut-on comprendre le churn, la rétention par cohortes, la conversion de trial et la LTV sans brancher des outils externes ?
• Paywall et expérimentation : Peut-on tester les prix, le design du paywall et les offres sans publier de mise à jour sur le Store ?
• Difficulté de migration : A quel point c'est douloureux de quitter RevenueCat ? Peut-on faire tourner les deux systèmes en parallèle ?

On a aussi pris en compte la maturité de la plateforme et la taille de l'équipe. Un SDK magnifique d'une startup de trois personnes, c'est un profil de risque différent du framework natif d'Apple.

Analyse détaillée : ce que chaque alternative fait de mieux

Adapty — le remplaçant le plus proche de RevenueCat

Adapty se positionne comme RevenueCat avec de meilleurs outils d'expérimentation, et ce positionnement est largement justifié. Les fonctionnalités de base de gestion d'abonnements — validation de reçus, SDK cross-platform, gestion des entitlements, analytics d'abonnement — sont comparables à RevenueCat. Là où Adapty se différencie, c'est le paywall builder visuel.

Le paywall builder permet de designer, déployer et A/B tester des paywalls sans passer par la review de l'App Store. On choisit un template (ou on construit de zéro), on configure les produits, on lance une expérimentation et on publie. RevenueCat a ajouté des fonctionnalités de paywall récemment, mais l'éditeur de paywall d'Adapty est plus mature et le moteur d'expérimentation est plus profond. Si on itère activement sur son paywall pour améliorer la conversion, ça fait la différence.

Les analytics incluent l'analyse par cohortes et la modélisation prédictive de la LTV sur le plan Pro. On peut voir comment les abonnés de différents canaux d'acquisition retiennent dans le temps et projeter leur lifetime value. C'est le genre d'analyse qui aide à prendre des décisions éclairées sur les dépenses publicitaires sans exporter les données dans un tableur.

La tarification suit un modèle similaire à RevenueCat — gratuit jusqu'à $10k MTR, puis tarification par paliers. A des niveaux de revenu plus élevés, Adapty peut être légèrement moins cher selon le plan, mais la douleur du scaling au pourcentage est comparable. On échange un frais basé sur le revenu pour un autre, donc la migration n'a de sens financier que si on bénéficie aussi des meilleurs outils de paywall.

La documentation du SDK est correcte mais pas tout à fait au niveau de RevenueCat. RevenueCat a eu des années pour peaufiner ses docs, ses sample apps et son support communautaire. Adapty rattrape son retard mais l'écosystème est plus petit. Si on tombe sur un edge case, on a plus de chances de trouver une solution RevenueCat sur Stack Overflow.

Quand Adapty vaut le switch : On optimise activement ses paywalls et on veut de l'A/B testing intégré sans ajouter un outil séparé comme Superwall par-dessus RevenueCat.

Qonversion — la plateforme attribution-first

Qonversion prend un angle différent en intégrant l'attribution directement dans la plateforme d'abonnement. Au lieu de juste tracker qui s'est abonné, Qonversion connecte le revenu d'abonnement aux campagnes publicitaires et aux canaux qui ont amené ces utilisateurs. Pour les apps qui dépendent de l'acquisition payante, ça boucle la boucle entre dépenses publicitaires et LTV réelle.

Le tracking d'attribution fonctionne en se connectant aux plateformes publicitaires (Apple Search Ads, Facebook, Google Ads, etc.) et en matchant les données d'attribution d'installation avec les événements d'abonnement. On peut voir quelles campagnes produisent les abonnés avec la meilleure rétention et la meilleure LTV, pas juste le plus grand volume d'installations. C'est une donnée puissante pour optimiser ses dépenses pub.

Côté tarification, Qonversion est plus agressif que RevenueCat sur les paliers supérieurs. Le plan Growth commence à $99/mois et augmente plus doucement que le modèle au pourcentage de RevenueCat. A partir de $50k+ MTR, les économies deviennent significatives — potentiellement plusieurs centaines de dollars par mois de moins que RevenueCat.

Le compromis, c'est une équipe plus petite et une vélocité de features plus lente. RevenueCat shippe des améliorations constamment. Qonversion avance à un rythme plus mesuré. Le dashboard est fonctionnel mais semble une génération en retard par rapport à RevenueCat ou Adapty en termes de polish UX. Les options d'intégration avec des outils tiers sont aussi plus limitées.

Quand Qonversion a du sens : On dépense pas mal en acquisition utilisateur et on a besoin de lier le revenu d'abonnement directement à la performance des campagnes. Les fonctionnalités d'attribution justifient le switch ; les économies à grande échelle sont un bonus.

Superwall — le spécialiste de l'optimisation de paywalls

Superwall n'est pas un remplacement de RevenueCat. C'est un complément à RevenueCat (ou à n'importe quelle plateforme d'abonnement, y compris StoreKit natif). Superwall fait une seule chose : il rend le paywall meilleur.

Le concept central, c'est la configuration de paywall à distance. On design son paywall dans le dashboard Superwall, on définit les règles d'affichage, on lance des expérimentations A/B, et on déploie — tout ça sans soumettre de mise à jour sur l'App Store. On peut tester un nouveau design de paywall le lundi, analyser les résultats le vendredi, et déployer le gagnant à 100 % des utilisateurs sans attendre la review du Store.

Le moteur d'expérimentation supporte l'A/B testing et les tests multivariés avec un suivi de significativité statistique. On peut tout tester : les prix, le design, le texte, le timing du déclenchement du paywall, s'il faut montrer un free trial ou une offre annuelle remisée. Pour les apps où la conversion du paywall est le levier de croissance principal, cette vitesse d'itération est transformatrice.

Superwall s'intègre directement avec RevenueCat, StoreKit 2 et d'autres plateformes d'abonnement. Il ne gère pas la validation de reçus ni l'état des abonnements — c'est le boulot de la plateforme d'abonnement. Superwall gère la présentation et l'optimisation.

La tarification est basée sur les conversions, pas sur le revenu. On paie pour le nombre d'utilisateurs qui convertissent via les paywalls gérés par Superwall. Ca peut devenir cher pour les apps à gros volume, mais si Superwall améliore le taux de conversion, le ROI est généralement positif.

Quand Superwall vaut le coup : L'app a un trafic significatif et le taux de conversion du paywall est le goulet d'étranglement. Si passer de 3 % à 5 % de conversion du paywall ferait bouger le MRR de manière significative, Superwall se rentabilise rapidement.

Glassfy — l'option budget

Glassfy se positionne comme l'alternative abordable à RevenueCat, et la tarification confirme cette promesse. Gratuit jusqu'à $10k MTR avec des plans payants forfaitaires à partir de $49/mois — pas de frais au pourcentage qui grimpent avec le revenu.

Les fonctionnalités de base sont solides : validation de reçus côté serveur, gestion de l'état des abonnements, webhooks d'événements en temps réel et support cross-platform iOS et Android. Pour une app d'abonnement classique qui a besoin d'une infrastructure de billing fiable sans les outils premium d'analytics et d'expérimentation, Glassfy couvre l'essentiel.

Le dashboard analytics est basique comparé à RevenueCat ou Adapty. On a le nombre d'abonnés, le suivi du MRR et les données de churn, mais pas l'analyse par cohortes, la LTV prédictive ni la segmentation avancée des plateformes plus chères. Si on a besoin de ces analytics, il faudra les construire soi-même ou brancher un outil d'analytics séparé.

La préoccupation avec Glassfy, c'est la taille de l'équipe et la viabilité à long terme. C'est une opération plus petite que RevenueCat ou Adapty, ce qui veut dire des temps de réponse du support plus longs et moins de ressources d'ingénierie dédiées aux améliorations du SDK. Pour un side project ou une app dans la fourchette $5k-20k MRR où le coût compte plus que les fonctionnalités, c'est un compromis raisonnable. Pour la source de revenu principale, la petite taille de l'équipe est un facteur de risque à considérer.

Quand Glassfy a du sens : On surveille le budget, le modèle d'abonnement est simple (pas d'entitlements complexes ni d'expérimentations tarifaires), et on veut des coûts prévisibles en grandissant.

StoreKit 2 — le chemin natif gratuit (iOS)

StoreKit 2, c'est le framework natif d'Apple pour les subscriptions, et il est vraiment bien maintenant. Le StoreKit original était notoirement pénible — des API basées sur des callbacks, une validation de reçus peu fiable et des edge cases qui causaient des bugs de billing qu'on mettait des semaines à débugger. StoreKit 2 a tout jeté et reparti de zéro.

L'API est async/await, ce qui signifie du code Swift propre au lieu de l'enfer des callbacks. Les transactions sont signées en JWS, donc on peut les valider sur son serveur sans envoyer les reçus à l'endpoint de validation d'Apple. L'API Transaction.currentEntitlements donne un moyen simple de vérifier ce que l'utilisateur a payé. Les infos de renouvellement, l'éligibilité aux offres et la gestion des locales de prix ont toutes des API propres.

Les server notifications V2 informent le backend des événements d'abonnement en temps réel — renouvellements, annulations, problèmes de facturation, grace periods. Combinées avec l'App Store Server API pour interroger l'historique des abonnements, on peut construire un backend complet de gestion d'abonnements sans SDK tiers.

Le coût du passage au natif, c'est le temps d'ingénierie. Il faut construire et maintenir sa propre gestion d'état d'abonnement côté serveur. Il faut gérer les edge cases — le partage familial, la rédemption de codes promo, les retries de facturation, les upgrades et downgrades d'abonnement. Il faut construire son propre dashboard analytics ou envoyer les données vers un outil d'analytics. RevenueCat fait tout ça out of the box.

Pour un développeur solo qui shippe une app iOS-only, le calcul dépend du MRR et des compétences en ingénierie. Si on est à $5k MRR et à l'aise en Swift, passer au natif économise un frais mensuel croissant et supprime une dépendance. Si on est à $50k MRR et qu'on embauche des ingénieurs, le coût en temps de maintenir l'infrastructure de billing dépasse probablement les frais RevenueCat.

Le vrai compromis : Zéro dollars de frais SDK versus 20-40 heures de développement initial et 2-5 heures par mois de maintenance pour l'infrastructure de billing. Multipliez votre taux horaire par ces heures et comparez à la facture RevenueCat.

Google Play Billing — le chemin natif Android

Google Play Billing Library est l'interface de facturation obligatoire pour les apps sur le Play Store. La version 5+ a introduit la refonte du modèle d'abonnement avec les base plans et les offres, et les dernières versions ont significativement amélioré l'expérience développeur.

Le système de base plans et offres donne une tarification d'abonnement flexible. On peut créer plusieurs base plans pour un même abonnement (mensuel, annuel, prépayé), ajouter des offres d'introduction, et gérer les upgrades et downgrades. Le système d'offres est plus flexible que ce qu'Apple propose avec StoreKit, bien que la surface d'API soit plus large et plus complexe.

L'intégration côté serveur utilise les Real-time Developer Notifications (RTDN) de Google via Pub/Sub et la Play Developer API pour interroger les détails d'achat. L'architecture est solide mais la documentation est dense et le handling d'erreurs a plus d'edge cases que StoreKit 2.

Passer au natif sur Android, c'est le même compromis que sur iOS : zéro coût de SDK en échange de temps d'ingénierie. La complication supplémentaire sur Android, c'est la gestion du billing à travers les différents états des devices, les limitations de traitement en arrière-plan et la variété des configurations matérielles.

Pour les apps cross-platform, utiliser le billing natif sur les deux plateformes signifie maintenir deux implémentations de billing séparées, deux flux de validation côté serveur et deux ensembles de logique d'état d'abonnement. C'est là que les SDK cross-platform comme RevenueCat apportent leur valeur la plus claire — une seule API, un seul dashboard, un seul endpoint de webhook.

Le chemin pragmatique pour les apps cross-platform : Si on construit pour iOS et Android, passer au natif sur les deux plateformes double la charge d'ingénierie billing. Un SDK cross-platform se rentabilise généralement en complexité d'ingénierie réduite pour toute équipe de moins de 5-10 ingénieurs.

Comparaison des coûts à grande échelle

Voici ce qu'on paie réellement aux différents niveaux de revenu (coûts mensuels approximatifs, hors commissions Apple/Google qui s'appliquent de toute façon) :

A $10k MRR : RevenueCat coûte $100-120. Adapty est gratuit-$24. Qonversion est à $99. Superwall est à $99 (plus le SDK d'abonnement). Glassfy est à $49. Le natif est à $0 mais coûte 20-40 heures de temps d'ingénierie initial.

A $50k MRR : RevenueCat coûte $400-600. Adapty et Qonversion tournent autour de $199-300 selon le plan. Glassfy reste à $49-99. Le natif est toujours à $0.

A $100k MRR : RevenueCat coûte $800-1,200. Adapty et Qonversion passent en tarification custom. Glassfy reste en forfait. Le natif continue de coûter $0 en frais, et les économies mensuelles par rapport à RevenueCat financent désormais une part significative du temps d'un ingénieur.

Le point d'inflexion où les alternatives ou le natif commencent à avoir un sens financier se situe autour de $30k-50k MRR. En dessous, le plan gratuit de RevenueCat et l'intégration rapide en font le choix pragmatique. Au-dessus, les économies liées au switch ou au passage au natif se cumulent vite.

Quand rester sur RevenueCat

RevenueCat reste le bon choix quand :

• On est en phase de product-market fit. Le plan gratuit et l'intégration rapide permettent de se concentrer sur l'app plutôt que sur l'infrastructure de billing. On optimise les coûts après avoir prouvé que les gens paient.
• On shippe sur iOS et Android. Le SDK cross-platform avec une API unifiée et un seul dashboard vaut le prix si on n'a pas d'ingénieurs dédiés au billing.
• L'équipe est petite et le temps est précieux. Les heures qu'on économise à ne pas construire d'infrastructure d'abonnement valent plus que les frais RevenueCat à la plupart des niveaux de revenu indie.
• On s'appuie sur leurs analytics. Les analytics d'abonnés de RevenueCat, les graphiques de cohortes et l'écosystème d'intégrations (Amplitude, Mixpanel, alertes Slack) apportent une vraie valeur opérationnelle.
• On n'optimise pas activement ses paywalls. Si le paywall est "assez bien" et que la croissance vient de l'acquisition plutôt que de l'optimisation de la conversion, les fonctionnalités de paywall intégrées de RevenueCat suffisent.

RevenueCat est devenu le standard pour de bonnes raisons. Le SDK est poli, la doc est excellente, la communauté est active, et le produit fonctionne. Les alternatives de cette liste ne sont pas meilleures sur tous les plans — elles sont meilleures sur des dimensions spécifiques (prix, expérimentation, attribution ou coût à grande échelle) selon ce qui compte le plus pour l'app aujourd'hui.

Ce qu'il faut savoir avant de migrer

Quitter RevenueCat demande de la préparation. Voici ce qu'il faut anticiper :

1. L'état des abonnés est la partie difficile. RevenueCat maintient un enregistrement canonique des entitlements, de l'historique de transactions et du statut de renouvellement de chaque abonné. Le nouveau système a besoin de ces données ou d'une stratégie pour gérer la période de transition. Il faut exporter les données d'abonnés avant de commencer.

2. Faire tourner les deux systèmes en parallèle. Pas de bascule sèche. On shippe une mise à jour d'app qui initialise l'ancien et le nouveau SDK, on valide que les états d'abonnement correspondent, et on fait tourner en parallèle pendant au moins un cycle de facturation complet avant de retirer RevenueCat.

3. Les notifications serveur se chevauchent. RevenueCat et le nouveau système recevront tous les deux les server notifications de l'App Store/Play Store pendant la transition. Il faut s'assurer que le backend gère ça correctement sans double-traitement des événements.

4. Le swap du SDK est la partie facile. Remplacer les appels au SDK RevenueCat par un autre SDK ou par StoreKit/Play Billing natif est du refactoring classique. La complexité vit dans la migration de l'état côté backend, pas dans le code client.

5. Prévoir 2-4 semaines pour une app de taille moyenne. Une semaine pour le swap du SDK et les tests, une semaine pour la migration backend, et une à deux semaines en parallèle pour attraper les edge cases. Il ne faut pas brusquer ça — les bugs de billing d'abonnement sont le genre qui coûte de l'argent réel.

6. Garder les données historiques de RevenueCat. Même après la migration, les analytics historiques de RevenueCat restent précieuses pour comprendre les cohortes pré-migration. Il faut exporter les graphiques et rapports avant de fermer le compte.

Le meilleur moment pour migrer, c'est pendant une période de MRR stable — pas pendant un pic de croissance ni un lancement produit majeur. Et la meilleure raison de migrer, c'est un bénéfice clair et quantifiable (économies, meilleurs outils d'expérimentation, réduction du risque de dépendance) plutôt qu'un sentiment vague qu'on devrait posséder plus de son stack.