Age checks are moving into the app store and British developers should plan for it

The age check is moving down the stack

For most of the past decade, an age check was something each app did for itself, usually as a date-of-birth box on the first screen, and that model is starting to break up. In the United States, several states have written laws that put the duty on the app store, and in Britain the regulator has started asking the same question about where in the technology stack the check should sit. If you build apps that children might download, the practical consequence is that your product will soon receive an age category from the platform, together with a parental consent status, and will be expected to do something sensible with both.

My view is that British developers should plan to consume that signal now, rather than waiting to see which jurisdiction moves first. Designing an app to read an age category, set its defaults from it and respect a parent's revocation is a modest piece of engineering, whereas retrofitting it under a statutory deadline, across every market at once, would be expensive and rushed. And the more a developer can rely on a well-built platform signal, the less it has to spend running document checks of its own, though as I will argue below it should not expect to drop its own checks entirely.

Utah has set the clearest date. From 6 May 2027, an app store provider must request age category information when someone in the state creates an account, verify it using commercially available methods, and, for existing accounts, do the same within 12 months after that date. Where the user is a minor, the account must be affiliated with a parent account and the app store must obtain verifiable parental consent before allowing downloads and in-app purchases.

Critics argue the American laws may not survive and Britain regulates services

This is the objection in its strongest form. Challengers say laws of this breadth are plainly unconstitutional because children have substantial free speech rights, and the Texas statute was initially blocked by a federal district court. When the Supreme Court let it take effect on 6 July 2026, it did so in an unsigned, unexplained order, and NPR noted that the ruling does not necessarily mean the law is constitutional, only that it can be enforced while the litigation continues. On the British side, the Online Safety Act places its duties on services rather than on app stores. Ofcom's own October 2026 work, as reported by Advanced Television, describes app stores as "currently not regulated under the Act", and its July report states that the compliance obligations rest on user-to-user services themselves. Planning a product around an app store model that Britain has not legislated for, on the strength of American laws that may yet fall, looks speculative.

I take the legal uncertainty seriously, and I have no confident view on how the Texas case will end. The Fifth Circuit's order was a stay pending appeal, not a final ruling, and one of the three judges concurred only in the sentence granting it. A developer that rebuilt its whole compliance model around Texas would be taking a real bet.

But look at what the courts have actually said so far. In its published order of 4 June 2026, the Fifth Circuit found Texas had made a strong showing that it is likely to succeed, reasoning that "App store transactions are commercial in nature" and that the Act likely faces intermediate rather than strict scrutiny. It also described the burden on app stores and developers as "minimal" because SB2420 requires only commercially reasonable verification methods. NPR reports that Utah, Louisiana and Alabama have passed similar laws. Utah's obligations are set in a statute amended in the 2026 general session with a fixed start date. Even if one state's law falls, the direction across several states is plain enough to plan for.

And Britain is no longer merely watching. Ofcom has published research showing that three quarters of children who use the internet said apps downloaded from an app store were their primary means of going online, and that all the app stores it analysed rely on children self-declaring their age. It said app stores could do more by making greater use of highly effective age assurance, and set out technical, policy and compliance considerations for the government should it consider bringing app stores into scope. A developer that can already read a platform age signal loses nothing if Britain stays put, and gains a cheaper path if it does not.

What the American statutes ask of developers

It is easy to read these laws as a burden on the platforms alone, but Utah's developer section puts plenty on the app maker too. From 6 May 2027 a developer must verify, through the app store's data sharing methods, the age category of account holders in the state and, for a minor account, whether verifiable parental consent has been obtained. It must notify app stores of significant changes to the app, and request age category data or consent when implementing such a change.

Several provisions shape product design directly. When initially setting safety-related features or defaults, a developer must use the lowest age category indicated by either the app store's data or age data it has collected itself. It may request age category data no more than once in each 12-month period to check accuracy, though it can also ask when there is reasonable suspicion of misuse. It may not share age category data with anyone, and may use it only to enforce age restrictions, comply with law, or set safety features and defaults. It can also ask an app store to stop minor accounts downloading or buying its app altogether.

