App Tracking Transparency & GDPR Consent in WebView Apps

Your website already has a cookie banner. It has had one for years, it is properly configured, and it satisfies your legal team. Then you wrap that website in an app, submit it, and Apple rejects you for tracking without permission. The cookie banner inside your WebView does not satisfy Apple's App Tracking Transparency requirement, because ATT is a native system prompt and a web page cannot display one.

These are two separate consent systems with two separate legal bases. Most WebView apps need both, and satisfying one does nothing for the other.

Does a WebView App Need ATT and Cookie Consent?

If your website loads any third-party advertising or analytics that tracks users across other companies' apps and sites, then your iOS app needs the native ATT prompt, and your site still needs its own consent mechanism for EU and UK users. Neither one replaces the other.

The trap is that a wrapped site looks like it is already handling consent, because the familiar banner appears on launch. It is handling one of the two requirements. The other one is invisible until App Review points at it. If you are new to how the wrapper works at all, start with what a WebView app actually is.

What Is App Tracking Transparency, and Does It Apply to a WebView App?

App Tracking Transparency is Apple's requirement that an app ask permission through a system prompt before tracking a user across apps and websites owned by other companies — and it applies to tracking your web content performs, not just tracking your native code performs. That last part is what catches wrapped sites.

Apple's framing is about the app as a whole. If your site loads a third-party ad network, a social pixel, or an analytics product that builds a cross-company profile, that behaviour is happening inside your app, and the app is what Apple reviews. "The tracking is in the website, not the app" is not a distinction Apple's rules recognise.

Mechanically the native side is small:

• The AppTrackingTransparency framework presents the prompt, via a tracking authorization request made from native code.
• An NSUserTrackingUsageDescription string in Info.plist explains why you are asking. Without it the prompt will not display at all.
• The IDFA is only available if the user allows it. Denied means your ad and analytics tools fall back to non-personalised behaviour.

This is native work, which is worth knowing if you are having an app built for you: it is a question to ask your builder directly rather than assume. Our guide to adding AdMob ads to a WebView app covers the same prompt from the monetisation side, and iOS permission best practices covers how to ask without getting denied by reflex.

Does My Website's Cookie Banner Cover the App?

Your cookie banner works normally inside a WebView and still does its job for GDPR and ePrivacy purposes — but it cannot produce Apple's ATT prompt, because only native code can. A web page has no ability to render a system dialog.

This is the single most common misunderstanding in this whole area, and it is an easy one to have. The banner is visible, it stores a choice, and everything looks handled. But the two mechanisms are answering different questions:

• Your banner asks: may this website store and use non-essential cookies and similar identifiers?
• The ATT prompt asks: may this app track you across other companies' apps and websites?

A user can reasonably answer yes to one and no to the other, and your implementation has to respect both answers independently. Treating an accepted cookie banner as blanket permission to track is exactly the behaviour both systems exist to prevent.

ATT vs GDPR Consent: Two Requirements, One App

ATT is a platform policy enforced by App Review; GDPR and ePrivacy consent is a legal obligation enforced by regulators. They overlap in subject matter and not at all in mechanism. You can fail either one while perfectly satisfying the other.

That third row deserves emphasis. A consent banner that sets a cookie but does not actually prevent scripts from loading is decorative. The test is not whether the dialog appears; it is whether declining it changes what the app does.

Why Does the Cookie Banner Reappear Every Time the App Opens?

Because consent choices are stored in cookies or local storage, and if the WebView is not configured to persist that storage, the record of the choice is thrown away when the app closes. The banner is working correctly; the storage underneath it is not.

This is genuinely bad for you in two directions. Users find a banner on every single launch intensely annoying, and a consent record that does not survive a restart is not much of a record. The fix is the same storage configuration that keeps users logged in:

• The consent cookie needs an explicit expiry, not a session cookie that dies with the app process.
• Android WebView needs DOM storage enabled and its cookies flushed before the process is killed.
• iOS needs the default (persistent) website data store, not the non-persistent one.

All three are covered in detail in our guide to session and cookie persistence in WebView apps. If your banner reappears every launch, fix storage first — nothing else in this article will behave predictably until you do.

What Are the Rules on Android?

Android has no App Tracking Transparency equivalent, but it has its own advertising ID rules and a mandatory Data Safety disclosure — and EU and UK consent law applies exactly the same on Android as on iOS. Fewer prompts, not fewer obligations.

