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.
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.
