Votre plan de migration comprend 5 étapes logiques et prend en moyenne 2 heures. 90 % des migrations se font en moins d’une journée de travail.

1. Découvrez les différences essentielles ; créez et configurez un compte Adapty (5 minutes) ;
2. Installez le SDK Adapty pour votre plateforme (iOS, Android, React Native, Flutter, Kotlin Multiplatform, Unity) à la place du SDK RevenueCat (1 heure) ;
3. Configurez les notifications serveur Apple App Store vers Adapty et (optionnellement) le transfert d’événements bruts (5 minutes) ;
4. Testez et publiez les mises à jour de votre application (30 minutes) ;
5. (Optionnel) Exportez vos données historiques RevenueCat au format CSV via les exports de données planifiés de RevenueCat (5 minutes) ;
6. (Optionnel) Importez les données historiques via le support Adapty (30 minutes).

Avant de publier une nouvelle version de votre application avec le SDK Adapty, pensez à consulter notre checklist de publication.

Découvrir les différences essentielles ; créer et préparer un compte Adapty

Les SDK Adapty et RevenueCat sont conçus de façon similaire. La principale différence réside dans l’utilisation du réseau et la rapidité : le SDK Adapty est conçu pour vous fournir les informations à la demande, aussi vite que possible. Par exemple, lors de la récupération d’un paywall, vous obtenez d’abord le Remote Config pour préparer votre onboarding ou votre paywall, puis vous demandez les produits dans une requête dédiée.

La terminologie diffère légèrement :

RevenueCat	Adapty
Package	Produit
Offering	Paywall
Paywall	Paywall Builder
Entitlement	Niveau d’accès

Adapty intègre la notion de placement. Il s’agit d’un endroit logique dans votre app où l’utilisateur peut effectuer un achat. Dans la plupart des cas, vous avez un ou deux placements :

• Onboarding (car 80 % des achats s’y effectuent) ;
• Général (affiché dans les paramètres ou dans l’app après l’onboarding).

Installer le SDK Adapty et remplacer le SDK RevenueCat

Installez le SDK Adapty pour votre plateforme (iOS, Android, React Native, Flutter, Kotlin Multiplatform, Unity) dans votre application.

Vous devez remplacer quelques méthodes SDK côté application. Voici les fonctions les plus courantes et comment les remplacer par le SDK Adapty.

Activation du SDK

Remplacez Purchases.configure par Adapty.activate.

Récupération des paywalls (offres)

Remplacez Purchases.shared.getOfferings par Adapty.getPaywall.

Dans Adapty, vous demandez toujours le paywall via un identifiant de placement. En pratique, vous ne récupérez qu’un ou deux paywalls au maximum, c’est donc un choix délibéré pour accélérer le SDK et réduire la consommation réseau.

Obtenir un profil utilisateur

Remplacez Purchases.shared.getCustomerInfo par Adapty.getProfile.

Récupérer les produits

Dans RevenueCat, vous utilisez la structure suivante : Purchases.shared.getOfferings puis self.offering?.availablePackages.

Dans Adapty, vous commencez par récupérer un paywall (voir ci-dessus) pour accéder immédiatement au Remote Config d’Adapty, puis vous appelez Adapty.getPaywallProducts pour obtenir les produits.

Effectuer un achat

Remplacez Purchases.shared.purchase par Adapty.makePurchase.

Vérification du niveau d’accès (entitlement)

Obtenez un profil client (lisez la section ci-dessus en premier) et remplacez

customerInfo?.entitlements["premium"]?.isActive == true

par

profile.accessLevels["premium"]?.isActive == true.

Restaurer un achat

Remplacez Purchases.shared.restorePurchases par Adapty.restorePurchases.

Vérifier si l’utilisateur est connecté

Remplacez Purchases.shared.isAnonymous par if profile.customerUserId == nil.

Connectez-vous en tant qu’utilisateur

Remplacez Purchases.shared.logIn par Adapty.identify.

Déconnexion d’un utilisateur

Remplacez Purchases.shared.logOut par Adapty.logout.

Basculer les notifications côté serveur de l’App Store vers Adapty

Découvrez comment procéder ici.

Testez et publiez une nouvelle version de votre app

Si vous lisez ceci, vous avez déjà :

• Configuré Adapty Dashboard
• Installé le SDK Adapty
• Remplacé la logique SDK par les fonctions Adapty
• Basculé les notifications serveur de l’App Store vers Adapty et, optionnellement, activé le transfert des événements bruts vers RevenueCat
• Effectué un achat en sandbox
• Publié une nouvelle version de l’app

Si vous avez coché les points ci-dessus, faites simplement un achat test en sandbox, puis publiez l’app.

(Facultatif) Exportez vos données historiques RevenueCat au format CSV

Exportez vos données historiques depuis RevenueCat au format CSV en suivant les instructions de la documentation officielle de RevenueCat.

(Optionnel) Demander à l’assistance RevenueCat les Google Purchase Tokens

