A native mobile app needs the same opt-in consent as a website before it tracks anyone in the EU, even if it never sets a browser cookie. The ePrivacy rule covers any storage on, or reading from, the user's device, so an analytics or advertising SDK that starts at launch, or reads the IDFA or GAID, needs consent first. What changes is the mechanics: you gate SDK code instead of blocking script tags.
Mobile apps do not use cookies the way websites do
Websites rely on HTTP cookies to remember visitors, track behaviour and serve targeted advertising. Mobile apps work differently. Native iOS and Android applications have direct access to device storage, advertising identifiers and embedded software development kits (SDKs) that collect data without setting a single browser cookie.
This distinction matters because many app developers assume that the ePrivacy Directive only applies to cookies. It does not. Article 5(3) of the ePrivacy Directive covers any storage of information, or access to information already stored, on a user's terminal equipment. A smartphone qualifies as terminal equipment, and an SDK reading a device's advertising identifier counts as accessing stored information.
The legal obligations are broadly the same. The technical implementation is entirely different.
SDKs are the mobile equivalent of third-party scripts
On a website, third-party tracking typically arrives through JavaScript tags: the Meta Pixel, the Google Analytics snippet or ad network scripts. Each sets cookies in the visitor's browser. In a mobile app, the equivalent mechanism is an SDK embedded directly into the app's compiled code.
An analytics SDK such as Firebase or Adjust initialises when the app launches and starts collecting data immediately unless the developer has configured it to wait for consent. Unlike a website script that can be conditionally loaded by changing its type attribute, an SDK is compiled into the app binary. Holding it back requires the developer to add gate logic in code, checking consent status before any SDK method fires.
This is where many apps fall short. The CNIL, France's data protection authority, published its final recommendations on mobile apps on 24 September 2024 and announced that from early spring 2025 it would run a specific investigation campaign on mobile applications. The recommendations say an app must obtain consent to process data that is not necessary for its operation, such as targeted advertising, and that refusing must be as easy as accepting.
IDFA, GAID and advertising identifiers
Two identifiers dominate mobile advertising. Apple assigns each iOS device an Identifier for Advertisers (IDFA), while Google assigns each Android device a Google Advertising ID (GAID). Both serve a similar purpose to third-party cookies on the web: they enable cross-app tracking and attribution.
The two platforms handle consent for these identifiers very differently.
Apple's App Tracking Transparency (ATT)
On iOS 14.5 and later, an app must request tracking authorisation through ATT before it can get the IDFA. Apple's documentation for the advertising identifier says it returns all zeros if the app has not asked or the user declines, which disables cross-app tracking through the IDFA.
ATT is a platform requirement, not a legal one. It does not replace GDPR consent obligations. An app used in the EU needs both an ATT authorisation and a separate GDPR consent request covering all non-essential processing, not only IDFA access.
Google's approach on Android
Google has taken a less restrictive path. Android users can reset or delete their GAID in device settings, but there is no system-level consent prompt equivalent to ATT. Google has kept the advertising ID: on 17 October 2025 it announced that it is retiring the Privacy Sandbox replacements, including the Topics and Attribution Reporting APIs on both Chrome and Android and the SDK Runtime. As of October 2026, the GAID stays available without a mandatory opt-in gate.
This does not mean Android apps can skip consent. Under the GDPR and the ePrivacy Directive, reading the GAID still counts as accessing information stored on a user's device. The legal requirement exists whether or not the platform enforces it technically.
How in-app tracking differs from website tracking
The table sums up the main differences between tracking on websites and in native mobile apps.
| Aspect | Website | Mobile app |
|---|---|---|
| Primary tracking mechanism | HTTP cookies (_ga, _fbp) | SDKs, IDFA and GAID |
| Third-party code delivery | JavaScript tags loaded at runtime | SDKs compiled into the app binary |
| Blocking before consent | Change the script's type attribute or use GTM triggers | Gate SDK initialisation in code |
| Cross-site or cross-app tracking | Third-party cookies (blocked by Safari and Firefox) | Advertising identifiers (IDFA and GAID) |
| Platform consent layer | None (a CMP is needed) | ATT on iOS, none on Android |
| Storage covered by ePrivacy | Cookies, localStorage and sessionStorage | Device storage, keychain, shared preferences |
| Consent request format | Cookie banner | In-app consent dialog or onboarding screen |
ePrivacy and the GDPR both apply to mobile apps
Article 5(3) of the ePrivacy Directive does not mention the word "cookie" at all. It refers to "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user." A smartphone running your app is terminal equipment. Any SDK that reads the GAID, writes data to shared preferences or accesses the device's keychain falls within scope.
The GDPR then applies on top whenever personal data is processed. Advertising identifiers count as personal data: Recital 30 of the GDPR names "cookie identifiers" and "other identifiers such as radio frequency identification tags" among the online identifiers that can be used to build profiles.
In practice, your mobile app needs opt-in consent before it starts any non-essential tracking, just as a website does. The only exemption is for storage or access that is strictly necessary to provide the service the user explicitly asked for.
Where the consent gate sits in an app's launch
Regulators test what an app sends, not what its policy says
Regulators do not stop at your privacy policy. A common method is to run the app through a proxy and watch which network requests fire before and after consent, the same before-and-after comparison they use on websites.
The CNIL imposed 83 sanctions totalling €486.8 million in 2025, according to its 2025 enforcement review, and 21 entities were sanctioned over trackers. Most of the money came from two website cases, Google (€325 million) and Shein (€150 million), so the total says more about cookies on the web than about apps. For mobile apps, the same review reports orders to several apps and online games used by many minors to strengthen age verification.
The CNIL is not alone in watching apps. The dark patterns that regulators target on cookie banners, such as hidden reject options and pre-ticked consent, are equally a problem in app onboarding flows.
Practical steps for mobile app consent
Gate SDK initialisation
Do not call FirebaseApp.configure(), Adjust.initSdk() or any analytics SDK method until the user has granted consent. This means moving SDK initialisation out of your AppDelegate or Application.onCreate() and into a consent callback.
Separate ATT from GDPR consent
On iOS, the ATT prompt covers IDFA access only. Your GDPR consent request must cover every processing activity, including analytics, crash reporting with personal data and behavioural profiling. Show your GDPR consent screen before the ATT prompt so users understand the wider context.
Keep consent records
Store a timestamped record of each consent decision, including which version of your consent text was shown. Article 7(1) of the GDPR requires you to be able to demonstrate that consent was given, and an investigation will ask for that evidence, the same standard that applies to cookie banners on websites.
Audit your SDKs regularly
Third-party SDKs update often, and a new version may collect more data. Run a periodic audit of every SDK in your app, documenting what data each collects and whether it fires before or after consent. Apple's App Privacy Report (Settings > Privacy & Security > App Privacy Report) shows which domains your app contacts.
Consent should follow the user across web and app
If your product has both a website and a mobile app, users expect their consent choices to carry across. A visitor who rejects marketing cookies on your website should not find themselves tracked by the same ad network through your app.
Syncing consent across devices needs an authenticated consent model. When a user signs in, their consent preferences load from your server and apply to the current session, whether that session runs in a browser or a native app.
Questions about consent in mobile apps
Do mobile apps need cookie consent if they do not use cookies?
Yes. The ePrivacy Directive covers all storage on and access to a user's device, not only cookies. SDKs that read advertising identifiers or write to device storage need the same opt-in consent as cookies on a website.
Is Apple's ATT prompt enough for the GDPR?
No. ATT only covers access to the IDFA for cross-app tracking. The GDPR requires consent for all non-essential processing of personal data, including analytics, crash reporting and behavioural profiling that ATT does not address.
Do Android apps need a consent prompt even though Google does not require one?
Yes. Under the GDPR and the ePrivacy Directive, reading the GAID or storing non-essential data on a user's device requires opt-in consent whatever the platform requires. Google's lack of a system-level prompt does not remove the legal obligation.
How do I block an SDK from firing before consent?
Move SDK initialisation out of your app's launch sequence and into a consent callback. Only call the SDK's start or initialise methods after the user has granted permission through your consent screen.
Can I use legitimate interest instead of consent for mobile app analytics?
Not for the access to the device. Where analytics stores or reads data on the device, the ePrivacy Directive requires consent whatever GDPR legal basis applies to later processing. Legitimate interest may cover server-side processing, but the initial access to the device triggers the consent requirement.
What fines have been issued for mobile app tracking?
The CNIL sanctioned 21 entities over trackers in 2025, but its largest fines that year, Google (€325 million) and Shein (€150 million), concerned websites and Gmail, not apps. The CNIL announced a specific investigation campaign on mobile apps from spring 2025.
Keep your website's consent in step with your app
Kukie.io does not run inside native iOS or Android apps: on the app side, the SDK gate above is code you write. On your website, Kukie.io scans the cookies your pages set, holds tracking scripts until visitors accept, and keeps a record of every choice, so the web half of a cross-platform consent model has the same categories and evidence as your app.
