Two Prompts, Two Different Laws

Open a mobile game in the EU on an iPhone and you may see two permission requests back to back: Apple's App Tracking Transparency (ATT) prompt asking to "track" you, and a GDPR consent form asking about personalized ads and data processing. Players assume these are the same thing. They are not, and conflating them is how publishers end up either non-compliant or leaving money on the table.

ATT is Apple's platform policy. GDPR is European law. One is enforced by App Store review; the other by data protection authorities with the power to levy multi-million-euro fines. You can satisfy one and still violate the other.

What App Tracking Transparency Actually Governs

ATT controls access to the IDFA (Identifier for Advertisers) and, more broadly, any tracking that links a user's activity across apps and websites owned by other companies. If a player taps "Ask App Not to Track," your app cannot access the IDFA and must not track them across other companies' properties.

• It is a binary, Apple-defined prompt — you cannot restyle its wording.
• It applies on iOS regardless of where the user lives.
• It governs cross-app tracking, not all advertising.

What GDPR Consent Actually Governs

GDPR is about a lawful basis for processing personal data. Personalized advertising in the EEA generally requires freely given, specific, informed consent — captured through a CMP, expressed in the IAB TCF framework, and revocable at any time.

• It applies to users in the EEA and UK regardless of device platform — iOS and Android.
• It covers far more than a single advertising ID: analytics, audience building, and data sharing all fall under it.
• The consent must be auditable; "we assumed yes" is not a defense.

Why You Need Both, and In What Order

For an EEA player on iOS, both regimes apply simultaneously. The widely recommended sequence is to show the GDPR consent form first, then the ATT prompt. The logic: GDPR consent is the legal basis, and Apple's prompt is a platform gate layered on top. If a user refuses GDPR consent, there is little reason to even ask ATT, because you have no lawful basis to track regardless of what Apple would allow.

Concretely, a clean launch flow looks like:

• Request GDPR consent via your CMP / UMP form.
• If consent is granted, request ATT authorization.
• Initialize ad SDKs with whatever the intersection of both answers permits.

The intersection is the crucial word. Personalized ads require both GDPR consent and ATT authorization on iOS. Miss either and you serve non-personalized inventory.

The Revenue Stakes

Each refused prompt steps your eCPM down. A user who grants GDPR consent but denies ATT can still receive personalized ads from contextual and first-party signals, but loses IDFA-based targeting. A user who denies both sees only non-personalized ads. Understanding these tiers lets you forecast revenue honestly and optimize the prompts you can influence — the GDPR form's timing, copy, and pre-prompt — rather than fighting Apple's fixed dialog.

Managing It All in One Place

Juggling ATT status, TCF consent strings, and Google Consent Mode signals across iOS, Android, and your web properties by hand does not scale. FlexyConsent centralizes the consent record, emits the correct TCF and Consent Mode v2 signals to your ad and analytics stack, and reports acceptance rates per platform and per region. You see exactly where consent — and revenue — is being lost, and you keep one audit-ready trail across every surface a player touches.

Key Takeaways

• ATT is Apple platform policy about cross-app tracking; GDPR is EU law about processing personal data.
• EEA iOS users need both — show the GDPR consent form first, then ATT.
• Personalized iOS ads require the intersection: GDPR consent AND ATT authorization.
• Centralizing consent signals protects compliance and makes lost-revenue tiers visible.