Texas SB 2420 status tracker — in effect June 4, 2026 (temporary stay pending appeal)

[zigapovhe]

On December 23, 2025, a federal court issued a preliminary injunction blocking Texas SB 2420, finding it likely violates the First Amendment.

Impact on APIs

Google Play Age Signals API:

• Will not return live responses for Texas users
• Age ratings for in-app products can still be provided but won't show in purchase approval flow

Apple DeclaredAgeRange API:

• Implementation for Texas has been paused

Utah & Louisiana Unaffected

The injunction only affects Texas. Laws in Utah (May 2026) and Louisiana (July 2026) are still on track, and both Google and Apple will continue supporting developers for compliance in those states.

Recommendation: Keep the plugin integrated

⚠️ This is a temporary injunction, not a final ruling. Texas can appeal, and the law could become enforceable at any time if:

• The Fifth Circuit reverses the decision
• A final ruling favors Texas
• The injunction is lifted for other reasons

I recommend keeping this plugin in your app to avoid scrambling if enforcement resumes unexpectedly. The plugin gracefully handles cases where APIs don't return data, so there's no downside to having it ready.

What to do

• Continue using useMockData: true for testing on Android
• Keep your implementation in place - don't remove it
• Prepare for Utah/Louisiana deadlines

References

• Google Play Developer FAQ
• Court Decision Coverage (Texas Tribune)

I'll update the README and monitor the situation.

[ecolab-neil]

@zigapovhe any ides of the future for this? louisiana and utah need this too i guess

[zigapovhe]

@ecolab-neil Correct. The main idea behind the Google Play Age Signals API and Apple Age Range API is to provide a universal, platform-level solution for age-verification laws, not just Texas. Google and Apple handle differences based on the user’s location and return an age range to the app.

If this plugin is properly integrated in your app, you should automatically benefit from future support when other countries or US states (e.g. Louisiana, Utah) introduce similar age-verification requirements, without needing state-specific implementations.

[ecolab-neil]

@zigapovhe Can we please have any updates/thoughts on this inlight of
https://www.texasattorneygeneral.gov/news/releases/attorney-general-ken-paxton-secures-major-victory-protecting-children-online-requiring-age
and Google's email June 2nd to the effect of "now you need to do this.. " and "required" and "in the coming weeks"

[zigapovhe]

@ecolab-neil Hey, thanks! Yeah, things have changed since I wrote that back in Feb. Texas SB 2420 is actually in effect now as of June 4 — the Fifth Circuit put a stay on the December injunction so the law's back on while the appeal
plays out (Texas Tribune), and Apple's already switched on age verification for Texas. The Google email you got is the
same story from their side, so the APIs should start returning live data for Texas users again.

Just be aware it's a temporary stay, not a final decision. The lower court still thinks the law is probably unconstitutional, so it could flip back depending on the appeal. Doesn't really change what you do
though.

Good news is you don't need to change anything in your integration. The whole point of the plugin is that it doesn't hardcode any state/region stuff — Google and Apple decide per user location whether to hand
back real data, so as Texas comes online you'll just start getting live responses automatically. When someone's not in a covered region you still get unknown like before. Just make sure you're handling all the
statuses and you're good.

Also worth mentioning this isn't only US states anymore — Apple now counts Australia and Brazil as covered regions too, and the plugin handles those exactly the same way.

I've updated the README to reflect all this. Let me know if anything's acting up on your end.

[ecolab-neil]

@zigapovhe thanks so much for your prompt response! :) When you say apple has "Switched it on" already for texas

1. How do i confirm that - how do I "fully test" from a manual qa perspective for minimum compliance?
2. Their sandbox testing is pretty confusing https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox. it makes it seem like for example that we need to have a serverside component to listen, which seems like a pain, but Apple also makes it seem like for a minimum no aduilt content happy path for revokation that the app store handles itself and this plugin would not "need" to do anything because it would not "show up" on the home screen at all?
3. If Texas is "in the comign weeks" and such is testing for Brazil "live" reasonable and easy to give higher real-world confidence than mockData:true?

Thanks

[zigapovhe]

@ecolab-neil Quick heads up first: 0.6.0 is published now, and it fixes the iOS hang that was getting in the way of testing this, so the Texas sandbox flow actually returns data reliably now. On your questions:

