On June 4, 2026, a federal appeals court stayed the injunction against Texas SB 2420, and the first US law obliging app stores and developers to check user ages went live mid-litigation. The statute was signed May 27, 2025, took effect January 1, 2026, got blocked on December 23, 2025 when a district judge found it likely unconstitutional, and then came back on the strength of a Fifth Circuit stay the Supreme Court declined to disturb on July 6. The lawsuit continues; the obligations do not wait for it. For new accounts created in Texas, the machinery is running now.
What the law asks of the store
Chapter 121 of the Texas Business and Commerce Code splits the work. The store's half: verify each new account holder's age category (child under 13, younger teen 13 to 15, older teen 16 or 17, adult) using a "commercially reasonable method," get parent or guardian consent before a minor downloads an app, buys it, or buys anything inside it, and share each user's age category and consent state with developers on request. Two clauses carry the sharp edges: consent must be obtained "for each individual download or purchase," blanket consent is itself a violation, and the store must notify the developer when a parent revokes. Age data is also minimized by statute: the store's use is confined to verification, consent, and its own compliance records, and developers may use it for age enforcement, compliance, and safety defaults, then delete it once verification is done.
What the law asks of your app
The developer subchapter is the part the coverage skipped. Section 121.052 requires an age rating on the app and "each purchase that can be made through" it, with the reasons behind each rating. Section 121.054 requires you to build a system that consumes the store's age and consent data and verifies it per user. Section 121.055 caps what you do with that data. And Section 121.056 defines your violations: enforcing terms against a minor who never had consent, knowingly misrepresenting a rating, or sharing the age data onward. There is a good-faith safe harbor if you rely on what the store sends you. The statute sets no dollar figure itself; violations ride as deceptive trade practices, which Texas caps at $10,000 per violation in attorney-general actions, beside whatever private DTPA claims a plaintiff can frame.
The clause with the widest reach for product teams is Section 121.053: before making a "significant change," you must notify the store so it can re-ask parents. The statute defines significant as a change to the type or category of personal data you collect, anything affecting the app's rating, new monetization (purchases or ads), or a material change to functionality or user experience. Apple's documentation repeats the legal reality flatly: determining when your change is significant is the developer's responsibility. Nobody reviews the call.
The toolkit Apple and Google shipped
Apple's response is four APIs, live for apps built on the iOS 26.2 SDK with Xcode 26.2 or later:
(under 13, 13-15, 16-17, 18+) plus the
assurance method, e.g. card or gov ID
parental-consent dialog for your change;
you block the feature until consent lands
current rating on-device and diff it
RESCIND_CONSENT: parent pulled approval;
Apple then blocks launch at the platform
Two mechanics matter past the API list. First, blocking: Apple's Q&A states plainly that until the parent consents to your significant update, "the child must be prevented from accessing" it, whether that means the whole app or the feature. Second, identification: RESCIND_CONSENT carries Apple's appTransactionID, a per-account key Apple generates, rather than any identifier of yours. If the app never captured and stored it (the real-world shape of a free app with no account system), the revocation cannot be attributed to a user. Design accordingly.
Google's parallel is the Play Age Signals API, in beta, which returns a verification status, an age band, the approval date of the latest significant change, and an install ID used to flag revoked approvals. Play began returning Texas signals for accounts created after May 28, 2026, tracking the administrative stay rather than Apple's June date. Play Console also lets you declare a significant change without shipping a binary, and shows a per-app revocation report. Amazon Appstore ships a third API in the same shape, which is the tell: age signals are becoming a store primitive, not a Texas patch.
The map behind Texas
Texas is first to enforce, not first to legislate. Utah's SB 142 passed earlier but was amended in 2026 into a private-right-of-action model landing May 6, 2027, retroactive to existing accounts. Louisiana's law was re-set to July 1, 2027 with AG-only enforcement. Alabama's takes effect January 1, 2027, and is also retroactive, even covering pre-installed apps. California chose a different architecture entirely: AB 1043 has the operating system collect an age-bracket signal at account setup and share it on request, with no per-download parental consent, starting January 1, 2027. A federal App Store Accountability Act sits in both chambers of Congress. The direction is set: the question is which state's version your build absorbs first.
Our position
Build once, to the strictest rule on the map. Today that is Texas: consent per download, consent on significant change, revocation handled as a launch-block. If your app is available in Texas at all, you are in scope the moment a new Texas account touches it, and "we are not a kids app" is not an out, because the law covers every app on the store. The uncomfortable piece is Section 121.053: significant-change judgment is yours, and an incorrect call is a deceptive trade practice. Treat it like a release note a lawyer will eventually read. And budget for the boring version of this feature, because the states disagree on details: Utah and Alabama reach existing accounts, Texas does not, and California skipped parental consent entirely. One abstraction now, or four rewrites later.
The takeaway
accounts; duties on store and developer;
dtpa violations up to $10k each for ag
purchase, with the reasons behind each
use for age enforcement, compliance,
safety defaults; then delete
monetization, or core function; you make
the call before release
app-transaction id, not yours; attribute
it or accept the blind spot
california jan 2027; retroactive rules
vary; a federal bill passed house committee
Store-rule plumbing like this is the submission work we scope into every custom software build, the same discipline behind our age-rating questionnaire guide and the updates we ship on CashTaq. If Texas just put your app in scope and you are not sure where the API calls go, send us the store link.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
