Teams moving from web to apps often look for the banner. There is no banner. What an app has instead is a stack of third party SDKs, each initializing at launch, each with its own data appetite, and a platform prompt whose wording and timing the operating system controls. Consent in apps is therefore less a design problem than a supply chain problem.
The regulatory logic is the same as the web: collection needs a lawful basis, and the publisher owns what its code does. The practical difference is that on the web you can watch network requests in a browser. In an app, the collection is compiled in. Unless someone inspects the traffic or the SDK documentation, the publisher's first honest look at its own behavior often comes from a regulator or a platform rejection.
The platform prompt is not consent, but it gates tracking
Apple's App Tracking Transparency prompt is a platform permission for cross app and cross site tracking tied to the device identifier. It is not a GDPR consent and does not replace one, but declining it has hard technical consequences: the advertising identifier is zeroed and tracking as the platform defines it must stop. Publishers who treat the prompt as their whole consent strategy discover it covers neither their analytics under privacy law nor data uses beyond the platform's tracking definition.
Sequencing matters. The prompt should arrive at a moment of context, not stacked on first launch with the push notification request and the cookie equivalent, because prompt fatigue trains reflexive declines. And nothing that the prompt governs may happen before it is answered, which constrains SDK initialization order in ways product teams rarely plan for.
SDK inventory is the app consent audit
The audit that matters lists every SDK in the build, its vendor, the data it collects, when it initializes, and what it sends before any user choice. Crash reporting, analytics, attribution, advertising, push, and A/B testing SDKs each have defaults, and several defaults involve device identifiers transmitted on first session.
Vendors' data sheets understate; traffic inspection does not. Running the app behind a proxy on a fresh device, before touching any consent surface, shows exactly what leaves the phone and when. That capture, compared against the privacy policy and the platform's data disclosures, is the document that predicts both regulatory findings and app review problems.
Gate initialization, not just features
On the web, consent tools block tags. In apps, the equivalent is conditional initialization: non essential SDKs do not start until the consent state allows them, and essential ones start in a restricted mode. Most major SDKs support delayed or consent aware startup; few apps use it, because the default integration initializes everything in the app delegate or equivalent and the data flows from the first second.
This is the app's version of the banner that fires trackers before the click, and it draws the same criticism. Regulators and platforms both ask what the code did before the choice. An initialization diagram, showing which SDKs start when and under what consent state, is the artifact that answers them, and building it usually reveals two or three SDKs nobody remembers adding.
Stores, policies, and prompts must tell one story
The app now makes its data claims in at least four places: the platform privacy labels or data safety section, the privacy policy, the consent surfaces in the app, and the SDK list in its documentation. Inconsistency among them is the most common app privacy failure, because each is written by a different team at a different time.
Reconcile them the way you would reconcile code: one inventory as the source of truth, each disclosure generated or checked against it, and a review whenever an SDK is added or updated. Store declarations made from memory decay on the same schedule as the app itself, which is to say every release.
Related reading
These earlier guides go deeper on connected questions: Consent in Newsletter Signup Forms: The Checkbox Is the Least of It Newsletter forms collect consent quietly and often badly: pre-ticked boxes, bundled permissions, and no record of what was agreed. What a defensible signup flow records., One Consent, Many Subdomains: Syncing Consent State Without Leaking It Everywhere Shops, blogs, support portals, and checkout subdomains each need the same consent answer. Cookie scope, server side state, and the failure modes of naive syncing., and Consent in Single Page Applications: Why Route Changes Break Your Banner Logic Single page apps load tools as visitors move between views without page reloads, which quietly defeats consent code written for classic sites. How to fix the sequence..
Frequently asked questions
Is Apple's tracking prompt the same as GDPR consent?
No. It is a platform permission for cross app tracking tied to the device identifier. Privacy law consent is a separate obligation, and neither replaces the other.
What is the biggest app consent risk?
SDKs that collect and transmit data on first launch, before any choice. An SDK inventory plus a first launch traffic capture finds them; a policy review does not.
How should non essential SDKs be handled?
Delay their initialization until consent allows, or start them in a restricted mode the vendor supports. Default integration that starts everything at launch is the common violation.
Why do app privacy disclosures disagree with each other?
Because the store labels, policy, and in app surfaces are written by different teams from memory. One SDK inventory as the source of truth, checked each release, keeps them consistent.