Consent in Mobile Apps: Getting SDK Signals Right
Mobile apps break consent in a way websites rarely do. A web banner can block tags in the page, but an app ships with analytics, attribution, and crash SDKs bundled inside it, and many of them initialize the moment the app launches, before any consent screen appears. That first launch data is often the most valuable data the SDK collects, which is exactly why regulators look at it.
This guide covers how to sequence SDK startup around a real consent signal, what the app side receipt should contain, and how to handle the messy cases: updates that add SDKs, users who move between web and app, and choices made offline.
Initialize in two phases, not one
Split SDK startup into an essential phase and a consent phase. Crash reporting that contains no identifiers and the code needed to render the consent screen itself can start immediately. Everything that measures, attributes, profiles, or advertises waits for the signal. The practical test is simple: run a fresh install on a test device with network logging and confirm that no request leaves for a non essential endpoint before a choice is tapped. Repeat that test on every release, because a single SDK update can quietly move initialization earlier in the launch sequence.
The receipt needs an SDK list version
A consent receipt that only names categories is hard to defend for an app, because the actual processing is done by specific SDKs that change between versions. Version your SDK inventory the same way you version your privacy notice, and store that version in the receipt. When version twelve of the inventory adds a new attribution partner, the receipts collected under version eleven do not cover it, and your renewal logic can target exactly the users whose coverage lapsed instead of re-asking your entire base.
Updates are a consent event
An app update that adds an SDK, expands the data an existing SDK collects, or changes a data recipient is a material change, and it should trigger the same revisit flow a website uses for a new tracker category. Show returning users what changed in plain language, keep their previous settings as the starting point, and do not enable the new processing until they answer. Shipping the change silently and covering it in release notes is not consent, and app store review teams as well as regulators have both rejected that argument.
Sync web and app choices conservatively
When the same person uses your website and your app under one account, conflicting choices are inevitable. The safe default is that the more restrictive choice governs both surfaces until the user actively changes it in the place they are using. Record which surface each choice came from, show the current state in both privacy settings screens, and never let a looser web choice silently loosen the app, where device identifiers make the processing more intrusive. Sync failures should fail closed for new processing, not open.
Related reading
These earlier guides cover connected questions in more depth: Consent for Embedded Checkout and Payment Iframes, Consent Receipts: What Proof of Consent You Actually Need to Keep, and Auditing the Banner Itself: Dark Patterns That Void the Consent You Collected.
Frequently asked questions
Can crash reporting run before consent?
Truly anonymous crash reporting with no device identifiers and no linkage to a user account is usually treated as essential. The moment the crash tool carries an install ID, a user ID, or session replay, it stops being anonymous and belongs behind the consent signal.
What if a user never answers the consent screen?
Then non essential SDKs stay off, indefinitely. A consent screen that eventually gives up and enables tracking is a timed paywall on privacy, and the data collected under it will not hold up as consented.
Do we need a new prompt after every app update?
No, only after updates that materially change processing: a new SDK, new data types, or a new recipient. Cosmetic and performance updates do not change what consent covered, and prompting for them trains users to tap without reading.
How should offline choices be handled?
Store the choice locally with its timestamp and sync it when the device reconnects. Processing decisions should use the locally stored choice in the meantime, so an offline refusal is honored even before your servers see it.