Mobile apps don't have cookies. There's no document.cookie, no HTTP cookie jar, no browser storage that a consent banner needs to gate. And yet mobile apps collect some of the most sensitive personal data on the internet: device advertising identifiers (Apple's IDFA, Google's GAID), precise GPS location, contact lists, health data, and behavioral telemetry from every SDK bundled into the binary.

The legal obligations are identical to the web. Under the GDPR, processing personal data requires a lawful basis regardless of whether that data came from a browser cookie or a mobile device identifier. Under the ePrivacy Directive, storing or accessing information on a user's terminal equipment requires consent, and a smartphone is terminal equipment. The mechanism is different, but the law doesn't care about mechanisms. It cares about outcomes.

This guide covers the full landscape of mobile consent management in 2026: how it differs from web consent, what Apple and Google have built into the OS layer, what the IAB's mobile spec requires, and how to build consent that's legally sound without driving users to uninstall.

How Mobile Consent Differs from Web Consent

On the web, cookie consent controls what JavaScript runs and what data gets stored in the browser. A CMP intercepts script loading, presents a banner, and gates tag execution on the user's choice.

Mobile apps flip this model. Instead of third-party scripts injected at runtime, you have SDKs compiled into the app binary. Instead of cookies, you have device identifiers (IDFA on iOS, GAID on Android), instance IDs, and hardware fingerprints. Instead of a tag manager deciding what runs, you have SDK initialization code that executes when the app launches.

The engineering consequences:

You can't block an SDK after it's compiled in. On the web, a CMP prevents a script tag from loading entirely. In a mobile app, the Firebase SDK or Meta SDK is already in your binary. You control it by gating initialization or calling configuration methods that suppress data collection until consent is granted.
Device IDs are OS-level, not app-level. IDFA and GAID are managed by the operating system. Apple and Google have built their own consent mechanisms (ATT and Privacy Sandbox) that operate below your app's consent layer. Your CMP has to work with these OS-level gates, not instead of them.
There's no DOM to inject a banner into. Mobile consent UIs are either native views (UIKit/SwiftUI on iOS, Jetpack Compose on Android) or WebViews that load a web-based consent interface inside the app.

Apple's App Tracking Transparency (ATT)

ATT requires apps to show a system-level permission prompt before accessing the IDFA. Users who tap "Ask App Not to Track" get a zeroed-out IDFA, and the app is prohibited from tracking them through alternative means.

Here's what mobile developers frequently get wrong: ATT is not GDPR consent, and GDPR consent is not ATT. They're separate obligations that happen to overlap.

ATT is governed by Apple's App Store Review Guidelines, not European law. It applies globally and covers only "tracking" as Apple defines it: linking data from your app with data from other companies' apps or websites for advertising purposes. It doesn't cover first-party analytics, crash reporting, or processing that stays within your ecosystem.

GDPR consent under Article 6(1)(a) covers any personal data processing where consent is your lawful basis, including first-party analytics SDKs, crash reporters that capture user state, and any identifier processing that constitutes personal data.

For an iOS app serving EU users, the correct flow is:

Show your own GDPR consent interface with granular purpose-level choices.
If the user consents to advertising/tracking, then trigger the ATT prompt.
If the user granted GDPR consent but denied ATT, you have legal permission but no IDFA. You can still do contextual advertising and first-party analytics.
If the user granted ATT but you didn't collect GDPR consent first, you have the IDFA but no legal basis to use it for EU users.

The order matters. Showing ATT before your consent UI creates a confusing double-prompt. Showing it after lets you explain context first and only trigger the system dialog for users who've already opted in.

Google's Privacy Sandbox for Android

Google's approach differs from Apple's. Rather than a binary opt-in/opt-out gate, Google is building alternative APIs that preserve advertising functionality while limiting cross-app tracking. For the web-side story, see our guide on Google's Privacy Sandbox and Topics API. Here we'll focus on the Android-specific components.

The Topics API assigns a device to interest categories derived from app usage. Advertisers get coarse signals ("Sports," "Travel") without seeing which apps the user installed. The Attribution Reporting API handles conversion measurement without exposing user-level cross-app data, supporting event-level and aggregate reports with noise for privacy. SDK Runtime runs third-party SDKs in a sandboxed process, limiting their access to app data and device identifiers.

