App Store age verification is an engineering requirement now, not a legal footnoteApp Store age verification is an engineering requirement now, not a legal footnote

Texas SB 2420 took effect on 4 June 2026 after the Fifth Circuit stayed an injunction that had blocked it. Apple Accounts in Texas must now declare whether the holder is over 18; minors' accounts must sit in a Family Sharing group, and a parent has to consent to downloads and in-app purchases. Developers are expected to adopt the Declared Age Range API, and reporting puts civil penalties at up to $10,000 per violation.

Separately, since February Apple has blocked 18+ downloads in Australia, Brazil and Singapore for accounts that have not completed age assurance.

Together these stop being regional curiosities and start being a platform requirement with engineering consequences.

The part teams get wrong

Compliance work gets scoped as a legal review followed by a checkbox. This one is not shaped that way, because it changes what your app can assume about the person using it.

An app that could always assume an adult with a working account now has to handle a user whose account is pending parental consent, whose age range is unknown, or who was consented and then had consent revoked. Those are states, and states need designing.

The requirement to re-obtain consent after a significant change is the one that catches people. That is not a launch task. It is an ongoing obligation attached to your release process.

What belongs in the estimate

• Declared Age Range integration, and the UI states for each outcome.
• Defined behaviour for pending, denied and revoked consent - including what a half-onboarded minor sees.
• A process decision about what counts as a significant change, agreed before the first one happens.
• Testing across jurisdictions, because behaviour now differs by where the account is registered.

None of that is difficult. All of it is expensive to add afterwards, because it touches onboarding, which touches everything.

The privacy tension is real

Age assurance means learning something about the user you previously did not know. Apple's approach keeps most of it at the account layer and hands the app a range rather than a birth date, which is meaningfully better than every developer building their own verification and storing the result.

An age range you never store is safer than a birth date you protect carefully.

Our recommendation is to use the platform API and hold nothing. Do not mirror the range into your database because it might be useful later. It is a special category of personal data about children, and the safest way to handle it is not to have a copy.

Where this is going

Texas, Louisiana and Utah domestically; Australia, Brazil and Singapore internationally. The direction is consistent even where the statutes differ, and the legal position is still moving - SB 2420 was blocked in December before the stay reinstated it.

Which is the planning point. Build the requirement as a capability, not a jurisdiction-specific patch. Teams that hard-coded Texas behaviour into a conditional will write that conditional again, and the fourth one is the one that breaks.