Texas SB 2420 has been enforceable since 4 June 2026, after a court lifted the injunction that had paused it since December. If you ship an app that Texans can download, three duties now sit with you and not with the store: assign an age designation to the app and to each purchase, build a system that reads the age category and parental consent status the store passes you, and notify the store before you make a change that affects data collection, ratings, monetisation or core functionality. Apple has shipped four APIs for this and says you must call them where the law applies. Google has shipped its own and says using them is optional. Neither position changes what the statute asks of you.
Who the law actually binds
Read the bill text and the split is clear. App stores verify age and collect parental consent. Developers assign each application and each purchase to one of four categories, child (under 13), younger teenager (13-16), older teenager (16-18) and adult (18+), and supply the stores with those ratings plus "the specific content or other elements that led to each rating". Developers must then "create and implement a system to use information received" from the stores to verify a user's age category and whether consent was obtained. A violation is a deceptive trade practice under Texas law, with remedies stacked on top of anything else already available.
Apple's own age assurance Q&A restates the division without softening it. Apple confirms age and blocks app launch when a parent revokes consent. The developer is responsible for enforcing age restrictions, deciding what counts as a significant update, handling consent responses, and compliance with local law. Even an app rated 18+ has to implement the API.
What each store gives you
The table below is a straight reading of each vendor's current developer documentation, opened on 28 July 2026, next to the statutory duty. Where a cell says the store does something, it is the store's own description of its behaviour, not an assurance that it discharges your obligation.
| Apple | Google Play | |
|---|---|---|
| Age signal | Declared Age Range API, available worldwide, returns the age band, the assurance method, parental control status, AgeRangeService.isEligibleForAgeFeatures and AgeRangeService.requiredRegulatoryFeatures | Play Age Signals API, in beta, returns age ranges, verification status and supervision status |
| Is calling it optional? | No, where legally required: "you must check the age of the people using your app" | Yes. Google states developers decide whether to use the API; the legal obligation is unchanged either way |
| Who is covered so far | New Apple Accounts in Texas, from 4 June 2026 | New users in Texas who created accounts after 28 May 2026 |
| Significant changes | AgeRangeService.showSignificantUpdateAcknowledgement(in:updateDescription:) under PermissionKit, plus a StoreKit age rating property to detect rating changes | Notify Google Play through the Age Signals page in Play Console, and add age ratings to purchase SKUs using the Play Billing Library |
| Consent withdrawal | App Store Server Notification of type RESCIND_CONSENT; Apple prevents the app from launching | Parental approval revocation reports in Play Console |
| Build requirements | iOS 26.2 or later, iPadOS 26.2 or later, Xcode 26.2 (17C52) or later | Enable API access in Play Console and complete Data safety disclosures |
| Use restrictions | Not stated in the opened Q&A | No advertising, marketing, user profiling or analytics. Violations can end in loss of API access, app suspension or removal |
One detail from Apple's Q&A is easy to miss and useful in practice: the assurance method comes back as a named value, including selfDeclared, guardianDeclared, governmentIDChecked, paymentChecked and guardian equivalents. A self-declared 18+ and a government-ID-checked 18+ are not the same evidence, and if you gate anything genuinely sensitive you can treat them differently.
What counts as a significant change
The statute gives four triggers, and this is the part most teams will get wrong because it fires on releases that feel routine. Notify the store, and expect consent to be re-sought, when a change to your terms or privacy policy affects:
- what data you collect,
- the rating designation of the app,
- monetisation features, which includes adding a subscription tier or switching a feature behind a purchase,
- core functionality.
Apple's November 2025 guidance adds a mechanical consequence: keep the age rating selections in App Store Connect current, because a rating change is itself a significant change. Write the list above into your release checklist next to the version bump, because the person who decides whether a release trips it is you, on both platforms.
The order to implement
- Rate the products, not just the app. Both the statute and Google's guidance point at in-app purchases specifically. On Android that means age ratings on purchase SKUs through the Play Billing Library. Do this first; it is metadata work that does not need a release.
- Write down the content basis for each rating. The statute requires the elements that led to the rating, not only the rating. A short internal note per category is enough, and it is what you will hand over if anyone asks.
- Read the signal at launch and cache the answer for the session. On iOS that is the Declared Age Range API, which also tells you whether the user is in a region where the requirement applies. On Android, the Play Age Signals API after enabling access in Play Console and completing the Data safety section.
- Decide what your app does with each band. This is product work, not compliance work: what a 13-15 user sees, what an unverified user sees, what happens when the signal is unavailable. Default to the more restrictive path when nothing comes back.
- Wire the withdrawal path. Subscribe to the
RESCIND_CONSENTnotification on Apple and check revocation reports in Play Console. Apple blocks app launch itself, so your job is server-side: stop billing, stop sending notifications, keep the data you are required to keep and nothing else. - Add the significant-change check to your release process with the four triggers above.
What is coming, and what is not settled
Apple and Google have both named Utah and Louisiana as next, and Apple lists Brazil alongside them; Google's Play Age Signals documentation dates Brazil's Digital ECA requirements to 17 March 2026. Neither company's opened documentation gives firm developer deadlines for Utah or Louisiana, so treat the Texas build as the template rather than a one-off. The pattern is familiar from state pricing statutes: a handful of states write similar-but-not-identical rules, and the compliant build is the one that reads a signal and branches, rather than the one that hardcodes a jurisdiction.
Two open edges are worth flagging. Google's API is in beta and its coverage begins with accounts created after 28 May 2026, so an app cannot assume a signal exists for every Texas user, and the fallback behaviour is your decision. And enforcement runs through the Texas Deceptive Trade Practices Act rather than a bespoke penalty schedule, which means the exposure is not a fixed number per violation.
The practical read: this is a week of work that mostly is not code. Ratings, a written basis for each one, a release checklist, and a branch on an age band. The APIs are the easy part, and they are the only part either store is doing for you. If you also ship on Android, it stacks with the verification deadline already on the calendar, and both are the kind of platform requirement where the appeal route is thin and the fix-and-resubmit loop is expensive. Do the metadata now and the code once.
Discussion
Sign in with Google or just a name. No email link, no password to remember.