App Store Accountability Acts 2026: Age Signals and Parental Consent for AI Apps

What Actually Changed for Developers

Four shifts, each independent of the others, and none of them satisfied by an age gate in your onboarding flow.

The store verifies; you consume the result

The structural move in these statutes is to put age verification on the app store rather than on every developer. Apple and Google are required to establish the age category of an account holder, to associate minor accounts with a parent, and to make that category available to developers. The developer-side duty is not to verify — it is to request the signal, receive it, and behave differently once it arrives. A product that never calls the API is not neutral; it has declined to collect a fact the law assumes it holds.

Knowledge is now imputed, not actual

Most children's-privacy exposure in the United States has historically turned on actual knowledge that a user is a child. A statutory signal collapses that defence. Once the platform hands you a category, 'we did not know' stops being available for that user, and every downstream obligation — consent, data handling, feature gating — is measured from the moment the signal was available rather than the moment you looked at it.

Consent is per-download and per-purchase

For an account in a minor category, the parent's consent is required before the app is downloaded and before in-app purchases are made. The consent flows through the store rather than through your onboarding, which is convenient until you realise the corollary: you cannot cure a missing consent inside your own product, and you cannot treat a completed install as evidence that consent for anything else was given.

Material changes reopen consent

The provision that catches AI products is the significant-change duty. When an app materially changes what it does with a minor's data or how the product functions, fresh parental consent is required. Shipping a model that now retains conversation history, adding a companion persona, turning on personalised recommendations or introducing a feature that collects voice — each is a candidate. Continuous deployment and per-download consent are in structural tension, and nobody has resolved it for you.

The AI Features That Change Behaviour on a Minor Signal

For each: why the age category matters to it specifically, and the artefact that implements the difference in a way an auditor can verify.

Conversational assistants and companions

Why it is exposed: A general-purpose chatbot inside a minor's account is the highest-salience feature in this entire area — it collects free-text personal disclosure, it is unpredictable by construction, and it is the specific product category legislators had in mind. Expect the age category to be treated as a hard gate rather than a preference.
What you have to build: A server-side capability check keyed to the age category before the assistant renders at all, a minor-mode system prompt and refusal policy that is enforced in the backend rather than in client copy, and retention defaults for minor conversations that differ from adult ones and are documented as differing.

Personalisation and recommendation models

Why it is exposed: Behavioural profiling of minors is restricted or prohibited under several overlapping regimes, and a recommender trained on engagement is exactly the mechanism those provisions target. The app-store statutes add the consent layer; the state privacy statutes add substantive limits that consent does not cure.
What you have to build: A profile-building switch that is off by default for minor categories, ranking that falls back to non-behavioural signals, and an audit record showing that a minor account's events were excluded from training and from the profile store — not merely hidden from the UI.

Voice, camera and biometric-adjacent input

Why it is exposed: Voice capture and face-based features pull in biometric statutes with their own consent standards and, in Illinois, a private right of action. A parental consent obtained through an app store is not a BIPA-compliant written release, and treating it as one is a common and expensive substitution.
What you have to build: Separate, explicit consent capture for biometric identifiers with its own record, retention schedule and deletion path, layered on top of — never instead of — the store-mediated parental consent.

Advertising and monetisation surfaces

Why it is exposed: Targeted advertising to known minors is restricted almost everywhere the question has been legislated, and in-app purchase flows now require parental consent at the transaction rather than at install. Ad SDKs are the usual failure: the app respects the age signal and the embedded SDK does not.
What you have to build: Propagate the age category into every SDK's initialisation call, verify the downstream behaviour changes with a real minor-category test account, and keep the vendor's written confirmation of what it does with that flag.

The Four Regimes Stacked on One User

A single minor account is governed by all of these at once. They do not conflict so much as accumulate, and compliance with the loudest one is routinely mistaken for compliance with the set.