1. Best way to confirm and QA right now is sandbox. On a real device (26.2+): Settings > Developer > Sandbox Apple Account > Manage > Age Assurance, pick one of the Texas scenarios, then call checkAgeSignals. I went through the Texas ones end to end, e.g. "Texas, under 13, approved" comes back as supervised with range 0-12. For minimum compliance you mostly need two things: read the user's declared age range, and gate your content on it. The plugin gives you the first part.
2. You read it right. The server-side App Store Server Notifications piece is only needed if you want to catch consent revocation or significant changes while your app isn't in the foreground. For a minimal "no adult content" happy path you don't need it. The revocation enforcement (app getting pulled off the minor's device) is handled by the App Store itself, so the plugin doesn't need to do anything there. The plugin's job is the foreground "what's this user's range" check.
3. Brazil's a fair shout, the Digital ECA is already enforceable there (since mid-March), so a real Brazilian account on a device gives you live, non-sandbox signals, about as real-world as it gets. That said, the sandbox scenarios are solid enough now that I'd start there since it's a lot less hassle than standing up a Brazil account. And remember mockData is Android-only, so on iOS sandbox is your realistic-testing path regardless.

[ecolab-neil]

@zigapovhe any updates on if Google's rollout is "done" or done enough. since their email a week ago says "in the coming weeks", ie can we "really" test this live now?

[ecolab-neil]

@zigapovhe re: server-side. i've been under the impression we need it to be compliant if we have server-side apis, db etc, does that seem right?

[vlaadbrain]

@zigapovhe re: server-side. i've been under the impression we need it to be compliant if we have server-side apis, db etc, does that seem right?

@ecolab-neil take a look at the android and apple links.

you have to choose. i dont think server side apis are necessarily a reason.

[zigapovhe]

@ecolab-neil Sorry for the slow reply. Both questions below, plus a clarification to what I wrote back in June.

Can you test Google live now? Yes. Play's docs say the API started returning signals for Texas users "who created their accounts after May 28, 2026". That catches people out, an older account gets nothing back and that's expected rather than a bug, so make a fresh test account. Google also announced the global rollout yesterday: Australia and Canada by mid-August, worldwide by year end. Still beta, so mock data for automated tests, real accounts for manual QA.

Does having a backend mean you need the server-side piece? Not from Apple's side. Their wording is that developers "can configure to receive" the revocation notification, never that you must. @vlaadbrain is right that having APIs and a database isn't itself the reason.

The clarification: in June I said the server piece is only needed if you want to catch revocation while your app isn't in the foreground, which implied re-checking on foreground is a substitute. It isn't. DeclaredAgeRange returns an age range and has no denied state, so the plugin can't tell you anything about consent, only about age. What actually enforces revocation on iOS is the App Store blocking the app from launching on that device. So if you do want the revocation signal itself, the notification is the only way to get it, and this plugin has no part in it either way.

Whether your compliance setup needs that signal is a lawyer question rather than a plugin one, and worth asking if you store anything about minors server-side.

One heads up: 0.8.0 is out and it breaks a few things from the 0.6.x you're on. Android needs requestAgeSignalsAccess() before checkAgeSignals(), status now comes from the age band measured against your ageGates rather than the assurance tier (pass ageGates on Android now, it assumes 18 otherwise), and useMockData: true throws outside debuggable builds. Rest is in the changelog.

[vlaadbrain]

@zigapovhe regarding revocation on Google Play Console and CSV's being available for 90 days. does Google reflect the revocation via the API's immediately? (so an app restart, with a checkAgeSignals can suffice?) or is the previous response cached for a certain amount of time?

Android example: if have a two gates [16, 18]
A mock: 'supervisedPending' => AgeSignalsMockData(status: .supervisedApprovalPending, ageLower: 13, ageUpper: 15, installId: 'test_pending'),
and a signal result: AgeSignalsResult(status: AgeSignalsStatus.supervisedApprovalPending, ageLower: 13, ageUpper: 15, source: null, installId: test_pending, activeParentalControls: null, ageRangeSource: AgeRangeSource.tierB, significantChangeStatus: SignificantChangeStatus.pending, significantChangeApprovalDate: null)

when this changes to supervised or verified, does a refresh show immediately in ApprovalDate?, when the significantChange is revoked, is the ApprovalDate removed immediately? so i need to integrate with Google Play Console CSV's?

developer docs seems to indicate that revocation is entirely out of band

Update: is this the right Mock construction?

'supervisedApproved' => AgeSignalsMockData(status: .supervised, significantChangeStatus: .approved, significantChangeApprovalDate: DateTime.now(), ageLower: 13, ageUpper: 15, installId: 'test_approved'),

maybe there should be a AgeSignalsStatus.supervisedApprovalGranted ?