Consent on Mobile Apps: The Banner Rules Change
Your website banner is sorted. Your app is a different product with different rules, and the consent flow that works on the web does not transfer to it. Mobile consent is not a smaller banner. It is a different system with its own prompts, its own SDKs, and its own ways to get it wrong.
The first difference is the operating system prompt. On iOS, App Tracking Transparency requires an app to ask permission before tracking the user across other companies' apps and websites. The user sees a system prompt, not your banner, and the answer is stored by the OS, not by your CMP. On Android, the data safety section in Google Play tells users what the app collects before they install it, and the consent has to match what that section promises.
The SDK is the banner
On the web, the CMP is a script in the head. In an app, it is a mobile SDK, and the consent state lives in the app, not in a cookie. The SDK has to be wired into every place data leaves the app: analytics, crash reporting, advertising, and the third-party libraries your developers added without telling anyone. A web CMP with a mobile add-on is not the same as a mobile SDK that actually gates the app's data flows, and the distinction is where most app consent fails.
The second difference is persistence. A web visitor clears cookies and the consent is gone; the site re-prompts. An app user who deletes the app deletes the consent with it, but an app user who just updates keeps the old consent state, including consent given to vendors the app no longer uses. The app has to re-check consent on launch, against the current vendor list, and re-prompt when the list changes. Most apps check once, at install, and never again.
What to test on your own app
Install it fresh and deny everything. Then watch what leaves the device: analytics events, ad requests, crash reports with identifiers. If the analytics SDK fires before the consent prompt appears, the prompt is decoration. Then update the app to a version with a changed vendor list and check whether it re-prompts. If it does not, the consent on the device describes a vendor list that no longer exists.
Web rules and app rules share the principle and none of the mechanics. Consent has to be informed, specific, and withdrawable as easily as it was given. On the web that means a banner with a real reject button. In an app it means an SDK that gates the data flows, a system prompt the user actually sees, and a settings screen where withdrawal works. Build the app flow like the app it is, not like a website squeezed into a phone.
Keep reading: The Cookie Banner's Accessible Name: What Screen Readers Actually Announce, The Cookie Banner Keyboard Trap Test, and Embedded Video and the Consent Facade: What Loads Before the Click cover the nearby cases in this series.
Frequently asked questions
What is App Tracking Transparency?
An iOS requirement that apps ask permission before tracking the user across other companies' apps and websites. The user answers a system prompt, and the answer is stored by the operating system, not by the app's CMP.
How is mobile consent different from web consent?
On the web the CMP is a script and consent lives in a cookie. In an app it is a mobile SDK, consent lives in the app, and it has to gate analytics, crash reporting, advertising, and third-party libraries.
Do I need to re-prompt when the vendor list changes in an app?
Yes. The app should re-check consent on launch against the current vendor list and re-prompt when it changes. Most apps check once at install and never again, so the consent on the device describes a list that no longer exists.
What should I test on my own app?
Install it fresh, deny everything, and watch what leaves the device. If analytics or ad requests fire before the consent prompt appears, the prompt is decoration. Then update to a version with a changed vendor list and check for a re-prompt.