Long before a player places a single tile, a free game has already made its first real impression — and it is not the menu. It is the consent screen: the box that asks what may be done with data about the person holding the phone. That screen is not optional, and pretending otherwise is how studios get rejected at review or fined by a regulator. So the interesting question was never whether to show it. It is how — because the same legal requirement can be satisfied with a fair prompt or a manipulative one, the two look almost identical from a distance, and a player can feel the difference long before they can name it. This is a first-hand account of how we build that screen across our games, and the one honest cost of building it the fair way.
You cannot skip it — so stop trying
Two separate rules land on the same small surface. For a player in the European Economic Area or the UK, data protection law requires a valid legal basis before an ad-supported app processes personal data for personalised advertising — in practice, a consent choice collected through a certified consent-management platform. Separately, on iOS, Apple requires an app to ask through the system App Tracking Transparency prompt before it accesses the device advertising identifier or otherwise tracks the user across other companies’ apps and sites. Neither is a nice-to-have. One is enforced by regulators; the other is enforced by App Review, and Apple has been unambiguous that an app which tries to route around the prompt does not ship.
Which means the entire “can we avoid this?” conversation is a dead end, and a surprising amount of dark-pattern energy is really just an expensive attempt to have that dead-end conversation anyway — to keep the legal box technically ticked while nudging every player toward the answer that pays best. We decided early that the honest move is the same one we made about monetization in free-to-play, done honestly: accept the constraint as real, and then compete on being fair inside it rather than clever around it. The design space that leaves is smaller than it looks, and far more interesting than it sounds.
Two prompts, two owners, one correct order
The first thing to get straight is that this is two systems, not one, and confusing them is where most implementations quietly break. The GDPR consent form is owned by Google’s User Messaging Platform (UMP), a certified consent-management platform that runs on both iOS and Android and shows the form to users the platform determines are in a region that requires it. The ATT prompt is owned by Apple and the app: it exists only on iOS, and on a cross-platform toolkit it fires only because our own code calls for it — never as a side effect of the consent form. Android has no tracking-authorization prompt at all; its equivalent lives in the system settings, not in a dialog we present. Treating ATT as an “iOS thing” and assuming Android is therefore exempt from consent is exactly backwards: the GDPR half applies to both platforms, and only the ATT half is Apple-only.
Because both can appear to the same person — an EEA player on an iPhone — order matters, and there is a correct one. We show the GDPR consent form first, then ATT. Apple explicitly permits that sequence, so there is no need for the fragile boot-time gymnastics of asking for tracking before the app has even settled. And the two decisions are wired together the way Apple’s own rule demands: if a player declines in the consent form, the ATT prompt is suppressed entirely and never shown, because a request to track after a decline is precisely what Guideline 5.1.1(iv) forbids. If they consent, ATT is presented and makes its own separate decision. Getting this join right means reading the actual IAB consent string the form writes — the authoritative record of what the user chose — not a softer signal that merely reports “a choice was made” and stays green even after a full reject.
Where the flow quietly turns adversarial
A dark pattern here is the same beast as in monetization: a design choice that works against the user’s own intent while staying technically within the rules. The consent screen has its own playbook of them, and each one is aimed at making the “yes” less deliberate. There is the pre-ticked box — consent switched on by default, so inattention counts as agreement. There is asymmetry: a big, bright, one-tap “Accept all” set against a “Reject” that is greyed out, shrunk, or hidden two menus deep behind “Manage options,” so the fair choice costs more effort than the profitable one. There is the faux-continue — a friendly “Continue” or “Got it” button that silently records consent the player never actually gave.
And there is the guilt trip, which finds its purest form on iOS. Apple lets an app show a pre-permission screen before the system ATT prompt, and that screen is where the pressure gets applied: “Allow tracking to keep this game free,” a wall of emotional copy, the honest option minimised to a whisper underneath. None of these make the choice clearer. Every one of them makes it less considered — and that is the tell, exactly as it is with a countdown timer or a stranded soft-currency balance. A consent flow tuned to maximise “yes” is not collecting consent. It is manufacturing it.
How we actually wire it
Our rules for the screen are boring on purpose, which is how you know they are working. Nothing is pre-ticked. The default state is no consent, and consent only exists as the result of a deliberate tap. The choices are symmetric. Accept and reject carry the same visual weight and sit the same number of taps away; declining is never the longer road. “Continue” never means yes. We do not harvest agreement from a dismissal, a scroll, or a neutral-sounding button — consent is an explicit act or it did not happen. And there is no guilt-trip pre-prompt before ATT; we do not bribe, pressure, or emotionally invoice a player for a permission, which is both the fair thing and, not coincidentally, what Apple’s rules about not incentivising the prompt require.
Two implementation details do a lot of quiet work. We key every consent-critical decision off the platform’s own location determination rather than the phone’s language setting — a traveller, an expat, or someone on a VPN can easily have a non-EEA language on an EEA connection, and using the language as a proxy for location is how you accidentally deny an EEA user the protections they are owed. And we keep a permanent “Manage consent” entry in settings that reopens the real certified form, because GDPR and Apple both require that a person can change their mind, and a choice you cannot revisit is not much of a choice. This is the same close-up discipline we apply to the rest of the ship pipeline in one codebase, two stores; consent just happens to be the surface where getting it wrong is most expensive.
What a “no” actually does
The honest test of a consent flow is not what happens when a player says yes. It is what happens when they say no — because that is where the temptation to punish, nag, or quietly break the app is strongest. Our answer is that a “no” costs the player nothing in the game itself. The app works exactly as it did a second earlier: every mode, every level, every feature, no degraded “free-but-crippled” mode as retaliation for a private choice.
What a “no” changes is narrow and specific, and we say it plainly rather than implying it away. Declining does not make the ads disappear — our games are ad-supported, and the free tier still shows ads. What changes is that those ads become non-personalised: served on context rather than on a profile built from the advertising identifier. Less relevant to the advertiser, typically worth less to us, and completely fine for the player, who was never promised an ad-free product in the first place. The one clean way to remove ads entirely remains what it has always been — a single optional Pro purchase — and it is deliberately unrelated to the tracking choice. We do not dangle “turn on tracking” as a fake substitute for paying, and we do not treat a privacy decision as leverage to sell one.
The trade-off we accept on purpose
Here is the part an honest post cannot leave out. A consent flow built this way collects fewer yeses. When you remove the pre-ticked box, balance the buttons, and refuse the guilt trip, a meaningful share of people who would have been nudged into consent simply decline — and every decline means a non-personalised impression that tends to earn less than a targeted one. A truthful flow measurably lowers the opt-in rate. That is not a bug in the implementation; it is the implementation working as intended. The manipulative version’s entire value proposition is the gap between the consent a fair screen would collect and the consent a rigged one extracts, and closing that gap on purpose is the whole point of the exercise.
We think that trade is worth making for the same reason the honest monetization trade is: it swaps a bigger short-term number for a sturdier long-term one. A player who was respected at the first screen has a different relationship with everything that comes after it, and trust is the one asset a competitor with a larger user-acquisition budget cannot outspend us for. It also happens to be the durable side of a regulatory bet — the enforcement trend across jurisdictions runs steadily toward penalising manufactured consent, not toward rewarding it. Choosing the fair flow is not a sacrifice we make and hope pays off. It is a smaller peak we take on purpose in exchange for a longer curve.
The consent screen really is the first thing a free game says about itself, and it says it before the player has any reason to trust you. You can spend that moment engineering a “yes,” or you can spend it earning the right to ask the question at all. We picked the second, wired it to be as easy to decline as to accept, and made a “no” a thing the game can absorb without flinching. If you want to check the claim rather than take our word for it, the flow is right there the first time you open anything in our catalogue — which is, as ever, rather the point of writing it down.
Notes
This is a first-hand account of how we build the consent flow across our own games, not a legal guide — treat the descriptions of GDPR and Apple’s rules as our working understanding of public requirements, not as advice, and confirm the current wording against the primary sources below before relying on it. It deliberately contains no opt-in-rate numbers. We say plainly that an honest flow lowers the opt-in rate because that is the direction the mechanism has to move; we do not publish a percentage, because we do not have a figure we would stand behind as representative, and a fabricated one would hollow out the exact argument the piece is making. The absence of the number is the honest position, not a gap in it.
Sources
The platform and legal references this post relies on, each a primary source (living documents; accessed 2026-07-18):
- Apple — App Store Review Guidelines, Guideline 5.1.1(iv) (Data Collection and Storage): if a user denies a permission request, an app must not ask again for that permission, and there must be no tracking until permission is granted.
- Apple Developer — App Tracking Transparency framework and Apple — User privacy and data use: the app-triggered ATT permission required before accessing the advertising identifier or tracking across apps and sites, and the rule against incentivising the prompt.
- Google AdMob — Obtain consent with the User Messaging Platform (UMP) and Google — EU user consent policy: the certified consent form flow, its cross-platform behaviour, and the requirement to collect consent before serving personalised ads to EEA/UK users.
- IAB Europe — Transparency & Consent Framework (TCF): the standard behind the consent string our code reads to determine what a user actually chose.
Keep reading: all posts on the WizusLabs Engineering blog.