If you have a mobile app available in the United States, you may have a compliance deadline coming up in less than a month.
Utah's App Store Accountability Act takes effect on May 7, 2026. Louisiana's follows on July 1. California's version kicks in January 1, 2027. Texas passed its own law targeting January 1, 2026, though enforcement is currently stayed pending litigation. These aren't vague "you should think about age-appropriate experiences" guidelines — they're laws with specific technical obligations that flow directly to app developers.
The good news: Apple and Google have both shipped APIs to help you meet these requirements without building your own age verification infrastructure. The less good news: a lot of developers haven't integrated them yet, and the window for Utah is now very short.
This guide covers what the laws actually require from you as a developer, what the Apple and Google APIs do, how to implement them, and what happens if you don't.
what these laws actually require#
The state App Store Accountability Acts share a common structure. At the app store level, Apple and Google are required to verify the age of users in covered states before allowing app downloads, obtain parental consent for users under 18, and pass age and consent signals to developers.
Your obligations as a developer flow from that last point. Specifically, if your app is available to users in a covered state, you're expected to:
- Integrate the platform APIs to receive age range signals and parental consent status for applicable users
- Gate or restrict app features appropriately based on those signals
- Handle "significant change" notifications — when a parent revokes consent or a child's account status changes, you need to restrict access promptly
- Keep any received age or consent data confidential, use it only for compliance purposes, transmit it securely, and delete it after use
- Assign an age rating to your app and any in-app purchases and document the content that informed those ratings
The laws don't require you to build your own age verification system — that's handled at the app store level. Your job is to consume the signals Apple and Google send you and act on them appropriately.
apple's declared age range api#
Apple's Declared Age Range API is the primary mechanism for receiving age information about your users. Here's what it gives you and how it works.
what you receive#
When a user in a covered state downloads or opens your app, Apple can provide your app with a declared age range — not the user's exact birthdate, but an age category. The categories are coarse by design, for privacy reasons: Apple doesn't want your app to have precise birth dates when all you need is "is this person a minor?"
You also receive a signal about the method of age assurance Apple used (credit card, government ID, etc.) and whether parental consent is required for this account. For users under 18, you'll receive consent status.
the significant change api#
Beyond the initial install, Apple also provides a Significant Change API that your app can invoke when you're about to make a meaningful change — a new subscription tier, a significant feature update, a change to data handling practices. This invokes a system experience that allows the user to request that parental consent be re-obtained if applicable.
Separately, Apple will notify your app when a parent withdraws consent or a child's account status changes. Your app needs to handle this notification and restrict access accordingly within a reasonable timeframe.
implementation basics#
The API surfaces through the App Store framework. You'll query for age-related signals when your app launches or when a user attempts a gated action. The flow looks roughly like this:
- At app launch or gated feature entry, request the age signal from the framework
- Check the returned age category — Apple's API provides well-defined constants
- If the user is categorized as a minor without parental consent, restrict the relevant features
- Register a notification handler for consent withdrawal events and respond appropriately
Apple has provided sandbox testing tooling that lets you simulate different age scenarios (user is 15, parent revokes consent mid-session, etc.) so you can test your implementation without real users.
google's play age signals api#
Google's approach is structurally similar but architecturally distinct. The Play Age Signals API provides developers with account-level age and supervision status from the Play Store. Unlike Apple's method-of-assurance model, Google's API focuses on the account status itself — you receive signals about whether the account is a supervised child account, and what age range applies.
what you receive from google#
The Play Age Signals API surfaces:
- Whether the user is on a supervised (child) account
- The user's age range, if available
- Whether parental approval is required for the current context
Google's API was in beta as of early 2026 and the implementation details have continued to evolve. Check the Play Console documentation for the current stable surface before integrating.
handling family link accounts#
On Android, many minors use accounts governed by Google Family Link. Your app should already be handling this gracefully, but the new API makes the obligation explicit. If a Family Link account installs your app, you need to check the age signal and restrict accordingly — not rely on the parent having restricted the app at the Family Link level.
the state-by-state timeline#
Here's where things stand as of April 2026:
Texas — Effective January 1, 2026, though a federal district court issued a preliminary injunction staying enforcement while litigation over First Amendment concerns continues. Texas developers should still implement the APIs, but the immediate enforcement risk is lower while the injunction holds.
Utah — Effective May 7, 2026. No known litigation stay. This is the most pressing near-term deadline for most developers.
Louisiana — Effective July 1, 2026. Similar requirements to Utah, with specific provisions around direct messaging features and content restrictions for minors.
California — Effective January 1, 2027. California's AADC (Age Appropriate Design Code) framework has been in effect separately, but the App Store Accountability Act requirements align with the January 2027 date.
If your app has meaningful usage in any of these states — which for most U.S.-distributed apps means all of them — you should be integrating both the Apple and Google APIs now rather than approaching each deadline individually.
what happens if you don't comply#
The laws create obligations at both the app store level and the developer level. Apple and Google bear the primary enforcement risk for their platforms, which is why they've moved to build and surface these APIs. But developers aren't fully insulated.
Non-compliant apps can be removed from app stores in covered states. State attorneys general have enforcement authority. More practically, if your app has age-restricted content or features and you're not gating them for minors in these states, you're exposed — both legally and in terms of App Store review.
Apple and Google have both communicated that they expect developers to implement the APIs and act on the signals received. Failure to do so after the effective dates will increasingly appear as a compliance gap during App Store review.
practical checklist for most apps#
If your app doesn't contain content that's inherently restricted to adults — no gambling, alcohol, explicit content, etc. — your compliance burden is relatively light. Here's a reasonable implementation approach:
For apps rated 4+ or 9+ with no restricted features: Integrate the APIs, confirm the age signals are being received, and log them. Your gating logic may be minimal (or none), but you should be able to demonstrate that you've integrated the APIs and handle the signals.
For apps with any in-app purchases, subscriptions, or features you'd consider inappropriate for minors: Implement gating logic. When you receive a minor signal without parental consent, disable purchase flows, hide restricted features, and surface an age-appropriate experience. Test this thoroughly with Apple's sandbox tooling.
For apps with significant social or messaging features: Louisiana and other states have specific provisions around direct communication features. Review the Louisiana law's specific requirements for messaging features and apply additional restrictions as needed.
For all apps: Update your privacy policy to reflect your age data handling. You should describe that you receive age signals from app stores, how you use them (compliance only), and how you handle them (secure transmission, deletion after use). This is both a legal requirement and an App Store review expectation.
how stora fits in#
The trickiest part of this compliance picture isn't the technical integration — both Apple's and Google's APIs are well-documented and relatively straightforward to implement. The hard part is making sure you've done it before your next submission, and that your store listing metadata (age ratings, content descriptions) accurately reflects your app's content.
Stora's compliance engine validates your age rating configuration against your app's actual feature set and flags inconsistencies before submission. If your app has an in-app purchase that should carry an age restriction your current rating doesn't reflect, that surfaces before Apple's review team sees it. Combined with the pre-submission checklist for new SDK requirements and privacy manifests, it's designed to catch the kind of compliance gaps that cause delayed releases at the worst possible time.
the bottom line#
Five US states will have active age verification requirements for app developers by January 2027, with Utah's deadline hitting in less than a month. The technical implementation isn't complex — both Apple and Google have done the heavy lifting at the platform level — but the integration work takes time, and testing the edge cases (consent withdrawal, minor account detection, gated feature handling) takes more time than most developers budget for.
If your app is distributed in the US and you haven't started this integration yet, start now. The Utah deadline is May 7. That's four weeks from today.