Skip to main content
Connect the analytics, attribution and advertising SDKs in your app to the user’s consent with @cookiechimp/react-native. See the React Native guide to install the SDK first. Each vendor has a name and a category. When the name matches a service in your dashboard, the user’s choice for that service applies; otherwise the category’s choice applies. onStart runs when consent allows the vendor and onStop when consent is withdrawn. Nothing starts before the SDK has loaded the stored decision, and nothing starts before a decision where the banner asks for opt-in consent. Turn off each vendor SDK’s automatic collection in its own setup (native config, Info.plist, AndroidManifest.xml or its init options) so it collects nothing before onStart. The preset notes below say how for each SDK. An SDK that starts in native code (AppDelegate or MainApplication) runs before any JavaScript, so a JavaScript call at launch is too late to stop it: turn it off natively or delay its initialization until consent.

Presets

Presets switch common mobile SDKs on and off for you. They use the service names and categories from CookieChimp’s mobile SDK library, so a vendor added from the dashboard library follows the user’s choice for that service.
Change a preset’s name or category to match your dashboard:
For any other SDK, register it with your own callbacks:

Firebase

connectFirebase registers the Firebase presets you pass and sends Google Consent Mode v2 signals to Firebase Analytics on launch and after every decision.
Signals follow the same category mapping as the web SDK: Under GDPR every signal is denied until the user chooses. Under an opt-out (CCPA) banner the signals start granted. Set the native defaults to denied as well, so the first events of a launch are covered before the SDK has loaded. In firebase.json at the root of your app:
Options: connectFirebase returns a function that disconnects Firebase. firebaseConsent(categories, mapping?) returns the signals for a decision if you call setConsent yourself.

App Tracking Transparency (iOS)

Apple requires the App Tracking Transparency (ATT) prompt before an app tracks users across other companies’ apps and websites, including any use of the advertising identifier (IDFA). A consent banner does not replace it, and a banner choice cannot override the user’s ATT answer. The two answer different questions, so many apps show both:
  1. The CookieChimp banner asks for consent under GDPR, ePrivacy or US state laws, by category and vendor.
  2. When the user accepts the category that tracks (usually marketing), the ATT prompt asks iOS for permission to track.
requestTrackingAfterConsent does step 2. It never shows the prompt while the category is rejected or undecided, which means users who already said no are not asked again. It does nothing on Android.
iOS shows the prompt only once per install and only while the app is active; the helper waits for the app to be active. On later launches request resolves with the stored answer without a prompt, so onStatus keeps your SDKs in sync. Add NSUserTrackingUsageDescription to Info.plist (with Expo, the expo-tracking-transparency config plugin’s userTrackingPermission). Keep these rules in mind:
  • If ATT is denied, do not track, even if the user accepted marketing in the banner. Vendor SDKs read the ATT status themselves for the IDFA; pass the status on where an SDK asks for it.
  • Do not show your own screen that imitates the system prompt, or offer rewards for allowing tracking.
  • Banner consent still applies when ATT is authorized: a user can withdraw marketing consent at any time and presets stop the vendors.
This is guidance, not legal advice. Check your setup with your privacy counsel and Apple’s App Review Guidelines and User Privacy and Data Use pages.

Google Play

Android has no system tracking prompt. Your banner decision is the consent signal; describe each vendor’s data in your Google Play Data safety form. The data labels you set for each vendor in the dashboard use the same data types.