Si vous devez importer des transactions Google Play, contactez l’assistance RevenueCat pour obtenir un fichier CSV contenant les Google Purchase Tokens via leur page d’assistance. Le Google Purchase Token est un identifiant unique fourni par Google Play pour chaque transaction, indispensable pour suivre et vérifier précisément les achats dans Adapty. Cette information n’est pas incluse dans le fichier d’export standard. Le fichier contient les trois colonnes suivantes :

• user_id
• google_purchase_token
• google_product_id

Écrivez-nous pour importer vos données historiques

Contactez-nous via le chat du site ou par e-mail à support@adapty.io en joignant vos fichiers CSV.

1. Envoyez directement le fichier CSV exporté depuis RevenueCat à notre équipe support.
2. Si vous importez des transactions Google Play, joignez également le fichier CSV contenant les Google Purchase Tokens que vous avez reçu de l’équipe support de RevenueCat.
3. Indiquez-nous quel identifiant utilisateur doit être utilisé comme Customer User ID (l’identifiant principal de l’utilisateur dans Adapty) : rc_original_app_user_id ou rc_last_seen_app_user_id_alias.

Notre équipe Support importera vos transactions dans Adapty. Les données suivantes seront importées dans Adapty pour chaque transaction :

Paramètre	Description
user_id	Customer User ID, l’identifiant principal de votre utilisateur dans Adapty et dans votre système.
apple_original_transaction_id	Pour les chaînes d’abonnements, il s’agit de la date d’achat de la transaction d’origine, liée par store_original_transaction_id.
google_product_id	L’identifiant du produit dans le Google Play Store.
google_purchase_token	Un identifiant unique fourni par Google Play pour chaque transaction, requis pour la validation.
country	Le pays de l’utilisateur.
created_at	La date et l’heure de création de l’utilisateur.
subscription_expiration_date	La date et l’heure d’expiration de l’abonnement.
email	L’adresse e-mail de l’utilisateur final.
phone_number	Le numéro de téléphone de l’utilisateur final.
idfa	L’Identifier for Advertisers (IDFA), attribué par Apple à l’appareil d’un utilisateur.
idfv	L’Identifier for Vendors (IDFV), un code attribué à toutes les applications d’un même développeur et partagé entre ces applications sur un appareil.
advertising_id	Un identifiant unique fourni par le système Android que les annonceurs peuvent utiliser à des fins de suivi.
attribution_channel	Le nom du canal marketing.
attribution_campaign	Le nom de la campagne marketing.
attribution_ad_group	Le groupe d’annonces d’attribution.
attribution_ad_set	L’ensemble d’annonces d’attribution.
attribution_creative	Le mot-clé créatif d’attribution.

En outre, les identifiants d’intégration pour les intégrations suivantes seront importés : Amplitude, Mixpanel, AppsFlyer, Adjust et FacebookAds.

Ce qui ne transparaît pas

• Chaque transaction est revalidée auprès du store lors de l’import, donc les lignes que le store ne reconnaît plus sont supprimées.
• Les lignes sans véritable identifiant de transaction en store — par exemple, les droits promotionnels ou accordés manuellement dans RevenueCat — sont importées en tant que profils sans transactions. Pour restaurer l’accès de ces utilisateurs, accordez-leur un niveau d’accès via l’API côté serveur.
• L’historique des remboursements et des problèmes de facturation n’est pas repris tel quel : un remboursement ne conserve que sa date d’annulation, et l’état de problème de facturation d’un abonnement est enregistré au moment de l’import, et non avec les dates historiques.

FAQ

J’ai installé le SDK Adapty avec succès et publié une nouvelle version de l’app. Que va-t-il se passer pour mes abonnés existants qui n’ont pas mis à jour vers la version intégrant le SDK Adapty ?

La plupart des utilisateurs chargent leur téléphone la nuit, période à laquelle l’App Store met généralement à jour toutes leurs apps automatiquement, donc ça ne devrait pas poser de problème. Il peut rester un petit nombre d’abonnés payants qui n’ont pas effectué la mise à jour, mais ils auront tout de même accès au contenu premium. Vous n’avez pas à vous en inquiéter ni à les forcer à mettre à jour.

Dois-je exporter mes données historiques depuis RevenueCat le plus vite possible, ou vais-je les perdre ?

Pas besoin de vous précipiter : faites d’abord une release avec le SDK Adapty, puis transmettez-nous vos données historiques. Nous restaurerons l’historique des paiements de vos utilisateurs et alimenterons les profils et les graphiques.

J’utilise un MMP (AppsFlyer, Adjust, etc.) et des outils d’analyse (Mixpanel, Amplitude, etc.). Comment m’assurer que tout fonctionnera ?

Vous devez d’abord nous transmettre les identifiants de ces services tiers via notre SDK, afin que nous puissions leur envoyer des données. Consultez le guide d’intégration de l’attribution et celui d’intégration des outils d’analyse. Pour les données historiques et les utilisateurs existants, assurez-vous de nous transmettre ces identifiants à partir des données que vous avez exportées depuis RevenueCat.