Layer	What it adds for a developer
App store accountability statutes	Texas and Utah are the leading enactments, with additional states following the same template. They allocate verification to the store, require parent association for minor accounts, mandate consent before download and purchase, and impose the significant-change re-consent duty on developers. Enforcement generally sits with the state attorney general, and at least one industry challenge is pending — which is a reason to track the litigation, not a reason to assume the calendar has moved.
COPPA and the amended Rule	Federal children's privacy still governs under-13 users independently. An age signal does not replace a COPPA direct notice or a COPPA-standard verifiable parental consent, and the amended Rule's separate consent for disclosures, written retention policy and data-security programme apply on their own terms. A store-mediated consent may support your COPPA posture; it does not substitute for the notice.
State comprehensive privacy laws	Most state privacy statutes now impose opt-in consent for processing the data of known minors, prohibit targeted advertising and sale for that cohort, and require assessments for profiling. Once the store tells you a user is fifteen, 'known' is satisfied in every one of those statutes simultaneously.
Platform policy	Apple and Google publish their own declaration requirements, age-rating questionnaires and minor-account policies, and these move faster than legislation. A misdeclared age rating or an unanswered AI-feature questionnaire is a review rejection or a removal — an outcome that arrives in days, where the statutory one arrives in months.

Five Failure Modes, All of Them Ordinary

Treating the signal as a client-side preference

Age gating implemented in the app shell is bypassed by an API client, a rooted device or a stale build, and the resulting logs show adult-mode processing on a minor account. The record of what your server did is the evidence, and it will not match your policy.

Assuming COPPA compliance covers it

COPPA programmes are built for under-13. The app-store statutes reach the whole minor cohort, including sixteen and seventeen year olds, and the substantive restrictions in state privacy law reach them too. A compliant under-13 flow leaves the largest part of the exposed population unhandled.

Never defining what a significant change is

Without an internal definition and a gate in release, the decision is made implicitly by whoever ships. The first time it matters is during an inquiry, when you are asked which releases changed minor data handling and cannot answer from your own changelog.

Letting a vendor SDK see the raw account

Analytics, attribution, crash and ad SDKs commonly collect identifiers by default. If the age category never reaches them, your app is compliant and your binary is not — and the plaintiff's expert reads the binary.

Building for one state

The statutes differ in the details and converge in the architecture. A per-state conditional grows unmaintainable within a year; an age-category capability model with per-jurisdiction policy data does not.

The minor-account drill

Create a test account in a minor age category and use your product for ten minutes. Then answer from logs alone: did your server ever see the category, did any AI feature render that should not have, which vendor SDKs fired, what did the model provider receive, and what retention tier was applied to the conversation.

Every answer you have to reconstruct by reading source is an answer you cannot give an attorney general in the time they allow. The drill takes an afternoon and it is the only reliable way to find out whether your age handling exists in the product or only in the policy.

Frequently Asked Questions

We are a web app, not an app store app. Does any of this reach us?

Not directly, and that is worth being precise about rather than relieved by. The app store accountability statutes are addressed to app stores and to developers who distribute through them, so a browser-only product sits outside their operative provisions. What does not sit outside is everything the signal was a shortcut for. State comprehensive privacy laws impose opt-in consent, targeted-advertising prohibitions and profiling assessments for known minors regardless of distribution channel, and 'known' can be established by a birthdate field, an account attribute, a school-based signup flow, or the plain nature of the product. Several states have also legislated age-assurance duties for particular content categories that apply on the open web. The practical planning assumption is that distribution determines which statute names you, not whether a minor-user regime applies. If you have any meaningful under-18 population and you build an age-category capability model now, you inherit the app-store obligations for free the day you ship a mobile client — which most products eventually do.

What actually counts as a 'significant change' that reopens parental consent?