Even with Privacy Sandbox, consent obligations remain. The Topics API processes personal data (it observes app usage), so GDPR consent is still required for EU users. Privacy Sandbox narrows the blast radius of tracking but doesn't eliminate the legal requirement to ask.

Google's GAID remains available, though users can reset or opt out. Unlike Apple, Google hasn't added a hard permission gate equivalent to ATT, but the trajectory is toward reducing GAID's role. Apps that still rely on GAID for cross-app tracking should treat it as a consent-gated identifier under GDPR.

GDPR Consent Requirements for Mobile SDKs

Every SDK in your app that processes personal data needs a lawful basis.

Analytics SDKs (Firebase Analytics, Amplitude, Mixpanel) collect device information, session data, and events. EU DPAs have generally taken a strict view on legitimate interest for analytics, especially when the SDK sends data to a US-based processor. Consent is the safest basis. Gate the SDK's initialization or use its consent APIs to suppress collection until opt-in.

Advertising SDKs (Google AdMob, Meta Audience Network, AppLovin) that serve personalized ads require consent under GDPR. On iOS, they also require ATT. On Android, they should respect the GAID opt-out and will increasingly need Privacy Sandbox APIs.

Crash reporters (Crashlytics, Sentry, Bugsnag) collect device state and stack traces. Whether this constitutes personal data depends on implementation: a report with a user ID attached is personal data; anonymized device metadata might not be. The conservative approach is to require consent, or strip all identifiers so it can run under legitimate interest.

The IAB TCF Mobile SDK Specification

The IAB's Transparency and Consent Framework includes a mobile in-app specification that standardizes how consent strings are stored and shared across SDKs.

On the web, the TCF consent string lives in a cookie accessible via the __tcfapi JavaScript API. On mobile, there's no cookie jar. Instead, the spec mandates storing the consent string in platform key-value storage:

iOS: NSUserDefaults under the key IABTCF_TCString
Android: SharedPreferences under the same key

Any TCF-compliant SDK reads from these locations. Your CMP writes the consent string there, and advertising SDKs, analytics SDKs, and mediation layers read the user's choices without proprietary integration. The spec also requires storing IABTCF_CmpSdkID, IABTCF_gdprApplies, IABTCF_PurposeConsents, and other metadata keys alongside the string.

For deeper TCF implementation details, see our TCF for Publishers guide and the TCF 2.2 technical walkthrough.

Push Notification Consent vs. Tracking Consent

Mobile developers often conflate push notification permission with data processing consent. They're legally and technically distinct.

On both iOS and Android, the OS manages push notification permission through a system prompt. This is a platform permission, not a GDPR consent mechanism. Granting push permission doesn't authorize you to process personal data for marketing.

Even after a user grants push permission, sending marketing notifications requires either consent under GDPR Article 6(1)(a) or legitimate interest under Article 6(1)(f) for transactional notifications only. The ePrivacy Directive's Article 13 adds another layer: unsolicited marketing communications require prior consent regardless of channel. A push promoting a sale is direct marketing.

Your consent flow should handle these as separate decisions: collect GDPR consent for data processing through your CMP, request OS push permission at a contextually relevant moment, and only send marketing push to users who've granted both. A user who allowed push but denied marketing consent should receive only transactional notifications.

How Mobile CMPs Work: WebView vs. Native UI

There are two architectural approaches to consent UIs in mobile apps.

WebView-based consent banners

A WebView loads your web-based consent UI inside the app. The CMP renders its standard banner in a web container, captures choices via JavaScript, and communicates them to the native layer via a JavaScript bridge or by writing to NSUserDefaults/SharedPreferences.

Advantages: one consent UI across web and app, updates without app store releases, TCF string generation handled by the existing web CMP, simpler to implement. Disadvantages: WebViews can feel foreign in a native app, WKWebView on iOS doesn't share storage with Safari, and some ad SDKs expect consent via native APIs.

Native consent UIs

A fully native consent screen built with SwiftUI/UIKit or Jetpack Compose. The CMP provides a native SDK that renders consent using platform controls.

