Your Licensed APKs Now Have to Ask How Old the Player Is. Settle Age Signals Before You Buy Android Games.

Before you buy Android games for your app, settle age signals: state law now pushes a player's age bracket into your app, and a licensed build can't read it.

For most of the last fifteen years, "age" in a games catalogue meant a rating. You declared a content rating in the store console, the store printed it on the listing, and the obligation ended there. The rating was metadata about your app. It never changed what the app did.

That is not how it works any more in a growing list of US states. The store now knows the age band of the account holder, and it hands that answer to your app at runtime — as a signal your code has to request, receive and act on. An app that ignores it is not merely impolite. In Texas it is out of compliance. And when the code in question is a game you licensed rather than a game you wrote, nobody on your side of the wall can add the API call.

📅 The Dates, and Which Ones Have Already Landed

Texas SB 2420, the state's App Store Accountability Act, was written to take effect on 1 January 2026. A federal district court blocked it on First Amendment grounds at the end of 2025, and the Fifth Circuit stayed that injunction on 10 June 2026 — which means the law is being enforced while the appeal continues. Morrison Foerster's 2026 tracking of the case sets out that sequence and the four statutory age categories the law works in: under 13, 13 to 15, 16 to 17, and 18 or older.

The platform-side dates are more concrete than the litigation, because Apple and Google have already shipped the plumbing. Apple's developer notice for these regimes says age categories are shared with a developer's app, on request through its Declared Age Range API, for new Apple Accounts in Utah from 6 May 2026 and in Louisiana from 1 July 2026. The same notice covers a separate set of changes outside the US: from 24 February 2026 Apple blocks users in Australia, Brazil and Singapore from downloading apps rated 18+ unless they have been confirmed as adults, and apps with loot boxes distributed in Brazil are moved to an 18+ rating automatically.

California went further and put the signal in the operating system rather than the store. AB 1043, the Digital Age Assurance Act, was signed on 13 October 2025 and takes effect on 1 January 2027, with a catch-up window to 1 July 2027 for accounts and apps that existed before that date. It requires OS providers to collect age information at device account setup and expose an age-bracket signal to developers through a real-time API.

Read those together and the planning mistake becomes obvious. There is no single deadline to hit — there is a rolling set of jurisdiction-specific behaviours your app has to handle, and the handling lives in code.

🔌 Age Assurance Stopped Being a Form Field and Became an API Call

On Android, Google has published a Play Console guide to the upcoming app store bills and a Play Age Signals API, in beta, that lets an app read the user's age range and parental approval status from the Play Store. The same page tells developers to report significant changes through Play Console, and states plainly that it is the developer's responsibility to decide what counts as a significant change for their app.

On iOS, the equivalent is the Declared Age Range API, which returns an age category rather than a birthdate, along with a signal about the assurance method the device used and whether age-related regulatory requirements apply to that user at all. Apple has also added a Significant Change API under PermissionKit and a new age rating property in StoreKit.

Two platforms, two APIs, two data shapes, both requiring a native call from the app that is installed on the device. That is the sentence that matters for anyone doing APK game licensing. The call belongs to the app of record. It cannot be made by a game.

🧱 Where the Call Has to Live, and Why a Licensed Build Cannot Make It

Licensed Android supply arrives in roughly three shapes, and they are not equally exposed here.

• Ready-to-publish per-title APKs. You get a signed or signable build per game and list each one. Your developer account is the developer of record for every listing, so every listing carries the age-signal obligation — but you did not write any of them, and adding a native API call means the supplier touches code, per title, for every store rule change to come.
• Source or reskin deals. You can add the call yourself. You have also taken on the maintenance of every title you touched, which is the trade that source-code buyers routinely under-price.
• One container app holding the catalogue. A single native shell with the games inside it — web builds in a WebView, native builds behind a launcher. One listing, one developer of record, one place to implement age signals for the whole catalogue.

The third shape is dramatically cheaper to keep compliant, and this is the strongest practical argument for it that has appeared in years. Implement the signal once in the shell, gate the catalogue on the result, and every title you add afterwards inherits the behaviour. In the first shape, the obligation multiplies by the number of listings and you cannot discharge it without your supplier.

There is an honest counterweight. A container app is one listing competing for one set of store impressions, where 200 listings are 200 chances to be found. If organic store discovery is the whole plan, per-title publishing still wins the traffic argument — it just costs more to keep legal now, and you should price that in rather than discover it.

🏷️ Four Statutory Categories, and the Two Your Catalogue Metadata Actually Has

The Texas categories are under 13, 13 to 15, 16 to 17 and 18+. Ask a licensor for that mapping and you will usually get something else: a free-text "family" or "casual" tag, an IARC rating obtained for a different territory, or a spreadsheet column that says "all ages" for 900 titles because nobody ever needed it to be sharper.

A law firm alert from Wiley in 2026 summarises the developer-side duties across the three enacted state laws as: receive age category information from the app store and use it to verify the user's category; receive parental consent information and use it to decide whether a minor may access the app; under Texas, assign an age rating to the app and to each in-app product; notify the store of significant changes; and use the data only for compliance, transmit it with industry-standard encryption, and delete it after use.

The in-app product clause catches portal operators who have not thought of themselves as sellers. If your app contains coin packs, a subscription tier or tournament entries, those are in-app products with their own rating obligation, and none of them came from the licensor. Your commerce layer is yours. So is its rating.

📢 Your Licensor Controls the Trigger for a Notice Only You Can Send

Significant-change notification is a developer duty. Changes to terms, privacy practice, monetization features or functionality have to be reported to the store — Google supports doing this from Play Console without shipping a new binary, and Apple provides a Significant Update Action to surface it to the adult on the account.

