"Significant Change" Is Now the Developer's Call. A Licensed Android Catalogue Makes One Every Month.

If you buy Android games as a catalogue and publish under your own developer account, the new app-store age laws land on you, not on the licensor who built them. The stores hand you a signal. Deciding what to do with it is a product decision nobody wrote into the licence.

The comfortable version of this story is that age became the store's problem. Google and Apple check the ID, the store asks the parent, and a licensee running an aggregated games app inherits a cleaner audience for free. That is half right. The stores did take on verification. They also shipped developer-side APIs, and both of them push a judgement call back to you that only makes sense if you know what your app is going to do next month.

For a licensed catalogue, what the app does next month is the product. You add titles. That is the reason the licence exists in the first place. Thirty new games a month, a seasonal batch before Ramadan or Christmas, a swap of underperformers for fresh stock — that cadence is the thing you are paying for, and it is now sitting inside a legal definition you are expected to interpret yourself.

📅 The Rules Are Live in More Places Than Texas

Texas SB 2420, the App Store Accountability Act, requires app marketplaces to establish a user's age category and obtain parental consent for minors under 18 before downloads, in-app purchases, and — the part that matters here — significant changes to an app. Its path through the courts has been messy. A district court preliminarily enjoined it, the Fifth Circuit granted an administrative stay on 28 May 2026 that made it enforceable, CCIA and SEAT went to the Supreme Court seeking vacatur, and the Fifth Circuit heard argument on the stay in early August 2026. Read that as: contested, and currently in force. Plan around the second half of that sentence.

The rest of the map, as it stands:

• Utah — the App Store Accountability Act's app-store and developer requirements took effect on 6 May 2026, with enforcement provisions from 31 December 2026. Utah includes a private right of action, which changes the risk profile from "the AG might notice" to "anyone might sue".
• Louisiana — HB 977, signed 15 May 2026, pushed its version back to 1 July 2027 while the Texas litigation plays out. Louisiana's statute does not give developers the reasonable-reliance safe harbour that Texas and Utah do.
• Alabama — HB 161, enacted 17 February 2026, becomes the fourth state law of this shape, effective 1 January 2027.
• Brazil — the ECA Digital (Law 15,211/2025) took effect on 17 March 2026 and applies to any service likely to be accessed by minors in Brazil, regardless of where the provider sits. It bans self-declaration as an age check and carries fines running to BRL 50 million per violation or a share of Brazilian revenue.

If your catalogue business skews toward LATAM or toward US carrier and OEM channels, you are already inside two of these, not waiting on one.

🔢 Two Different Numbers: the App's Rating and the Player's Age Band

Operators keep collapsing these. They are separate systems with separate owners.

The content rating describes your app. It comes out of the IARC questionnaire, your licensor's title metadata feeds it, and it is a property of the build. The age category describes the person holding the phone. It arrives at runtime from the store. Apple's Declared Age Range API returns one of four bands defined by the Texas statute — under 13, 13–15, 16–17, over 18 — plus a signal about the assurance method used, such as a credit card or government ID. Google's equivalent, the Play Age Signals API, returns verification status, age range and supervision data, and Google is explicit that you may use it only to deliver age-appropriate experiences in compliance with law — not for advertising, marketing, user profiling or analytics.

That restriction deserves a second read if your monetization plan involves audience segments. The age signal is a compliance input. It is not a targeting parameter, and treating it as one is a platform policy breach on top of whatever the statute says.

🔁 The Significant-Change Clause Walks Straight Into Your Release Cadence

Here is the sentence to put on the wall. Google's Play Console guidance says it is your responsibility to decide what constitutes a significant change for your app. Apple's Texas developer note says the same thing in almost the same words: it's the developer's responsibility to determine when there's a significant change to their app. Neither store will make the call for you, and neither will defend the call afterwards.

Both then give you the plumbing to act on it. Apple's Significant Change API sits in the PermissionKit framework, shows a system dialog requesting parental consent, and expects you to restrict access until consent comes back. Apple also added an ageRatingCode property to StoreKit products, so individual purchases carry their own rating. Google's side lets you notify the store of a significant change without shipping a new build, and lets you assign age ratings to in-app products through Play Console or the Publishing API.

Legal guidance on the state statutes describes the developer duty as notifying app stores of significant changes to app terms, privacy policies or monetization features, with parental consent refreshed afterwards. Texas explicitly treats a change in the app's age rating as significant.

What that means for a catalogue app, concretely

Take a licensed games app rated for a general audience with 400 titles in it. My reading of where the lines sit:

• Almost certainly significant: anything that moves the app's age rating. Adding a batch of licensed titles with casino styling, simulated gambling, or heavier violence does exactly that, and the rating change is the trigger the statute names.
• Almost certainly significant: switching monetization on. First interstitials, first rewarded video, first IAP SKU, a new subscription tier. These are monetization features, named in the statutes.
• Almost certainly significant: a terms or privacy policy rewrite — which is what happens when you add an ad network with a new data flow.
• Probably not, on its own: thirty more titles inside the rating band you already hold, no new data collection, no new purchase surface. This is the routine catalogue refresh, and if every refresh triggered a re-consent prompt you would train every parent in Texas to ignore them.

The point is not that my reading is the right one. The point is that you need a written policy, decided once, applied consistently, and reviewed by someone who reads statutes for a living — because the alternative is a product manager deciding it differently every release. Texas and Utah offer a safe harbour for reasonable reliance on store-supplied information; there is no safe harbour for having no policy at all.

🚪 A Parent Can Un-Approve Your App, and Nobody Removes It For You

This is the mechanic operators are least prepared for. Both stores let a parent revoke consent for an app they previously approved. Apple provides an App Store server notification you configure to receive withdrawal events. Google provides Play Console reporting when parents revoke approval — and states plainly that Google Play will not revoke app access or disable the app based on those approvals.

