The $10,000-Per-Violation PDF: Age Compliance for Indie App Studios

Sell the Paper Trail, Not the Age Check

On July 29, 2026, Google told Android developers that its Play Age Signals API is going global. Australia and Canada come online in mid-August. Every remaining market follows before the end of the year. The API has been live in Brazil since March, and Google has been returning real signals to apps for Texas users whose accounts were created after May 28.

At a glance, it looks like Google solved age verification for Android. It solved one piece of it.

Google now hands your app a privacy-preserving signal: an age band, whether the account is supervised, whether the user declined to share, whether verification is still required. Your app never sees a passport, a selfie, or a birthdate. Apple built the same primitive through its Declared Age Range API, with PermissionKit handling parental approval when an app makes what the law calls a "significant change."

Both companies stop in the same place. They deliver the signal, they don't tell you what to do with it, and they don't help you prove you did it correctly. That second half is where the business is.

Here's the opportunity:

What the Platforms Actually Give You

Google's API is a client-side runtime call. Your Android app asks, and Play answers with an age range, a "declined," a "not available," a "verification required," or a supervision state. Texas law defines the bands the industry has settled on: child under 13, younger teenager 13 to 15, older teenager 16 to 17, adult 18 and up.

Apple's version returns a range rather than a birthday, plus three signals that matter more than the age itself: whether age-related regulatory requirements apply to this user, whether the user is required to share a range, and whether a parent must approve a significant update before the child keeps using your app.

These are useful primitives. They spare every indie app from building identity collection it has no business owning. What they don't do is convert an age band into a compliance program.

Take a five-person team running a social journaling app with public profiles, direct messages, user-generated content, in-app purchases, algorithmic recommendations, and an AI companion. The API returns 13 to 15. The team now has to pick one answer per feature: kill DMs or restrict them to mutuals, pull the profile out of discovery or leave it, retune recommendations, limit what the AI companion will discuss, decide whether adding live video next quarter counts as a significant change, decide what happens to accounts that predate the rule.

Neither platform can answer that. It depends on the feature set, the jurisdictions the app ships to, the store's own policies, and the company's reading of its obligations. Google's guidance is explicit: developers are responsible for reviewing applicable laws and determining their own obligations, and the announcement frames integration as optional, giving developers "complete agency." Texas is blunter. The statute leaves developers to decide when a significant change has occurred, and attaches civil penalties of up to $10,000 per violation to focus the mind.

That's a quarter of work for a company with in-house counsel, and a problem nobody owns at a studio with six apps and no lawyer.

The Rules Moved After the Platforms Shipped

On February 24, 2026, Apple published a rollout schedule to developers. Age categories would be shared for new Apple Accounts in Utah starting May 6, and in Louisiana starting July 1. Developers read that, put it in a ticket, and planned around it.

Then the laws moved. Louisiana signed HB 977 on May 15, pushing its App Store Accountability Act to July 1, 2027. Utah amended its own act, slid the effective date to May 6, 2027, and stripped the attorney general's enforcement authority, leaving only a private right of action. Texas went the other direction: SB 2420 took effect January 1, was preliminarily enjoined in December 2025, got the injunction stayed by the Fifth Circuit, and became fully live when the Supreme Court declined to intervene on July 6, 2026, in two unsigned orders with no dissents. The merits are still open. The Fifth Circuit has an expedited hearing on the substantive appeal set for early August 2026.

Inside eight months, one state's regime went from enjoined to enforceable while two others slipped a full year, one of them also changing who is allowed to sue. The platform documentation, the legal reality, and whatever a developer wrote in a Jira ticket in March all point in different directions right now.

Nothing tracks that drift. A studio that shipped an implementation in April has no mechanism telling it which of its assumptions expired, which is what turns a one-time chore into work a team has to revisit every release.

Why the Timing Is Real

Compliance tooling sells when three conditions land together: a requirement becomes operational instead of theoretical, a large population has to change working software, and the platform ships primitives while pushing implementation onto the customer. All three are true this quarter.

Texas is enforceable today, and Google is already returning live Texas signals. Australia has been running the world's first under-16 social media ban since December 10, 2025, with penalties up to AUD 49.5 million; platforms had removed 4.7 million under-16 accounts by mid-December, and the eSafety Commissioner's Phase 2 industry codes extend age-assurance duties past social media into gaming, messaging, search, and app stores. Google's global Play rollout lands on top of that before December.

None of which means a weather app has to rebuild onboarding. Exposure varies enormously by category. It does mean that over the next few quarters, several thousand mobile teams will independently work through the same six questions: does this apply to us, which APIs do we implement, what should the app do with each response, how do we test it, how do we document the decision, and how do we find out when the rules change.

Those are engineering questions with a legal surface, and somebody gets paid to answer them over and over.

The Product: An Age-Assurance Release Console

The product should never promise to make an app compliant. That promise is unbackable, and it's the fastest route to getting sued alongside your customer. Sell a repeatable process instead: understand the requirement, choose an implementation, test the behavior, approve the decision, keep the evidence.