Now put a licensed catalogue behind that duty. Your supplier updates a batch of builds. One of them swaps an ad SDK for a newer version, another adds a rewarded placement that was not there in March, a third starts calling a different analytics endpoint. Each of those is a change to data collection or monetization in your app, under your developer account, notifiable by you. Your supplier is not the developer of record and has no reporting obligation. If you find out by reading a release note, you were lucky.

So put it in the agreement: written notice before any build change that alters data collection, SDK inventory or monetization, with a stated lead time and a per-build changelog. Do not accept "we'll let you know." Ask what the notice looks like and who sends it.

📺 The Ad Stack Is Where This Bites First

Suppose the signal works. The store tells your app the player is twelve. What, concretely, changes in the next thirty seconds of play?

In most licensed catalogues, nothing — because the ad SDK is compiled into a build you cannot patch, initialised with your publisher ID and the SDK's own defaults. Receiving an age signal you cannot pass into the thing that serves the ad is compliance theatre. The technical requirement is boring and specific: the build must expose an initialisation parameter you can set from the host — child-directed treatment, restricted data processing, non-personalised ads, whichever flag that SDK uses — or the mediation must sit in your shell rather than inside each game.

That is a question with a yes or no answer, and it is worth asking before money moves. "Can I set non-personalised mode per session, from outside the build?" If the answer is no, a mixed-audience app built on that catalogue has a hole in it that no contract clause repairs.

🌍 Europe Arrives at the Same Place From the Other End

The web route escapes the store APIs entirely. It does not escape the age question.

Article 28(1) of the Digital Services Act requires providers of online platforms to put in place appropriate and proportionate measures for the privacy, safety and security of minors. The European Commission's 2025 guidelines on the protection of minors set out what it considers adequate: age assurance that is accurate, reliable, robust, non-intrusive and non-discriminatory, with self-declaration treated as unreliable, age estimation and verification preferred, and the EU Digital Identity Wallet expected to become a route to the latter. Micro and small enterprises are outside the scope.

Whether a licensed games portal is an "online platform" in the DSA sense is a real question rather than a rhetorical one, and it turns on whether you disseminate user-provided content. A curated catalogue of licensed titles with no profiles, no chat and no user submissions is often not one. Add public leaderboards with player-chosen names, comments or uploads and the analysis changes. Get that answered by someone qualified before you build the feature, not after.

🚫 Five Ways Buyers Walk Into This

1. Treating the licensor's rating column as the statutory category. An IARC rating from another market is evidence, not compliance.
2. Publishing 200 listings and assuming the duty sits with the store. The store has its own duties. Yours are separate and per-app.
3. Buying builds with sealed ad SDKs. You will receive a signal you cannot act on.
4. Signing with no change-notice obligation upstream. Your supplier changes the app; you are the one who owes the notice.
5. Assuming the web is out of scope because there is no app store. Different regime, different regulator, not an exemption.

📋 Eight Questions to Put to a Supplier Before You Buy Android Games

• Does each build expose a native hook the host app can use to pass in an age category and parental-consent status, or is it a sealed canvas?
• Will you deliver a per-title age category mapped to under 13 / 13–15 / 16–17 / 18+, in writing, and stand behind it?
• What in-app products, if any, ship inside the builds themselves?
• Which ad SDKs are compiled in, at which versions, and can non-personalised or child-directed mode be set at initialisation from outside the game?
• Will you give written notice, with a stated lead time, before any build change affecting data collection, SDK inventory or monetization?
• Who is the developer of record in our territories, and does anything prevent us holding that account?
• Can the same titles be taken as HTML5 builds for a web route without reopening the commercial terms?
• If a store makes a new API mandatory, who does the rebuild and who pays for it?

A supplier who answers all eight from a document already written has done this before. A supplier who needs three weeks to find out is telling you something useful too.

🎯 What You Get When You Buy Android Games and License HTML5 Games From One Direct Licensor

Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles, with HTML5 builds and Android APK builds handled in the same licence conversation rather than through two suppliers who have never spoken. Games are also published on Google Play and the Apple App Store, and HTML5 titles are developed in-house, which is why questions about build internals — SDK inventory, initialisation parameters, per-title metadata — get answered rather than forwarded. A licence scope names your platforms, territories and formats up front, and delivery covers HTML5 builds, APK builds, source where applicable, branding, and hosting options including a white-label game portal if you would rather run one container than two hundred listings. If you are sizing a catalogue against a real audience, browse the catalogue and start from the titles you would actually ship, not the total.

🧸 Licensing Branded Games for Apps, Portals and Campaigns

Forestry Games works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, so businesses can license branded games alongside generic catalogue titles for campaigns, portals, events and apps. Branded content raises the age question rather than settling it: a licence that clears the character does not, by itself, decide how your app handles a signal that the player is eleven, and brand approval processes have views on how their properties appear next to advertising. Bring both conversations at once — the IP scope and the compliance behaviour — because they land on the same build. When you know the shape of what you need, ask for a licence scope covering the specific formats and territories, or request a portal demo to see the container route working before you commit to it. You can also license Android games and license HTML5 games from the same catalogue.

✅ Run the Signal Test This Week

Pick three titles from a catalogue you already hold or are considering. Send your supplier one email with two questions: can the host app pass an age category into this build, and can I set non-personalised ads per session from outside it? Nothing else. The answers arrive in a day or they do not arrive at all, and either outcome tells you what your compliance work looks like for the next two years.

Then do the arithmetic that follows from it. If the answer is no across the catalogue and your plan was 200 store listings, the container route just became cheaper than it looked, and so did the web route. If you are re-scoping either way, that is the moment to ask a licensor for terms covering both formats at once — because the expensive version of this is discovering in January that your Android catalogue and your web catalogue came from two contracts that disagree.