The statutes describe it in terms of material changes to the app's functionality or to how it collects, uses or shares a minor's data, and no regulator has yet produced a worked example, so the defensible move is to write your own definition and apply it consistently. A workable test asks three questions of every release: does it collect a new category of data from minors, does it use existing minor data for a new purpose, or does it change the nature of the interaction the parent consented to? Adding a conversational assistant to a utility app fails the third test unambiguously. Turning on conversation retention where sessions were previously ephemeral fails the second. Adding voice input fails the first. Bug fixes, performance work and cosmetic changes fail none of them. Put the question in your release checklist as a required field, route anything ambiguous to a named owner, and keep the record — because the value of this exercise is not only getting each call right, it is being able to show a consistent decision process across a year of releases when someone asks about the one you got wrong.

Can we just declare a 17+ age rating and avoid the whole regime?

It reduces the surface and it does not eliminate it, and it costs more than teams expect. A higher age rating changes what the store presents and can keep minor accounts from installing, which genuinely removes most of the consent mechanics. But the rating must be accurate for the content, misrating is itself a platform violation, and a 17+ rating on a product that plainly serves a general audience invites the argument that the rating was a compliance device rather than a content judgement. It also suppresses discovery and installs in a way that is rarely worth it for a general-purpose product. More importantly it does not address actual-knowledge exposure: if minors use the product anyway and your own signals show it — school email domains, self-reported ages in conversation, parental complaints in support tickets — you are back inside the state privacy provisions with the additional problem of having declared the cohort out of scope. Rate honestly, then build the capability model.

The store gives us a category, not a birthdate. Is that enough to comply?

For the app store statutes it is the intended input, and building against anything more precise creates its own problem. The design goal of these laws is data minimisation at the developer layer: the store performs the verification, absorbs the identity documents or inference, and passes down a coarse category so that thousands of developers do not each hold a database of children's birthdates. Requesting or storing more than the category works against you twice, because you take on sensitive-data obligations you did not need and you undermine the argument that your handling of minor data is minimal. Where the coarse category is not sufficient is any feature with its own statutory age line — biometric consent standards, alcohol or gambling-adjacent content, or a foreign regime with a different age of digital consent. Handle those as separate, explicit consent events rather than by escalating your baseline collection. The general rule: consume the signal, act on the category, store the decision and not the underlying fact.

How does this interact with our AI vendor — do we have to tell them the user is a minor?

You have to control what happens to that user's data, and telling the vendor is usually the mechanism, so the answer is normally yes with conditions attached. If prompts from a minor account reach a model provider, that provider is processing a minor's personal data on your instruction, and the obligations you carry do not stop at your own boundary. Concretely: confirm in the contract that the provider will not train on the data, set zero or minimal retention for that traffic where the provider offers it, verify that abuse-monitoring retention is disclosed and bounded, and use whatever end-user identifier or policy flag the provider supports so the treatment is enforced on their side rather than promised on yours. Then check the other direction — many providers' terms of service prohibit use by minors or require the customer to obtain consent, which means an unflagged minor population can breach your vendor agreement while you are busy complying with the statute. Read the provider's terms for the minor-user clause before you architect around it; it is the constraint teams discover last and it occasionally decides the design.

What should we build first if we have a small under-18 population?

Build in the order that removes imputed knowledge risk fastest and defers the expensive work. First, request and persist the age category on every session, server-side, even if nothing branches on it yet — this is a day of work and it converts every later question from an archaeology exercise into a query. Second, write the capability model: a single place that maps age category to a set of booleans such as assistant enabled, profiling enabled, voice enabled, ads personalised, retention tier. Third, enforce those booleans in the backend at the point of use, not in the client and not in the API gateway alone. Fourth, propagate the category into vendor SDK initialisation and model-provider calls. Fifth, add the significant-change question to your release checklist with a named owner. Notice the ordering: nothing here begins with a policy document, because the finding that hurts is never that the policy was wrong — it is that the product did not do what the policy said, and no policy edit fixes that after the fact.

The App Store Now Tells You a User Is 14. That Is a Legal Instruction.