Last updated: 2026-10-02
On September 10, 2026, Governor Newsom signed AB 1856, which rewrites California's Digital Age Assurance Act (AB 1043), together with AB 1709 and AB 2246. California, Texas, Utah, Louisiana and Alabama now have app store age verification laws. The age signal is the user's age bracket, which the operating system provides to a developer on request. From January 1, 2027, a California developer that receives the signal "shall be deemed to have actual knowledge of the age range of the user": the law treats the developer as knowing the bracket. Under the CCPA, actual knowledge of a consumer under 16 triggers an opt-in rule for selling or sharing that consumer's data.
What does California's Digital Age Assurance Act require from 2027?
Under the amended act, an operating system provider asks for the primary user's age or birth date at account setup (Civ. Code 1798.501(a)); a covered app store requests the signal and provides it to developers on request (1798.501(c)); the developer requests the signal "when the application is downloaded onto, and launched from, a particular device" (1798.501(d)(1)(A)).
The signal is "age bracket data that pertains to the primary user of a device" (1798.500(h)), in four brackets: under 13, 13 to 15, 16 to 17, and 18 or older. AB 1043 makes the title operative on January 1, 2027 (1798.505). Under the transition rule (1798.502), devices set up before that date get the age prompt before July 1, 2027, and installed apps last updated on or after January 1, 2026 request a signal before the same date.
The amended text also limits what the developer does with the signal. The developer has actual knowledge of the age range "even if the developer willfully disregards the signal" (1798.501(d)(2)(A)). It "shall use that signal to comply with applicable law but shall not ... Share the signal with a third party for a purpose not required by this title" (1798.501(d)(4)). And a person "shall not request a signal" unless this title or another law requires it (1798.501(e)).
CCPA section 1798.120(c) is the rule that actual knowledge triggers: "a business shall not sell or share the personal information of consumers if the business has actual knowledge that the consumer is less than 16 years of age", unless the consumer (13 to 15) or a parent or guardian (under 13) opts in. That link is a reading of the statutory text. The deemed-knowledge clause becomes operative on January 1, 2027, so as of October 2, 2026 no court has applied it.
Under AB 1709, "A covered platform shall not provide an addictive feature to a user who is under 16 years of age", and the platform verifies age "pursuant to the Digital Age Assurance Act" (Bus. & Prof. Code 22683, 22684). AB 2246 repeals and replaces the Age-Appropriate Design Code: a service likely to be accessed by children estimates age "with a reasonable level of certainty" or protects every consumer as a child, and by default does not profile a child or collect, sell or share a child's precise geolocation (Civ. Code 1798.99.29). With no operative-date clause, both take effect January 1, 2027 under the California Constitution, article IV, section 8(c).
Which states have app store age verification laws?
| State and law | Signed | Effective | Who must do what | Enforcement and status |
|---|---|---|---|---|
| California, AB 1043 as amended by AB 1856 | 2025-10-13; 2026-09-10 | 2027-01-01 | OS collects age at setup; store passes the bracket signal on; developer requests it at download and launch, shares it only as the title requires | Attorney General only (1798.503(a)); up to $2,500 (negligent) or $7,500 (intentional) per affected child |
| California, AB 1709 | 2026-09-10 | 2027-01-01 | Platforms verify age through the act and withhold addictive features under 16 | Attorney General or local public prosecutor; up to $25,000 (negligent) or $50,000 (knowing) per affected minor |
| California, AB 2246 | 2026-09-10 | 2027-01-01 | Services likely accessed by children estimate age or protect all users; no default profiling or precise geolocation of under-18s | Attorney General or public prosecutor; up to $5,000 (negligent) or $15,000 (intentional) per affected child |
| Texas, SB 2420 | 2025-05-27 | 2026-01-01 | Store verifies age and gets parental consent for minors; developer verifies through the store, uses the data only for age limits, compliance and safety, then deletes it | Deceptive trade practice under the DTPA; enforceable since the 2026-06-04 Fifth Circuit stay; appeal pending |
| Utah, SB 142 as amended by HB 498 | 2025-03-26; 2026-03-18 | 2027-05-06 (store and developer duties) | Developer verifies through the store at download, purchase or first launch of a pre-installed app; may not share age category data with any person | Harmed minor or parent may sue; greater of actual damages or $1,000 per violation |
| Louisiana, HB 977 (Act 185), replacing HB 570 (Act 481, which never took effect) | 2026-05-15 | 2027-07-01 | Developer verifies with the store signal; if it knows its own data is more accurate, uses that or the lower signal; may not sell age category data | Attorney General; up to $10,000 per violation; 45-day notice and cure |
| Alabama, HB 161 (Act 2026-59) | 2026-02-17 | 2027-01-01 | Developer verifies through the store, uses the lowest age category from store or own data; may not share age category data with any person | Attorney General only, for knowing or reckless violations; up to $7,500 per violation |
What is the status of the Texas app store law?
Texas SB 2420 has been enforceable since June 4, 2026, when a Fifth Circuit panel, in Students Engaged in Advancing Texas v. Paxton (No. 25-51073), consolidated with CCIA v. Paxton (No. 26-50001), stayed the district court's universal preliminary injunctions pending appeal. Judge Haynes concurred only in the stay. From the stay order:
At most, SB2420 regulates speech that “proposes a commercial transaction,” which is subject to intermediate scrutiny.
App listings propose commercial transactions, regardless of whether any monetary payment is made. In fact, the “payment” for apps that are purportedly “free” is access to user data and private information.
On July 6, 2026, the Supreme Court denied the applications to vacate the stay (25A1389 and 25A1390). Apple told developers on June 3 that new Apple Accounts in Texas are subject to the law from June 4. As of October 2, 2026, the June 4 order is the latest published Fifth Circuit ruling in No. 25-51073, and the appeal is pending.
What must an app or SDK do with the age signal?
Texas section 121.056(a)(3) treats it as a violation when a developer "shares or discloses the personal data of a user that was acquired under this subchapter", and Utah and Alabama bar sharing age category data "with any person". Those clauses cover the developer's use of the age data. The advertising identifier and location that the developer's ad SDK collects from a known minor fall under the rules that actual knowledge triggers, such as the CCPA's under-16 opt-in and, for services likely to be accessed by children, AB 2246's default bar on collecting a child's precise geolocation.
From Google's API overview: "You may not use the Play Age Signals API for any other purpose including, but not limited to, advertising, marketing, user profiling, or analytics."
Which APIs deliver the age signal?
Apple's DeclaredAgeRange framework is available from iOS 26.0. An app requests the range with AgeRangeService.shared.requestAgeRange(ageGates:_:_:in:), passing up to three age gates (ages to check). The Response is either .sharing(range:), a range with lowerBound and upperBound, or .declinedSharing when the person refuses. Apple's guide states that in some regulated regions the system provides the age range automatically and the person cannot decline. iOS 26.4 adds requiredRegulatoryFeatures, which returns a set of regulatory flags such as significantAppChangeRequiresParentalConsent.
Google's Play Age Signals API is the Android equivalent, in beta, shipped as the com.google.android.play:age-signals library. Its default ranges are 0 to 12, 13 to 15, 16 to 17 and 18 and over. It started returning signals for eligible Texas users with accounts created after May 28, 2026 (overview). In the request flow, the app first calls requestAgeSignalsAccess(), which returns SHARED, NOT_SHARED or VERIFICATION_REQUIRED. It then calls checkAgeSignals(), whose result contains the age bounds (ageLower(), ageUpper()), installId() and ageRangeSource().
How do a binary and a traffic capture show what an app does with the age signal?
An iOS binary names each system framework it links in a load command. Three artifacts indicate the Apple API: a load command for /System/Library/Frameworks/DeclaredAgeRange.framework/DeclaredAgeRange, the path in Apple's iOS 26 SDK; the com.apple.developer.declared-age-range entitlement, which the framework requires; and compiled Swift names imported from the DeclaredAgeRange module, which decode to names such as AgeRangeService.requestAgeRange.
In an Android APK, the published library puts the API classes in the package com.google.android.play.agesignals: AgeSignalsManagerFactory, AgeSignalsManager, AgeSignalsRequest and AgeSignalsResult. R8, Android's code shrinker, can rename these classes; the interface name the library uses for calls to Google Play, com.google.android.play.agesignals.protocol.IAgeSignalsService, is a string constant in the library (version 0.0.4) that renaming leaves intact.
Static presence shows that the code is in the binary; whether the app calls the API, and whether the result changes what its ad SDKs send, takes a traffic capture to establish.
The capture uses one build and two accounts, an adult and a 13 to 15 account (a Family Sharing child account on iOS, a supervised Google account on Android). I compare both captures, request by request, for the ad hosts contacted and these fields:
- The advertising identifier, as
device.ifain OpenRTB 2.6 or an SDK's own field. - Location in
device.geoor equivalent, with coordinate precision. regs.coppa, OpenRTB's COPPA flag, and child-directed flags such as the one Google Mobile Ads sets throughsetTagForChildDirectedTreatment().- The age bracket value in any request to a host other than the developer's.
The result the test looks for is an ad request from the minor account that contains the same identifier and location fields as the adult session. Field names vary with each SDK's format, and what the SDK's server does with a request is outside any device capture. Our post on EFF's study of four Android ad SDKs applies the same method to location; EFF found that those SDKs' COPPA modes "are not the default".
How does a CanITrustThat scan test an app's use of the age signal?
A CanITrustThat scan lists whether the binary references the DeclaredAgeRange framework or the Play Age Signals library, next to the ad SDKs found in the same build, with file and line for each finding. The network tier records traffic on test devices, each request timed against the app's prompts; the methodology page sets out what a scan checks and the scan's limits.
I treat static findings as leads: an app with a DeclaredAgeRange load command and three ad SDKs goes on the capture list, and a captured minor-account request containing ifa is the evidence of transmission. Scanned apps are listed in the app index, and I can scan a list of iOS and Android apps in bulk ahead of January 1, 2027. Sign up for a CanITrustThat account to run your own research, or let us run an investigation for you.