Three things matter on the Android side:

• The advertising ID permission. Apps targeting newer Android versions that use the advertising ID must declare the AD_ID permission. Omit it and the identifier comes back as zeros, which usually surfaces as ad revenue quietly collapsing rather than as an error.
• The Data Safety form. Google Play requires you to declare what your app collects and shares — and that includes data collected by your website inside the WebView. Our Data Safety form walkthrough covers how to fill it in without over-claiming.
• Consent still applies. GDPR does not care which app store the app came from. Your banner needs to work, and actually gate scripts, on both platforms.

What Order Should the Prompts Appear In?

Show the ATT prompt before any tracking begins, and do not stack it on top of your cookie banner in the same moment — two consent dialogs fired at once on first launch is the fastest way to get both of them declined. Sequence matters for consent rates as much as for compliance.

A workable order for a wrapped site:

1. Let the app open and render something useful first. A prompt before the user has seen anything gets dismissed reflexively.
2. Show the ATT prompt from native code, ideally after a brief moment of context — a short native screen explaining what personalisation buys the user tends to outperform a cold prompt.
3. Let the website's consent banner appear once the user is on the page, as it normally would.
4. Gate the trackers on both answers. Tracking should only run where ATT was allowed and consent was given.

Because ATT can only be asked once, that single prompt matters. If the user denies it, the only route back is the iOS Settings app, so it is worth spending the effort on the timing and the explanation.

What Changed in 2025–2026

The direction of travel is that platforms increasingly want machine-readable declarations of what you collect, rather than trusting a prose privacy policy. Three developments matter for wrapped sites as of September 2026.

• Privacy manifests on iOS. Apple requires apps and many third-party SDKs to ship a privacy manifest declaring collected data types and the reasons for using certain APIs. A wrapper app is not exempt because its content is web-based.
• Consent signals are expected by ad platforms, not just regulators. Google requires consent signals from advertisers serving users in the EEA, which means an EU-facing site running Google ad products needs its consent mechanism wired into those signals rather than merely displayed.
• Enforcement of ATT has tightened. Apple has become notably stricter about apps that use advertising identifiers without showing the prompt, which is consistent with the broader pattern in common Apple rejection reasons.

None of this changes the underlying principle. It does mean that vague or absent declarations are increasingly caught automatically rather than by a human reviewer noticing.

Step-by-Step: Getting Consent Right in a WebView App

Start by finding out what your site actually loads, because everything else depends on that answer. Six steps, and the first is the one most teams skip.

Common Mistakes

How Do You Test Consent Properly?

Test the paths where the user says no, because those are the ones that get an app rejected or a company fined — and they are the ones nobody tries. The happy path almost always works.

1. Deny the ATT prompt and confirm the app still functions and requests no advertising identifier.
2. Decline the cookie banner and watch the network traffic. If tracking requests still fire, the banner is not wired to anything.
3. Force-quit and relaunch. Both the ATT answer and the consent choice should survive; a banner on every launch means a storage problem.
4. Reset ATT in iOS Settings and confirm the prompt appears again on a clean install, since it can only be shown once per install.
5. Check both platforms. Android has no ATT prompt but the same consent obligations, and it is easy to wire one platform and forget the other.

Watching real network traffic is the only reliable check here. A consent tool's own dashboard reports what it believes it is doing, which is not always what the page actually does — the same reason we recommend real-device testing for camera, file upload and geolocation permissions.

Frequently Asked Questions

Key Takeaways

• A cookie banner cannot satisfy ATT — only a native system prompt can, and a web page cannot display one.
• ATT covers tracking your website does, not just your native code. The app is what Apple reviews.
• These are two separate systems with different enforcers; satisfying one does nothing for the other.
• A banner that does not gate scripts is decorative. Declining has to change what the app actually does.
• Consent that resets every launch is a storage bug, and it is the same fix as keeping users logged in.
• Android has no ATT but the same consent obligations, plus the AD_ID permission and a Data Safety declaration.
• Test the denial paths — those are the ones that get apps rejected.

Consent handling sits alongside the other details that separate a production-ready app from a thin wrapper, like dark mode and the native touches covered in our previous guide. The difference is that getting this one wrong has consequences beyond a user deleting your app.