So the app stays installed, the account keeps working, and a webhook lands on your server saying this user no longer has consent. What happens next is entirely yours to build. For a single-purpose app, "restrict access" is obvious. For an aggregated catalogue it is a design question with real answers and no default:

• Do you block the whole app, or drop the user to the titles that need no consent at all?
• Does revocation kill IAP and ads while leaving free play intact, or is the ad stack the reason consent was needed in the first place?
• What happens to a subscription that is mid-cycle when consent is withdrawn — and does your billing provider have a state for that?
• Where does the player's saved progress go, and can they get it back if a parent re-approves next week?

None of that is in your licence agreement, and none of it is in the builds you were shipped. It is shell work — the same layer that already carries your account system, your storefront and your ad mediation. Budget it as product engineering, not as a compliance ticket.

🎰 The Titles Most Likely to Trip This Are the Ones You Took for Fill

Casino-styled casual games are the usual culprit — the slots and card titles that pad out a catalogue and quietly test well. Loot boxes and gacha mechanics are the other. Brazil's ECA Digital is specific here: gaming platforms must take measures to prevent minors reaching gambling, betting, lottery equivalents and loot boxes, with obligations around offering versions without those features.

A licensed catalogue is a mixed bag by construction. You did not commission these titles and you cannot patch them. That leaves two levers, and both belong in the licence rather than the backlog: the ability to filter titles out by age band at serve time, and per-title metadata honest enough to filter on. "Casual" is not a content descriptor. Simulated gambling, in-game purchases, randomised rewards and ad presence are.

🧾 What Your Licensor Has to Deliver Before You Can Comply

Raise these before the next batch lands, not after:

1. Per-title content descriptors in a machine-readable field, covering simulated gambling, randomised rewards, chat or UGC, in-app purchases and ad formats present in the build.
2. A per-title age rating you can map to the four statutory bands, and notice when a licensor-side update changes it.
3. Advance notice of build changes. If the licensor swaps an SDK or turns on a new ad format inside a title you already ship, that can move your app's rating — and you find out from a store review, not from them, unless the contract says otherwise.
4. The right to withhold or geo-filter individual titles without breaching a minimum-catalogue commitment. Some licences count titles you must display; make sure compliance removals do not put you in default.
5. IP and content indemnity that survives a rating dispute, and a named contact who can answer a content question in days, not quarters.

🚫 Five Ways Operators Get This Wrong

• Assuming the store's verification is your compliance. It is an input to yours. The developer obligations are separate and they are yours.
• Treating the age signal as an audience segment. Google's terms rule out advertising, marketing, profiling and analytics use. That is not a grey area.
• Having no significant-change policy, so each release makes the call fresh and inconsistently. Inconsistency is what an enforcement action looks like in hindsight.
• Ignoring revocation until the first webhook arrives. The event is delivered whether or not you built anything to receive it.
• Waiting for the Texas litigation to resolve. Utah's requirements are already in force, Alabama arrives on 1 January 2027, and Brazil has been live since March 2026. The work is largely the same in every one of them.

📋 A Two-Week Audit You Can Actually Run

1. Pull the age rating for every title you ship and sort by rating. Anything above your app's declared rating is either a filter rule or a removal.
2. List every monetization surface — ad formats, IAP SKUs, subscriptions — and mark which ones a minor can reach without consent today.
3. Write the significant-change policy. One page. What triggers re-consent, who signs it off, where it is logged.
4. Wire the revocation notification to something that is not a dead endpoint, and decide the degraded experience it produces.
5. Send your licensor the five-item list above and ask which they already supply. The gaps are your negotiating agenda for the renewal.

🎯 What a Licence Covers When You Buy Android Games Direct

Working with a direct licensor rather than a reseller matters most on exactly this kind of question, because compliance depends on metadata and build control that a middle layer usually cannot supply. Forestry Games has licensed games since 2017 and holds a catalogue of 1,049 titles covering both HTML5 and Android builds, so the same conversation covers the web portal and the APK app instead of splitting across two suppliers with two answers. A licence can cover HTML5 builds, APK builds, source where applicable, branding and reskins, and hosted or self-hosted delivery — and because the games are licensed rather than syndicated through a feed, title-level decisions like withholding a category or filtering by age band are contract terms rather than impossibilities. If you are sizing a catalogue against a rating band, buy Android games from a shortlist filtered by content type first, and browse the catalogue before you commit to a title count. Where you need to modify builds yourself, ask about source-code licensing up front — that is what makes a title-level fix possible at all.

🧸 Licensing Branded Games for Campaigns, Portals and Apps

Branded content sits under the same rules, with an extra approval layer. Forestry Games works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, and businesses can license branded game content through it for campaigns, portals, events and apps. If your audience skews young, expect the brand's own compliance requirements to sit alongside the statutory ones, and expect both to want answers about data collection and monetization before a build is approved. Ask for a licence scope in writing, request a white-label game portal demo if the same content needs a web surface, and put the age-band question in the first email rather than the fifth.

🧭 Decide the Policy Before the Next Batch Lands

The stores have been unusually direct about where this sits. Two companies with large legal departments both looked at "what counts as a significant change" and handed the question to you. That is not an oversight; it is a signal that the answer is app-specific and that no platform wants to own it on your behalf. A licensed catalogue is the hardest case, because its whole value is a supply of content that keeps arriving from somewhere else.

So write the policy this month, while the batch you are worried about is still a purchase order rather than a live release. Then take the five deliverables above to your licensor and find out, in writing, which of them you can actually get. If the answer is vague, that is the finding — and it is a much cheaper one to make now than in the middle of an enforcement letter.