Advantages: native feel, faster rendering, direct integration with platform consent storage. Disadvantages: two UIs to maintain, updates require app store review, more complex integration.

Firebase Analytics and Consent Mode on Mobile

Google's Consent Mode has a mobile equivalent that works with Firebase Analytics and Google's mobile advertising SDKs.

The Firebase SDK exposes a setConsent() method accepting consent state for analytics_storage, ad_storage, ad_user_data, and ad_personalization. Before the user chooses, set all to denied. After consent, update the relevant keys to granted. In denied mode, Firebase sends cookieless pings that Google uses for behavioral modeling in GA4.

The implementation pattern: set default consent to denied at app launch, show your consent UI, call setConsent() with updated values on user choice, and persist the choice locally to restore on next launch without re-prompting. For the web-side equivalent, see our Consent Mode Advanced vs Basic guide.

Best Practices for Mobile Consent UX

Timing

Don't show a full-screen consent dialog before the user has seen a single screen of your app. They've just downloaded it, have zero context, and you're asking for data processing decisions. Consent rates drop when the prompt precedes the value proposition. Delay until a relevant moment, show a brief onboarding screen first, or start with essential-only processing and collect consent as the user engages.

Transparency

"We use cookies and similar technologies" doesn't work on mobile because there are no cookies. Be specific: "This app uses Firebase Analytics to understand how you use the app, and Google AdMob to show relevant ads." Naming SDKs and purposes meets the GDPR's informed consent requirement.

Granularity

Don't bundle everything into a single accept/reject. Mobile users are often willing to allow analytics but unwilling to allow advertising tracking. Separate toggles per purpose increase overall consent rates while respecting preferences.

Equal prominence

Per every DPA guidance document and dark pattern regulation: the reject button must be the same size, same visual weight, same number of taps away as accept.

Persistence

Store consent state locally and restore it on each launch. Don't re-prompt every session. Provide a settings screen for reviewing and changing choices at any time. The GDPR requires withdrawal to be as easy as granting consent.

CookieBeam's Approach to Mobile Consent

CookieBeam's architecture is API-first, which makes mobile integration straightforward without requiring a separate native SDK per platform.

WebView integration

Load your CookieBeam consent banner in a WKWebView (iOS) or WebView (Android). The banner renders identically to your website. CookieBeam's JavaScript SDK communicates consent choices to the native layer via the JavaScript bridge, and your native code writes consent state to NSUserDefaults/SharedPreferences for TCF-compatible SDK consumption.

API-first consent

For fully native UIs, CookieBeam exposes consent management through its API. Your app can fetch the consent configuration (purposes, vendors, legal text), render it using native components, submit consent records back to the API for audit trail, and sync consent state across web and mobile so returning users aren't re-prompted.

This is the same API-first pattern described in our connected TV and IoT consent guide: the consent decision and consent interface are decoupled, so any platform that makes an HTTP call can participate.

Consent Mode forwarding

CookieBeam's Consent Mode v2 integration extends to mobile. When a user makes a consent choice, CookieBeam returns the equivalent Consent Mode signals (analytics_storage, ad_storage, ad_user_data, ad_personalization) that your native code passes to Firebase's setConsent(). One consent choice, consistently applied across your CMP audit trail and Google's analytics pipeline.

Common Mistakes

Initializing SDKs before consent. If the Meta SDK or Firebase starts collecting data at launch, you've already processed personal data without consent. Set conservative defaults and gate initialization behind the consent result.
Treating ATT as GDPR consent. ATT doesn't generate a consent record, doesn't cover all GDPR purposes, and doesn't apply to Android. You need your own consent layer.
No withdrawal mechanism. If your consent UI appears once during onboarding and there's no settings screen to change preferences later, you're violating Article 7(3).
Forgetting about app updates. When you add a new SDK, existing users need re-prompting. Consent given for "analytics" doesn't cover a new advertising SDK added in version 3.2.
Web and app consent silos. A user who consented on your website shouldn't face the same wall in your app. Use an API-backed consent store keyed to their account.

Mobile consent isn't a niche concern. If your app processes personal data from EU users, consent management is as fundamental as authentication. Build it into your architecture from day one.

For related reading, see our guides on GDPR compliance checklists, Consent Mode v2 failures, and consent for single-page apps.