If you ship a mobile app, four US states have now written laws that change what your code has to do before someone can download it. One of those deadlines is 1 January 2027, which is under two months away.

Texas went first. Its App Store Accountability Act took effect on 1 January 2026, was promptly enjoined by a federal district court on First Amendment grounds, and then came back into force when the Fifth Circuit stayed that injunction pending appeal. Morrison Foerster's update notes that plaintiffs intend to ask the Supreme Court to vacate the stay. Utah followed on 7 May 2026, Louisiana on 1 July, and California arrives on 1 January 2027.

The part most teams have missed is that these are not only app store obligations. The stores verify the age. Developers have to receive that signal, act on it, and prove they did.

---

What the laws actually ask of developers

• Scope is every app available to residents of those states, not only apps aimed at children.

  A B2B productivity app available on the US store is in scope. This is the assumption most teams get wrong on first reading.



• Texas requires an age rating for the app and for each in-app purchase, in four bands.

  Under 13, 13 to 15, 16 to 17, and 18 and over, along with the content that informed the rating, disclosed to each relevant store.



• Developers must use store-provided consent data before a minor downloads or buys.

  Not after signup, not at first launch of a paid feature. Before.



• The liability routes differ by state.

  Texas frames violations as a deceptive trade practice, which opens private litigation. Utah includes an explicit private right of action. Louisiana, per Wiley's analysis, rejects the safe harbour that Texas and Utah give developers who reasonably rely on store information.



• Both platforms have shipped the plumbing.

  Apple's Declared Age Range API returns an age category rather than a birthdate, alongside a Significant Change API and sandbox testing. Google Play's Age Signals API covers supervised account status, age range where available, and whether parental approval is required.

Two honest caveats. This is a summary for people who build things, not legal advice, and the differences between these statutes are the sort that counsel should read rather than a blog. And the legal position is genuinely unsettled: the Texas law is in effect because of a procedural stay, not because a court upheld it.

---

1. Establish whether you are in scope, properly

The threshold question is not whether your app is for children. It is whether residents of Texas, Utah, Louisiana or California can download it.

For most apps on the US storefront the answer is yes, which means the work applies. An app with no minor users still has to be able to receive and act on the signal that says a user is a minor. Write down your determination and the reasoning, because that record is the first thing anyone will ask for.

2. Integrate both platforms' age signal APIs

Apple's Declared Age Range API and Google Play's Age Signals API are the mechanism the statutes assume you are using. They are also, to give the platforms credit, designed reasonably: you receive a band rather than a date of birth, which means you learn what you need and store less than you would under a document-upload approach.

Request the signal at a sensible point such as launch or account creation, handle the case where no signal is available, and do not build a flow that breaks when the API returns nothing. Apple provides a sandbox that can simulate a 15-year-old or a revoked consent. Google, at the time of writing, does not offer an equivalent, so test with accounts configured for the relevant jurisdictions.

3. Rate the app and every in-app purchase

The Texas requirement is specific: a rating for the app and for each purchase, with the content that informed it, provided to each store.

If your app has twenty in-app purchases, that is twenty determinations, not one. Build the rating into your product data rather than treating it as a store listing field someone fills in once, because it has to survive your next catalogue change.

4. Gate features, not just the download

A download gate is the easy half. The statutes reach in-app purchases, and in practice your obligations extend to the features that make an app inappropriate for a younger band.

Map your app's surface against the four age bands and decide, deliberately, what each band can reach: purchases, messaging with strangers, user-generated content, external links, advertising personalisation. Then enforce it server-side as well as in the client, because a client-side check is a suggestion.

5. Build the significant-change notification path

This is the requirement teams discover late, and it has architectural consequences. When you make a significant change to your terms, your privacy policy, your data collection or your monetisation, you must notify the store so parental consent can be refreshed.

That means you need an internal definition of significant, a person who makes that call, and a release process that includes the notification step. Apple handles the consent re-request through its Significant Change API; Google expects you to flag it in Play Console. A release checklist that does not include this question will eventually ship a change that needed it.

6. Treat withdrawn consent as a live event

Parental consent is not a one-time gate. It can be withdrawn, and when it is, your app has to restrict access promptly.

Apple notifies you. For Google you monitor revocations through Play Console reports and check approval status against the API. Either way you need a path from that signal to a change in what the user can do, which is a different thing from checking a flag at install time and forgetting it.

7. Handle the signals as regulated data

The age and consent information you receive comes with strings attached. Use it only for compliance and safety purposes, transmit it with industry-standard encryption, and delete it once verification is complete.

Resist the obvious temptation to enrich your analytics with it. A field called age_band sitting in your data warehouse because it seemed useful is exactly the finding that turns a compliance question into a problem.

8. Keep the evidence, because the safe harbour depends on it

Texas and Utah offer developers a safe harbour for reasonable reliance on store-provided information. Reasonable reliance is something you demonstrate rather than assert.

Log what signal you received, when, what you did with it, and when you deleted it. Keep your scope determination, your rating methodology and your significant-change decisions. The engineering effort is modest. Reconstructing all of it eighteen months later under a letter from an attorney general is not.

---

Building for a law that might not survive

There is an obvious objection to all of this, and it deserves a straight answer. The Texas statute is in force because an appeals court paused an injunction, not because anyone has decided it is constitutional. The challengers argue it burdens protected speech, the district court found that argument likely to succeed, and the Supreme Court may yet be asked to weigh in. It is entirely possible that some of this gets struck down.

Building for it anyway is still the rational call, for three reasons. The Utah and Louisiana laws are in effect and not enjoined. California arrives in January and is a considerably larger market than any of them. And the work itself, an age signal you can act on, server-side feature gating by age band, and a release process that knows when consent needs refreshing, is the same work regardless of which specific statute survives. The direction of travel across jurisdictions is one way, and nobody serious expects it to reverse.

It is also worth separating the legal argument from the underlying one. The dispute in court is about method and about who bears the burden, not about whether minors should be able to buy anything they like without a parent knowing. Most developers, asked directly, would rather their app did not sell loot boxes to twelve-year-olds. The frustration is that the implementation cost falls on small teams who were already stretched, which is a fair complaint about the design of the laws rather than an argument that the goal is wrong.

The practical risk is not a fine. For most independent developers it is an app that gets pulled from a store because it cannot demonstrate compliance, during a month when that revenue was the payroll.

---

Three checks to run this week

• Confirm whether your app can receive an age signal at all.

  If neither API is integrated, that is your first sprint and the deadline is January.



• Count your in-app purchases and check how many have a documented age rating.

  For most teams the answer is the app has one and the purchases have none.



• Ask who in your team decides what counts as a significant change.

  If the answer is nobody, add the question to your release checklist today. It costs one line and prevents the failure mode that is hardest to fix retroactively.

An afternoon of checking, and you will know whether this is a sprint or a quarter.

Need the age signals, the gating and the audit trail built before January? Talk to Spark about getting your app compliant without rebuilding it.