@cookiechimp/react-native. See the
React Native guide to install the SDK first.
How vendors follow consent
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:
Firebase
connectFirebase registers the Firebase presets you pass and sends Google
Consent Mode v2 signals to Firebase Analytics on launch and after every
decision.
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:
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:- The CookieChimp banner asks for consent under GDPR, ePrivacy or US state laws, by category and vendor.
- 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.