Installer et configurer le SDK Adapty dans un projet React Native pur
Ce guide s’applique uniquement aux projets React Native purs (sans Expo). Si vous utilisez Expo, suivez plutôt le guide d’installation pour Expo.
Le SDK Adapty comprend deux modules clés pour une intégration fluide dans votre application React Native :
- Core Adapty : ce module est indispensable au bon fonctionnement d’Adapty dans votre application.
- AdaptyUI : ce module est nécessaire si vous utilisez le Adapty Paywall Builder, un outil no-code convivial pour créer facilement des paywalls multiplateformes. AdaptyUI est activé automatiquement avec le module principal.
Vous voulez voir un exemple concret d’intégration du SDK Adapty dans une application mobile ? Consultez nos exemples d’applications, qui illustrent la configuration complète, notamment l’affichage des paywalls, les achats et d’autres fonctionnalités de base.
Prérequis
Le SDK React Native d’Adapty requiert iOS 15.0 ou supérieur.
La compilation pour iOS nécessite Swift 6.0 ou une version ultérieure. Le mode Kids requiert Swift 6.1 ou une version ultérieure.
À partir du SDK v3.17, Adapty SDK utilise Google Play Billing Library v8.0.0 par défaut.
L’installation du SDK correspond à l’étape 5 de la configuration d’Adapty. Avant que les achats fonctionnent dans votre app, vous devez également connecter votre app aux stores, puis créer des produits, un paywall et un placement dans l’Adapty Dashboard. Le guide de démarrage rapide décrit toutes les étapes requises.
Installer le SDK Adapty
À partir de la v4, le SDK React Native d’Adapty ne prend plus en charge l’installation CocoaPods de ses dépendances natives. Si vous avez besoin de la v4 ou d’une version ultérieure (pour le Flow Builder), suivez plutôt SDK Adapty 4.0 : activer Swift Package Manager ci-dessous.
- Installez le SDK Adapty (cela installe également
@adapty/coreautomatiquement) :# using npm npm install react-native-adapty # or using yarn yarn add react-native-adapty - Pour iOS, installez les pods :
cd ios && pod install
Pour Android, si votre version de React Native est antérieure à 0.73.0 (cliquez pour développer)
Mettez à jour le fichier /android/build.gradle. Assurez-vous que la dépendance kotlin-gradle-plugin:1.8.0 ou une version plus récente est présente :
...
buildscript {
...
dependencies {
...
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0"
}
}
...SDK Adapty 4.0 : activer Swift Package Manager
Le SDK React Native 4.0 — qui ajoute la prise en charge du Flow Builder — nécessite React Native 0.75 ou une version ultérieure. Installez le SDK :
npm install react-native-adapty@^4.0.0
# or using yarn
yarn add react-native-adapty@^4.0.0
La v4 récupère les SDK iOS natifs (Adapty, AdaptyUI, AdaptyPlugin) via Swift Package Manager plutôt que via des sous-dépendances CocoaPods (le dépôt de specs CocoaPods passe en lecture seule en décembre 2026). SPM nécessite des frameworks dynamiques — ajoutez ce qui suit dans la cible de votre ios/Podfile, puis réinstallez les pods :
use_frameworks! :linkage => :dynamic
cd ios && pod install --repo-update
Si vous récupériez auparavant Adapty, AdaptyUI ou AdaptyPlugin en tant que sous-dépendances CocoaPods, supprimez d’abord toute ligne pod 'Adapty', pod 'AdaptyUI' ou pod 'AdaptyPlugin' de votre Podfile.
Passer de la liaison statique par défaut aux frameworks dynamiques peut entrer en conflit avec des bibliothèques qui ne prennent pas encore en charge les en-têtes modulaires, et est incompatible avec Flipper. Consultez Migrer le SDK React Native Adapty vers la v4 pour plus de détails.
Activer le module Adapty du SDK Adapty
Pour obtenir votre Public SDK Key :
- Accédez à l’Adapty Dashboard et naviguez vers App settings → General.
- Dans la section Api keys, copiez la Public SDK Key (et NON la Secret Key).
- Remplacez
"YOUR_PUBLIC_SDK_KEY"dans le code.
Ou obtenez-la de façon programmatique via l’Adapty CLI :
npm install -g adapty
adapty auth login
adapty apps list
Ou, directement :
npx adapty auth login
adapty apps list
- Assurez-vous d’utiliser la Public SDK key pour l’initialisation d’Adapty — la Secret key ne doit être utilisée que pour l’API côté serveur.
- Les SDK keys sont propres à chaque application, donc si vous avez plusieurs applications, veillez à choisir la bonne.
Copiez le code suivant dans App.tsx pour activer Adapty :
adapty.activate('YOUR_PUBLIC_SDK_KEY');
Attendez que activate soit résolu avant d’appeler toute autre méthode du SDK Adapty. Consultez Ordre des appels dans le SDK React Native pour la séquence complète.
Configurez maintenant les paywalls dans votre application :
- Si vous utilisez Adapty Paywall Builder, suivez le démarrage rapide avec Paywall Builder.
- Si vous créez votre propre interface de paywall, consultez le démarrage rapide pour les paywalls personnalisés.
Pour éviter les erreurs d’activation en environnement de développement, utilisez les conseils.
Activer le module AdaptyUI du SDK Adapty
Si vous prévoyez d’utiliser le Paywall Builder, vous avez besoin du module AdaptyUI. Il est activé automatiquement lorsque vous activez le module principal ; vous n’avez rien d’autre à faire.
Configuration optionnelle
Journalisation
Configurer le système de journalisation
Adapty enregistre les erreurs et d’autres informations importantes pour vous aider à comprendre ce qui se passe. Les niveaux suivants sont disponibles :
| Niveau | Description |
|---|---|
error | Seules les erreurs seront enregistrées |
warn | Les erreurs et les messages du SDK qui ne causent pas d’erreurs critiques mais méritent attention seront enregistrés |
info | Les erreurs, avertissements et divers messages d’information seront enregistrés |
verbose | Toute information supplémentaire pouvant être utile lors du débogage, comme les appels de fonctions, les requêtes API, etc., sera enregistrée |
Vous pouvez définir le niveau de journalisation dans votre application avant ou pendant la configuration d’Adapty :
// Set log level before activation
// 'verbose' is recommended for development and the first production release
adapty.setLogLevel('verbose');
// Or set it during configuration
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
logLevel: 'verbose',
});
Politiques de données
Adapty ne stocke pas les données personnelles de vos utilisateurs à moins que vous ne les envoyiez explicitement, mais vous pouvez mettre en place des politiques de sécurité des données supplémentaires pour vous conformer aux directives des stores ou des pays.
Désactiver la collecte et le partage des adresses IP
Lors de l’activation du module Adapty, définissez ipAddressCollectionDisabled sur true pour désactiver la collecte et le partage des adresses IP des utilisateurs. La valeur par défaut est false.
Utilisez ce paramètre pour renforcer la confidentialité des utilisateurs, vous conformer aux réglementations régionales de protection des données (comme le RGPD ou le CCPA), ou réduire la collecte de données inutile lorsque les fonctionnalités basées sur l’IP ne sont pas requises pour votre application.
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
ipAddressCollectionDisabled: true,
});
Désactiver la collecte et le partage de l’identifiant publicitaire
Lors de l’activation du module Adapty, définissez ios.idfaCollectionDisabled (iOS) ou android.adIdCollectionDisabled (Android) sur true pour désactiver la collecte des identifiants publicitaires. La valeur par défaut est false.
Utilisez ce paramètre pour vous conformer aux politiques de l’App Store/Play Store, éviter de déclencher la demande App Tracking Transparency, ou si votre application ne nécessite pas d’attribution publicitaire ni d’analyse basée sur les identifiants publicitaires.
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
ios: {
idfaCollectionDisabled: true,
},
android: {
adIdCollectionDisabled: true,
},
});
Configurer le cache média pour AdaptyUI
Par défaut, AdaptyUI met en cache les médias (images et vidéos) pour améliorer les performances et réduire l’utilisation du réseau. Vous pouvez personnaliser les paramètres du cache en fournissant une configuration personnalisée.
Utilisez mediaCache pour remplacer les paramètres de cache par défaut :
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
mediaCache: {
memoryStorageTotalCostLimit: 200 * 1024 * 1024, // Optional: memory cache size in bytes
memoryStorageCountLimit: 2147483647, // Optional: max number of items in memory
diskStorageSizeLimit: 200 * 1024 * 1024, // Optional: disk cache size in bytes
},
});
Paramètres :
| Paramètre | Requis | Description |
|---|---|---|
| memoryStorageTotalCostLimit | optionnel | Taille totale du cache en mémoire en octets. Par défaut, valeur spécifique à la plateforme. |
| memoryStorageCountLimit | optionnel | Limite du nombre d’éléments dans le stockage en mémoire. Par défaut, valeur spécifique à la plateforme. |
| diskStorageSizeLimit | optionnel | Limite de taille des fichiers sur le disque en octets. Par défaut, valeur spécifique à la plateforme. |
Activer les niveaux d’accès locaux (Android)
Par défaut, les niveaux d’accès locaux sont activés sur iOS et désactivés sur Android. Pour les activer également sur Android, définissez localAccessLevelAllowed sur true :
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
android: {
localAccessLevelAllowed: true,
},
});
Effacer les données lors de la restauration d’une sauvegarde
Lorsque clearDataOnBackup est défini sur true, le SDK détecte quand l’application est restaurée depuis une sauvegarde iCloud et supprime toutes les données SDK stockées localement, y compris les informations de profil en cache, les détails des produits et les paywalls. Le SDK s’initialise alors avec un état vierge. La valeur par défaut est false.
Seul le cache local du SDK est supprimé. L’historique des transactions avec Apple et les données utilisateur sur les serveurs Adapty restent inchangés.
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
ios: {
clearDataOnBackup: true
},
});
Conseils pour l’environnement de développement
Retarder l’activation du SDK à des fins de développement
Adapty pré-charge toutes les données utilisateur nécessaires lors de l’activation du SDK, permettant un accès plus rapide aux données actualisées.
Cela peut toutefois poser problème dans le simulateur iOS, qui demande fréquemment une authentification lors du développement. Bien qu’Adapty ne puisse pas contrôler le flux d’authentification StoreKit, il peut différer les requêtes effectuées par le SDK pour obtenir des données utilisateur actualisées.
En activant la propriété __debugDeferActivation, l’appel d’activation est suspendu jusqu’à ce que vous effectuiez le prochain appel au SDK Adapty. Cela évite les demandes d’authentification inutiles si elles ne sont pas nécessaires.
Il est important de noter que cette fonctionnalité est destinée uniquement au développement, car elle ne couvre pas tous les scénarios utilisateur possibles. En production, l’activation ne doit pas être différée, car les appareils réels mémorisent généralement les données d’authentification et ne demandent pas répétitivement les identifiants.
Voici l’approche recommandée :
try {
adapty.activate('PUBLIC_SDK_KEY', {
__debugDeferActivation: isSimulator(), // 'isSimulator' from any 3rd party library
});
} catch (error) {
console.error('Failed to activate Adapty SDK:', error);
// Handle the error appropriately for your app
}
Résoudre les erreurs d’activation du SDK avec le Fast Refresh de React Native
Lors du développement avec le SDK Adapty dans React Native, vous pouvez rencontrer l’erreur : Adapty can only be activated once. Ensure that the SDK activation call is not made more than once.
Cela se produit parce que la fonctionnalité de rechargement rapide de React Native déclenche plusieurs appels d’activation pendant le développement. Pour éviter cela, utilisez l’option __ignoreActivationOnFastRefresh définie sur __DEV__ (le drapeau de mode développement de React Native).
try {
adapty.activate('PUBLIC_SDK_KEY', {
__ignoreActivationOnFastRefresh: __DEV__,
});
} catch (error) {
console.error('Failed to activate Adapty SDK:', error);
// Handle the error appropriately for your app
}
Configurer le mode mock pour les tests locaux
Pour le développement local et les tests, vous pouvez activer le mode mock afin d’éviter d’avoir besoin de comptes sandbox App Store/Google Play et d’accélérer les itérations. Le mode mock contourne complètement les modules natifs d’Adapty et renvoie des données simulées.
Le mode mock n’est pas un outil pour tester de vrais achats :
- Il n’ouvre pas les flux d’achat App Store / Google Play et ne crée pas de vraies transactions.
- Il n’affiche pas les paywalls/onboardings créés avec Adapty Paywall Builder (AdaptyUI).
- Les modules natifs d’Adapty sont complètement contournés — même des fichiers SDK natifs manquants dans la build Xcode/Android ou une clé API invalide ne déclencheront pas d’erreurs.
- Aucune donnée n’est envoyée aux serveurs d’Adapty.
Pour tester de vrais achats et les paywalls Paywall Builder, désactivez le mode mock et utilisez des comptes sandbox.
Pour activer le mode mock, définissez enableMock sur true :
adapty.activate('YOUR_PUBLIC_SDK_KEY', {
enableMock: true,
});
Lorsque le mode mock est actif :
- Toutes les méthodes Adapty renvoient des données mock sans effectuer de requêtes réseau vers les serveurs d’Adapty.
- Par défaut, le profil mock initial n’a pas d’abonnements actifs.
- Par défaut,
makePurchase(...)simule un achat réussi et accorde l’accès premium.
Vous pouvez personnaliser les données mock en utilisant mockConfig lors de l’activation. Consultez le format de configuration et les paramètres pris en charge ici.
try {
await adapty.activate('YOUR_PUBLIC_SDK_KEY', {
mockConfig: {
// Customize the initial mock profile (optional)
},
});
} catch (error) {
console.error('Failed to activate Adapty SDK:', error);
}
Si vous avez besoin d’appeler des méthodes du SDK avant l’activation (comme isActivated() ou setLogLevel()), utilisez enableMock() avant activate(). Si le bridge est déjà initialisé, cette méthode ne fait rien.
adapty.enableMock(); // Optional: pass mockConfig to customize mock data
// Now you can call methods before activation
await adapty.activate('YOUR_PUBLIC_SDK_KEY');
Dépannage
Erreur de version iOS minimale
Si vous obtenez une erreur de version iOS minimale, mettez à jour votre Podfile :
-platform :ios, min_ios_version_supported
+platform :ios, '15.0'
Conflit de manifeste Android Auto Backup
Certains SDKs (dont Adapty) embarquent leur propre configuration Android Auto Backup. Si vous utilisez plusieurs SDKs qui définissent des règles de sauvegarde, la fusion du manifeste Android peut échouer avec une erreur mentionnant android:fullBackupContent, android:dataExtractionRules ou android:allowBackup.
Symptômes typiques : Manifest merger failed: Attribute application@dataExtractionRules value=(@xml/your_data_extraction_rules) is also present at [com.other.sdk:library:1.0.0] value=(@xml/other_sdk_data_extraction_rules)
Ces modifications doivent être effectuées dans votre répertoire de la plateforme Android (généralement situé dans le dossier android/ de votre projet).
Pour résoudre ce problème, vous devez :
-
Indiquer au gestionnaire de fusion de manifeste d’utiliser les valeurs de votre application pour les attributs liés à la sauvegarde.
-
Créer des fichiers de règles de sauvegarde qui fusionnent les règles d’Adapty avec celles des autres SDKs.
1. Ajoutez l’espace de noms tools à votre manifeste
Dans votre fichier AndroidManifest.xml, assurez-vous que la balise racine <manifest> inclut tools :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
package="com.example.app">
...
</manifest>
2. Remplacez les attributs de sauvegarde dans <application>
Dans le même fichier AndroidManifest.xml, mettez à jour la balise <application> afin que votre application fournisse les valeurs finales et indique au gestionnaire de fusion de remplacer les valeurs des bibliothèques :
<application
android:name=".App"
android:allowBackup="true"
android:fullBackupContent="@xml/sample_backup_rules"
android:dataExtractionRules="@xml/sample_data_extraction_rules"
tools:replace="android:fullBackupContent,android:dataExtractionRules">
...
</application>
Si un SDK définit également android:allowBackup, incluez-le dans tools:replace :
tools:replace="android:allowBackup,android:fullBackupContent,android:dataExtractionRules"
3. Créez les fichiers de règles de sauvegarde fusionnés
Créez des fichiers XML dans le répertoire res/xml/ de votre projet Android, en combinant les règles d’Adapty avec celles des autres SDKs. Android utilise des formats de règles de sauvegarde différents selon la version de l’OS, donc créer les deux fichiers garantit la compatibilité avec toutes les versions d’Android prises en charge par votre application.
Les exemples ci-dessous utilisent AppsFlyer comme exemple de SDK tiers. Remplacez ou ajoutez des règles pour tout autre SDK que vous utilisez dans votre application.
Pour Android 12 et supérieur (utilise le nouveau format de règles d’extraction de données) :
<?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
<cloud-backup>
<exclude domain="sharedpref" path="appsflyer-data"/>
<exclude domain="sharedpref" path="appsflyer-purchase-data"/>
<exclude domain="database" path="afpurchases.db"/>
<exclude domain="sharedpref" path="AdaptySDKPrefs.xml"/>
</cloud-backup>
<device-transfer>
<exclude domain="sharedpref" path="appsflyer-data"/>
<exclude domain="sharedpref" path="appsflyer-purchase-data"/>
<exclude domain="database" path="afpurchases.db"/>
<exclude domain="sharedpref" path="AdaptySDKPrefs.xml"/>
</device-transfer>
</data-extraction-rules>
Pour Android 11 et inférieur (utilise l’ancien format de sauvegarde complète) :
<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
<exclude domain="sharedpref" path="appsflyer-data"/>
<exclude domain="sharedpref" path="AdaptySDKPrefs.xml"/>
Les achats échouent après le retour depuis une autre application sur Android
Si l’Activity qui démarre le flux d’achat utilise un launchMode non standard, Android peut la recréer ou la réutiliser de manière incorrecte lorsque l’utilisateur revient depuis Google Play, une application bancaire ou un navigateur. Cela peut entraîner la perte du résultat de l’achat ou son traitement comme annulé.
Pour que les achats fonctionnent correctement, utilisez uniquement les modes de lancement standard ou singleTop pour l’Activity qui démarre le flux d’achat, et évitez tout autre mode.
Dans votre AndroidManifest.xml, assurez-vous que l’Activity qui démarre le flux d’achat est définie sur standard ou singleTop :
<activity
android:name=".MainActivity"
android:launchMode="standard" />
Erreurs de build Swift 6 causées par le remplacement de SWIFT_VERSION dans le Podfile
Lors de la compilation de votre application React Native pour iOS, vous pouvez voir des erreurs de compilation Swift 6 sur les cibles de pod Adapty. Les symptômes typiques incluent des incompatibilités @Sendable dans AdaptyUIBuilderLogic, une conformité Sendable manquante sur les types Adapty, ou des erreurs d’isolation d’acteur.
Les pods Adapty déclarent s.swift_version = '6.0' et nécessitent Swift 6 pour être compilés. Votre propre code d’application peut rester sur Swift 5 — seules les cibles de pod Adapty (Adapty, AdaptyUI, AdaptyUIBuilder, AdaptyLogger, AdaptyPlugin) doivent être compilées avec Swift 6.
La cause la plus fréquente est un hook post_install dans ios/Podfile qui réécrit SWIFT_VERSION pour chaque cible de pod :
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '5.9'
end
end
end
Correctif : Excluez les cibles de pod Adapty du remplacement :
post_install do |installer|
installer.pods_project.targets.each do |target|
next if %w[Adapty AdaptyUI AdaptyUIBuilder AdaptyLogger AdaptyPlugin].include?(target.name)
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '5.9'
end
end
end
Exécutez ensuite pod install depuis le répertoire ios/ et recompilez.
Pour vérifier, ouvrez ios/Pods/Pods.xcodeproj, sélectionnez la cible de pod Adapty → Build Settings → Swift Language Version. Elle devrait indiquer Swift 6.