The store now tells you your users' ages. Google's terms forbid putting it in analytics.

Play's Age Signals terms limit the signal to age-appropriate experiences and name advertising, marketing, profiling and analytics as prohibited uses, with app takedown as the stated penalty. Apple's version hands you the age plus how it was proven. Both are live now in a widening list of regions, and the default engineering reflex is wrong for both.

There's a new field arriving in mobile apps this year and almost nobody is treating it as a product decision. It's the user's age, handed to you by the store instead of asked for in your onboarding.

Here are the dates, from the platforms' own developer docs rather than the coverage. Apple says that for new Apple Accounts in Utah as of 6 May 2026 and in Louisiana as of 1 July 2026, age categories are shared with your app when you ask through the Declared Age Range API. Separately, since 24 February 2026 Apple blocks users in Australia, Brazil and Singapore from downloading apps rated 18+ unless they've been confirmed as adults. Google's Play Age Signals API started returning signals for Brazil on 17 March 2026 and for eligible Texas users who created their accounts after 28 May 2026. More states are queued behind those.

Two things in there that I think will bite people.

The one that's a takedown risk.

Google's terms of service for the Age Signals API say you may only use the information to provide age-appropriate content and experiences in compliance with law, and then names what you may not use it for: advertising, marketing, user profiling, or analytics. The stated consequence for a prohibited use is termination of API access and suspension or takedown of your apps.

Now think about how a new user property actually enters a codebase. Someone adds it to the user object. The analytics SDK is configured to forward user properties. It's in Mixpanel by Thursday and in the warehouse by Friday, and nobody made a decision at any point, because forwarding user properties is what the pipeline is for. Then in the next planning cycle a perfectly reasonable person breaks retention down by age band, because it's sitting right there in the dropdown.

That path has no decision point in it. It's a default. And it lands you squarely in a clause with app removal attached to it. If you integrate this API, the work isn't the integration, it's the wiring you have to actively prevent.

The one that's more interesting.

Apple's API doesn't just tell you an age band. It tells you how the age was established. The declaration comes back as self-declared, guardian-declared, checked by another method, government-ID checked, or payment checked, with guardian equivalents for each. There's also a signal for whether regulatory requirements apply to this user at all, and whether they're required to share.

So age arrives with a provenance attached. And I'd bet almost every implementation collapses it to a single isMinor boolean on the first day and throws the rest away, because that's the shape the rest of the code wants.

I want to be honest that for a lot of apps, discarding it is the right call. If your only use is "don't show this content to a 13-year-old," you behave identically whether the 13 was typed in or proven by ID. But there's a class of product where the difference is the whole thing: anything where a wrong answer is expensive, or where you're deciding how cautious to be rather than what to hide. Self-declared 18+ on a device with parental controls off is a different fact from ID-verified 18+, and the API is telling you which one you have. Losing that in a cast is a decision. Make it on purpose.

The part that touches your roadmap.

Both platforms now have a mechanism for a "significant app update" that requires a parent's approval before a child can keep using your app. Apple is explicit that until the parent consents, the child must be prevented from accessing the update, which may include all app and account data or specific features, and that if a parent revokes consent, Apple will prevent the app from launching. You get a RESCIND_CONSENT server notification when that happens. Google has the equivalent: notify Play of significant changes, and handle revoked approvals.

Neither of them defines significant. Apple says plainly that you determine what constitutes a significant app update, based on applicable law, and to consult your counsel.

That's the sentence I'd sit with. A definition you write yourself now controls whether shipping a given release locks a cohort of your users out of their own data pending someone else's tap. For an AI product it's genuinely unclear where the line sits. Is swapping the underlying model a significant change to what the app does? Is broadening what the assistant will discuss? I don't think anyone knows yet, and I'd rather have written down my answer before a release forces one.

Where I actually am on this.

Murror is an emotional-reflection product, so the age of the person on the other side is not a compliance field to me, it's the most load-bearing context I could have. And I still don't have a clean answer on the verification-method question, because the honest version is that I don't yet know what I'd do differently with a government-ID-checked 16 versus a self-declared one. I'd rather say that than write a paragraph pretending I've resolved it.

The thing I am confident about is narrower. The signal is sparse for a long while yet. Texas only covers accounts created after a date in May, Apple's state coverage is new accounts only, and users can decline to share. So any product logic that assumes you now know everyone's age is wrong, and the interesting engineering question is what your app does in the large unknown bucket, which is where most of your users will sit for the foreseeable future.

Four things I'd do this week if you ship a mobile app. Check whether your analytics SDK auto-forwards new user properties, before you add one you're contractually barred from analysing. Decide, in writing, whether verification method changes your behaviour. Write your own definition of a significant update while it's cheap. And implement the revocation notification, because an app that can be prevented from launching is a support-load event you'd much rather see coming than hear about.

None of that is hard. It's just that none of it happens by default, and the default here has a penalty clause attached.