Texas follows a similar logic, and the Fifth Circuit's order summarises SB2420 as requiring "age verification; parental consent; and age rating and content display", and notes that developers must give app stores notice before making significant changes to their terms of service or privacy policy. A developer is not liable for an incorrect age rating if it uses widely adopted industry standards and applies them consistently and in good faith. Pricing changes count too, since a change is significant if it "adds new monetization features".

For a British developer selling into those states, then, the job is part plumbing and part process. Plumbing means calling the platform's age and consent interfaces at the right moments and setting defaults from the result. Process means keeping a record of significant changes, notifying the store and handling renewed consent without breaking the user experience for families.

Why the signal is cheaper than doing it all yourself

Britain's own numbers show that checks at app level are workable but repetitive. Ofcom's July 2026 report found over 69 million age checks were completed across 32 services between July and December 2025, a 23-fold increase on the 3 million those services completed in the previous half-year. It also thought it likely that many services retained the result of a user's first check rather than asking again on every visit.

Per check, the cost is low. Ofcom's 2026 analysis put the median average per-check cost for the analysed providers at around £0.06, within the £0.05 to £0.30 range it estimated in its April 2025 statement. Yet the regulator also found that providers generally could not quantify the engineering, support and compliance costs wrapped around those checks, because they sit inside wider operations. For a small studio those surrounding costs are the real bill, and they are duplicated in every app a child uses. A signal from the platform, checked once and passed on, is the obvious way to stop paying for the same answer many times over.

Ofcom points at the same idea. In the July report it says the protection of children "requires a system-wide effort" and that there are questions about the role of other actors, "including search engines, operating systems, and app store providers", in strengthening protections and reducing friction on users. Its later work, as reported in October, suggested that a layered or whole-of-system approach may be most effective, avoiding any single point of failure.

Treat the store's signal as one input among several

Here I part company with the more enthusiastic advocates of app store checks. Ofcom has been clear that a store-level check would not absolve service providers of doing their own. The BBC reported on 29 October 2026 that the regulator said device-level checks via app stores would not remove the need for social networks to carry out checks as well. Utah's statute reflects a similar instinct by telling developers to use the lowest age indicated by either source, which assumes the developer may know something the store does not.

There are good reasons for that caution. Children borrow phones, share family accounts and use apps through the web where no store sits in between. A platform signal is also only as good as the method behind it, and Ofcom's finding that today's analysed app stores rely on self-declaration should give anyone pause. So the design I would recommend treats the store's age category as a strong default input, combines it with what the app already knows, and keeps a route to a stronger check when signals conflict or risk is high.

Europe is heading the same way

Brussels has reached a similar conclusion by a different road. Under the EU KIDS Act proposed in September 2026, online services and app stores must use age assurance tools, for example the EU age verification app, which does not retain identity documents or biometric data. The Commission's explainer adds that app stores must age-rate every app with a published methodology, must not let children access or buy apps inappropriate for their age, and must carry the EU age verification app.

That gives a British developer three regimes moving towards a common shape, with app stores carrying age information and developers expected to read it, set age-appropriate defaults and keep their own ratings honest. The details differ, and in Europe the text is still a proposal, but nobody building an app for families in 2027 should be designing as if the store will stay a neutral shop window.

What UK technology leaders should do before 2027

Build an internal age decision that can take inputs from more than one source, including a platform age category, a parental consent status and the app's own checks, and that applies the most protective result by default. Make the defaults for each age band explicit in configuration rather than scattered through code, so that a regulator's question about what a 14-year-old sees can be answered quickly.

Set up the process side too. Keep a log of significant changes to features, pricing, terms and privacy policy, because both American statutes key parental re-consent to those changes, and decide now who signs off an age rating and on what standard.

Then take part in the British debate while it is open. Ofcom's app store work is now public and the government has yet to say whether it will bring stores into scope. Developers have a direct interest in arguing for a single interoperable age signal that satisfies UK duties as well as American and European ones, because the alternative is a different consent flow for every jurisdiction. Whether London chooses that route is still uncertain, and I would not bet the business on the timing. Building the receiving end costs little either way.