Texas Age Law Is Live: 7 Honest Checks for Founders

A law that everyone thought was dead came back to life on June 4.

If your app reaches anyone in Texas, that affects you. Even if you've never set foot in the state.

Here's the short version. For the first time in U.S. history, creating a smartphone app store account in a state now requires proof of who you are. Texas's App Store Accountability Act, Senate Bill 2420, went into force on June 4, 2026, after the Fifth Circuit Court of Appeals lifted the federal injunction that had blocked it for five months.

So the rules you maybe skimmed last winter and then forgot about? They're real again. As of last week.

Our take: don't panic, but don't ignore it either

A lot of founders are going to do one of two wrong things right now.

Some will panic and assume they need to rebuild everything.

Others will assume "this is Apple's problem, not mine" and do nothing.

Both are wrong.

The truth sits in the middle. Apple built most of the plumbing for you. But the law puts real obligations on the developer too, and the penalty for getting it wrong is not small. App developers who fail to implement Apple's required compliance stack face civil penalties of up to $10,000 per violation.

Per violation. Not per company. That math gets ugly fast if you ignore it.

So the right move is calm and specific. Figure out if this touches you, and if it does, handle the handful of things that actually matter.

What actually changed on June 4

Let's keep this in plain language.

If a new user in Texas creates an Apple Account, Apple now checks their age before they can download anything. Anyone who wants to create an Apple Account in Texas must verify that they are 18 or older. Those under 18 will need to join a Family Sharing group, and parents will be able to revoke access to previously approved App Store apps.

One bit of good news that takes the edge off the panic: this isn't retroactive. Does Texas App Store age verification affect existing Apple Accounts? No. SB 2420's requirements apply only to new Apple Accounts created in Texas on or after June 4, 2026.

So your current users in Texas aren't suddenly locked out. It's new accounts going forward.

The part that lands on you, the founder, is the developer-side wiring. For developers distributing apps in Texas, the compliance obligation is now active: implement the four-API stack, Declared Age Range API, Significant Change API under PermissionKit, StoreKit ageRatingCode, and App Store server notification, and validate using Apple's sandbox environment.

Don't worry about the names. Here's what those four pieces do, in human terms:

·       One tells your app which age bucket a user falls in.

·       One asks a parent to re-approve when you ship a big change.

·       One is the age rating you give your own app.

·       One pings your servers when a parent pulls their kid's access so your app can react.

That's it. Four signals. Your app reads them and behaves accordingly.

Why this is sneakier than it looks

The trap isn't the API work. A good engineer can wire that up.

The trap is the word "minor."

The moment Apple tells your app that a user is under 18, you officially know something you didn't before. And knowing changes your legal exposure. By requiring app stores to provide developers with information that their apps are being used by minors, the Act creates "actual knowledge" of minor usage. For apps intended for a general audience, this could trigger obligations under COPPA if personal information is collected from children under 13, or under teen privacy laws in other states.

Read that twice if you're collecting any user data.

A general-audience app that suddenly learns it has under-13 users can walk straight into children's-privacy rules it never planned for. That's not an Apple problem. That's your problem, and it's a much bigger one than wiring up an API.

This is exactly the kind of thing that "looks done but isn't ready." The app works. The demo is clean. Then a regulator or a parent's lawyer asks what you do with a 12-year-old's data, and there's no answer.

When our take is wrong

Honesty time. This won't apply to everyone equally.

If your app is strictly B2B, sold to companies, with no consumer signups and no one under 18 ever touching it, the practical risk here is low. You should still document why, but you're not the target.

If you're pre-launch and haven't shipped anything, you don't need to scramble. You need to build this in from day one, which is cheaper than retrofitting it later.

And if your whole user base is outside the U.S. with zero Texas exposure, this specific law isn't your fire today. But know that it's spreading. Apple built the Declared Age Range API as a global, platform-level system precisely because the mandate is spreading: Utah and Louisiana have comparable laws taking effect in 2026, California's AB 1043 imposes device-level age collection starting in 2027, and more than a quarter of U.S. states have introduced related legislation.

So even if you dodge it now, you're building toward it. Designing your signup flow to handle age categories cleanly today saves you a painful rebuild in 18 months.

The artifact: 7 honest checks to run this week

Copy these into a doc. Walk through them with whoever builds your app. If you don't have a builder, these are the exact questions to ask any agency or developer you're talking to.

1.     Does any Texas user reach our app? If yes, you're in scope. If you genuinely can't tell, that's its own red flag worth fixing.

2.     Do we read the Declared Age Range API? Your app should be able to ask Apple which age bucket a user is in. If your team can't tell you yes or no in one sentence, they haven't looked yet.

3.     What do we do when we learn a user is under 13? This is the COPPA trapdoor. If the answer is "nothing, we just store their data like everyone else's," stop and get advice before you ship.

4.     Can we handle a parent revoking access? Parents in Texas are able to revoke consent for any app they previously approved for their child, a system that developers also need to support. Your app needs to notice and respond when that happens, not crash or silently break.

5.     Is our age rating accurate and current? The store has to show it, and it has to be truthful. A lazy or wrong rating is a violation waiting to happen.

6.     Have we tested this in Apple's sandbox? Apple gives you a safe environment to validate the whole flow before real users hit it. Skipping this is how "it worked in the demo" becomes a $10,000 letter.

7.     Who owns this if a complaint lands? Pick a name. A real person who knows the flow, not "the team." Vague ownership is how these things rot.

If you got a clean "yes, handled" on all seven, you're in good shape. If three or more made you wince, you've got work to do, and it's the kind that's much cheaper to do now than after a penalty notice.

Before this becomes a fire drill

If you're not sure whether your app is exposed, send us what you've built and we'll tell you, in plain English, what's compliant and what isn't. No jargon, no scare tactics, just a straight read on where you stand.

The Texas law is live right now, and the next wave (Utah, Louisiana, more) is already on the calendar. The cheapest time to handle age-verification flows is before a complaint forces you to. We've shipped 100-plus apps and seen how messy "we'll deal with it later" gets. You can book a 20-minute scoping call and walk away knowing exactly what, if anything, you need to do.

If you're earlier and just want a sanity check on whether your build holds up under real users and real rules, our digital product audit is built for exactly that. And if you're building a consumer app from scratch, this is the kind of thing we bake into the iOS build from day one, not bolt on after.

P.S. The $10,000 figure is per violation, not per company. For an app with real download numbers in Texas, "we'll get to it" is the single most expensive sentence you can say this summer. One scoping call tells you whether you're exposed. That's worth 20 minutes.