Age assurance used to be a problem for social apps and games. That is changing quickly. Apple has spent 2026 shipping tools for state and national age laws, including its Declared Age Range API for Texas, Utah, and Louisiana requirements. California is next, and its law is written broadly enough that most mobile teams should read it. Assembly Bill 1043, the Digital Age Assurance Act, was signed on October 13, 2025 and becomes operative on January 1, 2027. That is about twelve weeks away. If your app ships through an app store and has California users, the developer obligations apply to you, and the statute does not carve out business apps.
What the law actually requires
The law splits responsibilities between operating system providers, app stores, and developers. Operating system providers must offer an accessible interface at account setup where an account holder enters the user's birth date or age, and must provide developers with a real-time signal indicating which of four brackets applies: under 13, 13 to under 16, 16 to under 18, or 18 and over. Developers must request that signal from the operating system provider or a covered app store when the application is downloaded and launched. Once you receive a signal, you are deemed to have actual knowledge of the user's age range across all platforms and points of access to your application. You must treat the signal as the primary indicator of age, unless you have internal clear and convincing information that the user's age is different, in which case that information takes priority. You must request no more information than necessary and must not share the signal with third parties for purposes the law does not require.
Dates and penalties
The main obligations start January 1, 2027. There is also a transition rule: if your app was last updated on or after January 1, 2026, was downloaded before January 1, 2027, and you have not requested a signal for that user, you must request one from a covered app store before July 1, 2027. Operating system providers have until July 1, 2027 to offer the age interface on devices set up before 2027. Enforcement is by the California Attorney General through civil actions, with penalties of up to $2,500 per affected child for negligent violations and up to $7,500 per affected child for intentional ones. Those numbers scale with your user base, so this is not a rounding error for consumer apps.
Why B2B app teams should care
It is tempting to assume a field-service, logistics, or healthcare staff app is out of scope because its users are employees. The statute defines a developer simply as a person that owns, maintains, or controls an application, and it requires the signal request when the app is downloaded and launched. There is no exemption for enterprise apps distributed through public stores. Read the law with your counsel, but plan engineering as if the request applies. The work is modest, and being wrong is expensive. The more interesting question for B2B teams is what happens after the signal arrives. Most will receive "18 and over" for nearly every user. The edge cases matter: student workers, apprentices, family accounts on shared devices, and consumer-facing companion apps built by B2B vendors.
A build plan for the next twelve weeks
1. Map your platforms. On iOS, Apple's Declared Age Range API is the obvious starting point, since Apple already uses it for other state laws. On Android and other stores, track each platform's developer guidance as it rolls out, and design an abstraction that does not assume one vendor's API shape. 2. Request at the right moments. Wire the request into first launch after download, and decide how you will handle existing installs to satisfy the July 1, 2027 transition rule. 3. Store the bracket, not the birth date. Persist only the bracket and when you received it, tied to the account, and keep it out of analytics and advertising pipelines. 4. Define behavior per bracket. Decide what changes for under-18 users: data collection, sharing, features, and notifications. Write it down as product policy, then implement it. 5. Reconcile with what you already know. If your onboarding collects a date of birth, or an employer tells you a user's age, document how that interacts with the signal under the clear-and-convincing rule.
type AgeBracket = 'under13' | '13to15' | '16to17' | 'adult';
interface AgeSignalRecord {
bracket: AgeBracket | 'unavailable';
source: 'ios-declared-age-range' | 'android-store' | 'other';
receivedAt: string; // ISO timestamp
appVersion: string;
}
// Never forward AgeSignalRecord to analytics or ad SDKs.
export function policyFor(b: AgeSignalRecord['bracket']) {
return b === 'adult' ? 'standard' : b === 'unavailable' ? 'retry-later' : 'minor-protections';
}Do not forget the web and other surfaces
Actual knowledge applies across all platforms and points of access to your application. If a user's signal says they are under 18 in the mobile app, your web app, support tooling, and marketing systems need to respect the same policy for that account. Make the bracket part of the account record your other systems already read, and test the cross-platform path before January. It is also worth adding the signal to your privacy documentation so customer security teams see a consistent answer.
Founder takeaway
January 1, 2027 is close enough to plan for now and far enough to do it calmly. Have counsel confirm scope, add the signal request at download and launch, store only the bracket, define what changes for minors, and keep the signal away from third parties. Ship it in a regular release this quarter so the deadline passes without drama.
