This guide covers the full implementation lifecycle: why mobile apps have distinct consent requirements from web, how a React Native consent SDK is structured, step-by-step integration, how to gate third-party SDKs on consent status, and the most common implementation failures that produce technical non-compliance even when the UI looks correct.
Why Mobile Apps Need Consent Management
The privacy compliance challenge in mobile apps is not primarily about showing a banner. It is about controlling the SDK ecosystem. A typical production React Native app integrates between ten and thirty third-party libraries — analytics, advertising, crash reporting, attribution, marketing automation — and every one of them may collect personal data independently. Under GDPR, the app publisher is the data controller responsible for everything those libraries do, regardless of whether the publisher controls what the SDK sends. Learn more about cookie consent implementation for React web apps.
The EDPB's guidance on mobile tracking is explicit: consent must be obtained before any tracking SDK initializes. This creates a technical requirement that does not exist in most web consent implementations — SDKs must be prevented from starting, not just flagged to stop. A consent banner rendered by React Native's component tree that appears visually on screen does not automatically delay native SDK initialization. If an analytics SDK is initialized in your native app delegate or Application class before the JavaScript bridge renders anything, it has already fired its first event before the consent layer exists.
Device identifiers compound this. IDFA on iOS and AAID on Android are classified as personal data under GDPR because they enable persistent cross-app and cross-device tracking. Accessing these identifiers requires explicit consent — the same standard as accessing cookies on the web. Apple's App Tracking Transparency framework adds a system-level prompt specifically for cross-app tracking that must be coordinated with GDPR consent flows. These two requirements are related but distinct: ATT covers cross-app tracking specifically, while GDPR covers all non-essential personal data processing. Both may apply to the same SDK operation.
The practical consequence is that GDPR compliance for mobile apps requires a layered architecture — a consent SDK that controls when the rest of the SDK stack is allowed to initialize, not one that simply records a preference and leaves SDK behaviour unchanged.
What Is a React Native Consent SDK?
A React Native consent SDK is a JavaScript (or bridged native) library that handles the full consent lifecycle in a React Native application: presenting the consent interface, storing consent decisions, exposing consent state to application code, and — in a properly integrated implementation — gating the initialization of other SDKs based on those decisions.
The distinction from a web CMP is architectural. A web CMP operates in a browser context where cookies and scripts can be blocked by the consent platform itself, often through tag manager integration. In a React Native app, there is no tag manager and no browser cookie jar. The consent SDK exposes an API, and the developer is responsible for using that API to control when third-party code runs. The SDK cannot block a native library from initializing unless the developer has structured the initialization sequence correctly.
A mature React Native consent SDK provides four capabilities. The consent UI layer renders the banner or modal — typically a native component for performance, though some SDKs use a WebView shell. The consent storage layer persists decisions securely on device, using Keychain on iOS or EncryptedSharedPreferences on Android, and synchronizes to a backend audit log. The vendor and purpose management layer maintains the structured representation of consent decisions — by purpose (analytics, advertising, personalisation) and by vendor where TCF compliance is required. And the SDK signal control layer exposes the API that application code calls to check whether a given category of processing has consent before initializing the relevant third-party library.
For apps using Google's advertising stack, TCF v2.2 and Google Consent Mode v2 compliance are additional requirements that a production consent SDK must satisfy. Consent Mode v2 requires transmitting four specific parameters to Google services — analytics_storage, ad_storage, ad_user_data, and ad_personalization — based on user choices, and the SDK must handle this automatically through Firebase SDK integration.
How a React Native Consent SDK Works
At initialization, the consent SDK checks local secure storage for an existing consent record. If a valid record exists that covers the current vendor list version, the SDK restores that state and calls any registered consent-ready callbacks without displaying the UI. If no valid record exists — on first launch, or if the vendor list has changed since the last accepted state — the SDK presents the consent interface.
The consent interface captures granular choices per purpose. For GDPR compliance, purposes must be presented with equal prominence for accept and reject: pre-checked boxes, deceptive accept-only flows, and consent as a condition of core app functionality are all violations that European regulators have enforced against mobile apps specifically. Once the user responds, the SDK writes the consent string to secure local storage, logs the decision with a timestamp and the consent UI version to the audit backend, and fires callbacks that application code is listening for.
Application code waits on those callbacks before initializing tracked SDKs. This is the architectural hinge: all third-party SDK initialization must be deferred until the consent SDK has resolved its state — either by confirming existing consent or by receiving a new response. If initialization is not deferred, the SDK runs before consent is known, which is a legal basis violation regardless of what the user subsequently chooses.
After initialization, the consent SDK exposes a synchronous API to check consent state by purpose, which application code calls at the point of each conditional SDK initialization.
Integrating a React Native Consent SDK
The following workflow describes integration with Secure Privacy's React Native SDK. The patterns apply across comparable implementations, with API method names varying by provider.
Step 1: Install the SDK
npm install @secure-privacy/react-native-sdk
# For iOS, install native dependencies:
cd ios && pod install
React Native 0.76+ with the New Architecture uses TurboModules. Ensure the SDK version you install explicitly supports the New Architecture if your project has it enabled.
Step 2: Initialize Early in the App Entry Point
Initialization must happen before any third-party SDK that requires consent. In a React Native app, the earliest reliable point is at the top of your root component or in a native module that runs before the JS bridge. Initialize the SDK with your site ID, the applicable regulatory context, and a callback to receive the resolved consent state:
import ConsentSDK from '@secure-privacy/react-native-sdk';
import { useEffect, useState } from 'react';
export default function App() {
const [consentResolved, setConsentResolved] = useState(false);
useEffect(() => {
ConsentSDK.initialize({
siteId: 'YOUR_SITE_ID',
onConsentReady: (consentState) => {
setConsentResolved(true);
initializeTrackedSDKs(consentState);
}
});
}, []);
if (!consentResolved) {
return <SplashScreen />;
}
return <AppNavigator />;
}
The pattern of gating the rest of the app behind consent resolution is deliberate. It prevents any tracked component from mounting — and triggering its own SDK calls — before consent state is known.
Step 3: The Consent Interface
The SDK handles banner display automatically based on the initialization check. If consent is required, the banner or modal renders. The presentation is configurable: purpose descriptions, button labels, links to your privacy policy, and visual styling should all be set in the SDK dashboard and reflected in the rendered UI. The SDK handles localisation — displaying the consent interface in the device's locale — without requiring the developer to manage translation strings manually.
Step 4: Retrieve Consent Status
After consent resolution, the SDK exposes a synchronous method to check per-purpose consent.
This can also be accessed via a React hook that re-renders on consent changes, useful for components that conditionally render advertising-dependent UI.
Step 5: Gate Third-Party SDK Initialization
This is where most compliance gaps occur in practice. Every SDK that collects personal data must be wrapped in a consent check.
The consequence of not implementing this gating is not hypothetical. A 2025 enforcement case against a retail app resulted in a $1.35 million fine specifically because the opt-out form appeared functional while third-party trackers continued operating. Regulators use network monitoring tools to verify whether SDK traffic stops when consent is declined. If it does not, the consent interface is treated as a dark pattern regardless of its visual design.
Step 6: Provide Ongoing Consent Access
GDPR requires that withdrawal be as easy as the original consent. Your app must include a persistent access point to the consent interface — typically a "Privacy Settings" or "Manage Consent" menu item in your app's settings screen.
When users update their consent, the SDK fires a consent-changed event. Your application code should listen for this and reinitialize or halt the relevant SDKs accordingly.
GDPR Requirements for Mobile Consent
The consent validity requirements under GDPR apply to mobile apps exactly as they do to web. Consent must be freely given — the app's core functionality cannot be conditioned on accepting optional tracking. It must be specific — granular choices by purpose, not a single accept-all. It must be informed — clear explanations of what each purpose involves and which vendors are enabled. And it must be obtained through an unambiguous affirmative action — no pre-checked boxes, no consent by scrolling or continued use.
The mobile-specific compliance layer is the documentation obligation. GDPR's accountability principle requires demonstrating that consent was obtained — not just asserting it. This means the consent SDK must log every decision: the timestamp, the consent UI version displayed, the specific choices made, and the device identifier (anonymised or hashed). This log must be backed up to a server, not stored only on device. Local storage is vulnerable to app reinstallation and device reset. If a regulator requests evidence of consent for a specific user, device-only storage cannot produce it.
For apps with authenticated users, cross-device consent synchronisation is an additional requirement. If a user grants consent on one device, their consent state should follow them across platforms where the same account is authenticated. This requires the consent SDK to store state server-side keyed to the user's account identifier, not only locally keyed to the device.
Handling Third-Party SDKs
The mobile app SDK consent management challenge is that different third-party SDKs integrate at different levels of the app stack. TCF-compliant SDKs — those built to the IAB's Transparency and Consent Framework — read the consent string from standard local storage and respect it automatically. These require the least manual gating: initializing the CMP correctly writes the TC string, and the SDK reads it. Most advertising network SDKs in the programmatic ecosystem support TCF.
Non-TCF SDKs require explicit conditional initialization, as in the pattern above. Crash reporting tools like Crashlytics and Sentry present a nuanced case: if they are configured to strip all personally identifiable information and transmit only anonymised crash data, they may be operable under legitimate interest without consent. But if they transmit device identifiers, user IDs, or any data that could identify an individual, they require consent gating. The vendor's documentation should specify whether the SDK is designed to operate in a privacy mode that satisfies legitimate interest. If it is not, treat it as requiring consent.
Tag manager SDKs that themselves load sub-vendors — Google Tag Manager for Firebase being the common case — require special attention. You are not just gating one SDK; you are gating a runtime tag configuration that can add new tracking vendors without a code change. For these, consent gating should wrap the tag manager initialization itself, and you should configure the tag manager to pass consent signals to each fired tag so that individual tags respect granular consent rather than inheriting the blanket initialization.
Before shipping any third-party SDK, use a network proxy (Charles Proxy, Proxyman, or mitmproxy) to verify traffic patterns. Confirm that declining all optional consent categories prevents the SDK from transmitting data. Confirm that accepting analytics but declining advertising limits transmission accordingly. This verification should be part of your QA process for every release, not a one-time integration check.
Best Practices
Load the consent SDK as early as possible in the app lifecycle. Any delay between app launch and consent SDK initialization is a window in which native code can run without consent context. Where possible, initialize in the native AppDelegate (iOS) or Application class (Android) rather than waiting for the JS bridge.
Delay all third-party SDK initialization until consent is resolved. The splash screen or loading state pattern shown in the integration example above is the correct approach. It prevents any component from mounting before consent state is known.
Store consent locally and remotely. Local storage enables immediate retrieval on next launch without an async roundtrip. Remote backup enables audit evidence and cross-device synchronisation for authenticated users.
Increment your consent version when your privacy policy or vendor list changes materially. Version management in the SDK configuration triggers re-consent for users who accepted an earlier version, ensuring their consent reflects the current data practices.
Support withdrawal at all times. A menu path to the consent interface must be permanently accessible, and consent-changed events must trigger immediate SDK behaviour changes — not on the next app launch.
Test across both iOS and Android with network monitoring at every major release. Consent behaviour can diverge between platforms due to native module differences, and a compliance gap on one platform may not be visible from the other.
Common Integration Problems
Consent UI not displaying. The most common cause is calling getConsentStatus() before initialize() has resolved. The SDK needs to complete its async check against the server to determine whether the current vendor list version matches the stored consent. If application code checks status before this check completes, it may receive a stale or empty state and decide not to show the UI. Always gate status checks and SDK initialization on the onConsentReady callback.
Third-party SDKs loading before consent. This occurs when native SDK initialization happens in the native app delegate or Application class, which runs before the React Native JS bundle is loaded or the consent SDK has initialized. The fix requires moving SDK initialization out of native startup code and into JavaScript, controlled by the consent callback. For SDKs that must be initialized natively for technical reasons, check whether the SDK supports a deferred start mode — many analytics SDKs can be initialized with data collection disabled and enabled later via a JavaScript API call.
Consent state not persisting across launches. Usually a secure storage configuration issue. On Android, EncryptedSharedPreferences requires the correct keystore configuration. If the app is installed on a device running Android API below 23, the encrypted storage API falls back to a less secure mode that may behave differently. On iOS, Keychain items stored with the wrong accessibility attribute may be cleared when the device is locked or after app reinstallation. Verify storage configuration in the SDK setup documentation and confirm persistence with a test sequence of launch, consent, force-quit, relaunch.
Consent modal appearing on every launch. The stored consent record has a version mismatch with the current vendor list configuration. Either the vendor list was updated without incrementing the consent version, causing the SDK to treat every launch as a new consent event, or the consent version was incremented without intent, unnecessarily invalidating existing consent. Review your SDK dashboard configuration and ensure version increments only when the underlying privacy practices have changed.
FAQ
What is a React Native consent SDK? A library that manages the full consent lifecycle in React Native apps: displaying the consent UI, storing decisions securely, exposing consent state to application code, and enabling conditional initialization of third-party SDKs based on user choices.
Do mobile apps need a consent banner? Yes, if the app processes personal data for non-essential purposes — analytics, advertising, tracking — and is used by people in GDPR jurisdictions. The requirement applies regardless of platform or framework.
How do you block SDKs until consent is granted? By deferring all third-party SDK initialization until the onConsentReady callback fires, and wrapping each SDK initialization in a conditional check against the consent state returned by that callback. The consent SDK itself does not block native library loading; the application code must structure initialization sequencing correctly.
Can React Native apps implement TCF-compliant CMPs? Yes. TCF v2.2 compliance is supported by several React Native consent SDKs, including Secure Privacy's. TCF compliance requires the SDK to write a valid TC string to standard local storage so that TCF-compliant advertising SDKs can read and respect consent automatically.
What happens if a third-party SDK fires before consent? Under GDPR, any personal data processing that occurs before a valid legal basis exists is unlawful processing, regardless of what the user subsequently chooses. Regulators treating this as a technical violation rather than a policy one means the UI design is irrelevant — only the actual network traffic at the time of SDK initialization matters.
Putting It Together
The gap between a compliant-looking consent implementation and a technically verified one is where most mobile privacy enforcement is focused in 2026. Regulators have the tooling to inspect network traffic, decompile SDKs, and verify whether data actually stops when consent is declined. A consent banner that does not control SDK behaviour provides no compliance protection — it creates a documented record that the app acknowledged a privacy requirement and failed to honour it.
The architecture for a defensible implementation is not complex: initialize the consent SDK first, defer everything else, check consent state before each tracked SDK starts, log every decision with a server-side backup, and provide persistent consent withdrawal. What makes it operationally difficult is that it requires the consent layer to be treated as infrastructure rather than a UI feature — built into the app's initialization sequence at the same level as networking and authentication, not added after the fact as a compliance layer on top of an existing SDK stack.
Secure Privacy's React Native SDK handles consent UI, storage, TCF compliance, Google Consent Mode v2, and cross-platform synchronisation in a single integration. Book a developer demo →
