Consent in Mobile Apps: The SDK Problem Nobody Sees From the Banner Dashboard
A website banner holds the line because nothing loads before it. An app is the opposite shape. The binary ships with its analytics, advertising, crash reporting, and attribution SDKs inside it, and they wake up when the app launches, which is before the first screen, let alone the privacy screen, has had its say.
Teams arriving from web consent bring a banner mindset to a structural problem and end up with a beautiful preferences page governing SDKs that already sent their first payload at the splash screen. The fix is architectural, and it has to be specified before the build, not audited in afterwards.
The launch sequence is the consent sequence
On both major mobile platforms, an SDK initialised in the app's startup path can collect device identifiers, IP addresses, and usage signals immediately. Delaying that initialisation until after a consent decision is a deliberate engineering choice: the SDKs sit behind a consent gate in code, the app's own first party functions that need no consent still run, and the gate opens per purpose as the user chooses. If your SDK documentation describes an automatic start, someone has to write the manual start, and that work belongs in the estimate, not in a later surprise.
Operating system permissions sit alongside this, not instead of it. The platform tracking prompt governs cross app tracking identifiers on that OS. It does not cover analytics inside your own app, crash data, or processing under other legal bases, and an app that treats the OS prompt as its entire consent programme has a well designed quarter of one.
Records in a world without cookies
Web consent leans on cookies and local storage. Apps have accounts, device identifiers that reset, and users who reinstall. The consent record needs an identity strategy: tied to the account when there is one, so a choice follows the person across devices, and handled honestly when there is not, which means a reinstall may lawfully be asked again rather than silently treated as a continuing yes.
Versioning matters more in apps because updates stagger. Your user base runs six app versions at once, each with a different consent screen wording and a different SDK list, and the record has to say which version collected it. When a store listing's data safety or privacy nutrition declarations are filled in, they should be generated from the same SDK and purpose inventory the consent flow uses. Two documents describing the same app differently is an audit finding with a download link.
The update nobody consents to twice
Shipping a new SDK in an app update is the mobile equivalent of adding a tracker to a website, except quieter: no new banner appears, the version notes say bug fixes, and the data flows change underneath a consent given for a different inventory. Material changes to the SDK list or purposes should trigger a fresh in app ask, surfaced as a real choice with the new purposes named, not as a line in a changelog nobody opens.
Keep an SDK register the way websites keep a cookie inventory: every SDK, its owner, its purposes, the consent purpose it waits behind, and the version it arrived in. When the privacy team, the store declarations, and the consent gate all read from that one register, the app finally has what the web team takes for granted: a banner that tells the truth.
Related reading
These earlier guides cover connected questions in more depth: Consent Mode Defaults by Region: Setting Denied First, and Proving It, Consent Errors You Never See: Logging Failures in the Consent Layer, and Banner Flicker Is a Consent Bug: Fixing Load Order and Page Shift.
Frequently asked questions
Why is app consent harder than web consent?
Because collection starts with the app itself. SDKs bundled in the binary can initialise at launch, before a consent interface runs, so holding them back has to be engineered into the app's startup sequence rather than handled by a banner script that loads first.
Does the operating system's tracking prompt replace in app consent?
No. The OS prompt covers a specific cross app tracking permission on that platform. It does not address the app's own analytics, crash reporting, or other processing, which need their own consent or legal basis handling inside the app.
What should an app consent record contain?
The user or account identifier it attaches to, the timestamp, the purposes and their states, the wording version and app version that collected it, and the SDK inventory in force at the time. Staggered app versions make the version fields essential.
Do we need to re ask consent when we add an SDK?
If the new SDK changes purposes or adds a materially new kind of processing, yes: the original consent did not cover it. A fresh, specific ask for the change is the defensible route, driven by an SDK register that flags the change.