On this page · 10 sections
- What changes on 1 January 2027, and what AB 1856 changed
- Who is covered: OS providers, app stores and developers
- What developers must do, clause by clause
- What the signal triggers under other laws
- Apple Declared Age Range vs Google Play Age Signals
- Penalty exposure: a worked example
- Developer checklist for 1 January 2027
- Other states, Brazil and India: one architecture, several rulebooks
- How eCorpIT can help
- References
Summary. California's Digital Age Assurance Act (AB 1043, Chapter 675 of 2025, Civil Code section 1798.500 onward) becomes operative on 1 January 2027, but not in the form signed on 13 October 2025. AB 1856, approved on 10 September 2026 as Chapter 184, rewrote it. Operating system providers must collect a birth date or age at device account setup and answer requests through a real-time API with one of 4 brackets: under 13, 13 to 15, 16 to 17, or 18 and over. Every developer with an app in a covered app store must request that signal when the app is downloaded onto, and launched from, a device. AB 1856 extends the signal to primary users of any age, makes app stores request and relay it, excludes distributors of openly licensed software from the OS provider definition and adds a good-faith safe harbour for developers. For apps updated since 1 January 2026 and installed before 2027, requests are due before 1 July 2027. Penalties remain up to $2,500 per affected child for each negligent violation and $7,500 for each intentional one, recoverable only by the Attorney General. Apple's Declared Age Range API and Google's Play Age Signals API (beta) can return matching brackets, but on 1 November 2026 neither company's documentation names California.
About this article. For mobile, product and privacy teams with apps available to California users. On 1 November 2026 we read the chaptered text of AB 1043 (13 October 2025) and AB 1856 (10 September 2026), the two 2026 bills that build on them, and Apple and Google developer documentation. This is general information, not legal advice, so confirm your position with your own counsel. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
What changes on 1 January 2027, and what AB 1856 changed
Signing AB 1043, the Governor asked for a 2026 bill to answer streaming services and game developers, whose existing age systems already deal with family accounts and profiles used across devices.
AB 1856, also by Assemblymember Buffy Wicks, was introduced on 11 February 2026, passed the Assembly 68-1 on 26 May and the Senate unopposed on 26 August, and was signed on 10 September. The Senate had taken out a version that extended the framework to browsers and websites, in its amendments of 1 July. The table compares the two chaptered texts.
| Provision | AB 1043 as signed (Oct 2025) | As amended by AB 1856 (Sept 2026) |
|---|---|---|
| Whose age is signalled | User meant a child who is the primary user of the device | User definition deleted; signal covers the primary user, adults included |
| Who is a developer | Anyone who owns, maintains or controls an application | Owner of an app, or whoever maintains or controls its hosting, in a covered store |
| App store role | Permitted signal source, bound by non-discrimination rules, with no duty to request or relay signals | Must request the signal from the OS provider and pass it to developers on request |
| Open-source software | Covered like any OS provider | OS provider excludes anyone distributing an OS or app under licence terms allowing copying, redistribution and modification |
| What counts as an app | Any software application that can reach a store or download an app | Excludes software components not offered as a stand-alone executable app in a covered store |
| Extension and plug-in stores | Already not a covered store if the software runs only inside a host application | Unchanged |
| Browsers and websites | Not covered | Proposed framework deleted before passage |
| Family sub-accounts | Not addressed | Age information from an account holder about a sub-account user counts as clear and convincing information |
| Developer liability for bad signals | Safe harbour for OS providers and stores only | Good-faith developers not liable for an erroneous signal or the OS's conduct |
| Login checks | Not addressed | No request needed at every login; periodic requests allowed |
| Devices and apps before 2027 | OS interface and developer requests before 1 July 2027 | Same date; developers may now ask the OS provider as well as the store |
| Penalties | Up to $2,500 (negligent) or $7,500 (intentional) per affected child | Unchanged; Attorney General only |
The start date did not move: section 1798.505, which AB 1856 left alone, still sets 1 January 2027.
Who is covered: OS providers, app stores and developers
Operating system providers develop, control or grant licences for OS software on a computer, phone or other general-purpose computing device. Where an OS has an account setup feature, the provider must show an accessible interface at setup that requires an account holder (an adult, or a parent or guardian of a user under 18 in California) to enter the primary user's birth date, age or both. It then answers signal requests through a reasonably consistent real-time API and sends only the minimum information needed.
Covered application stores are publicly available websites, apps, services or platforms that distribute third-party apps.
Developers are persons who own an app, or maintain or control its hosting, in a covered application store. If you publish to the App Store, Google Play or another public third-party store, you are a developer, whatever your app does. Apps distributed only outside any public store appear to fall outside the definition, but take advice before relying on that.
Out of scope under section 1798.504(f): broadband internet access, telecommunications services, and the delivery or use of a physical product. SDKs that are not stand-alone store apps, and extension or plug-in marketplaces, also fall outside, as the table shows.
What developers must do, clause by clause
The developer duties sit in Civil Code section 1798.501(d) and (e), with the transition rule in section 1798.502(b). In plain terms:
- Request a signal at download and launch. Under (d)(1)(A), you must ask the OS provider or a covered store for a signal about a particular user when the app is downloaded onto, and launched from, a particular device.
- Treat it as actual knowledge. Under (d)(2)(A), once you receive a signal you are deemed to know the user's age range, even if you ignore it. That extends to any platform of the app where the user can create an account, including your website, and any point of access, including web logins from the same device.
- Use it as the primary indicator. Under (d)(3), the signal is your primary evidence of age unless you hold internal clear and convincing information that the age is different. That information then becomes the primary indicator, and you are deemed to know that age instead. Age details an account holder gives for a sub-account count. Under (d)(2)(B), you cannot wilfully disregard such records.
- Collect the minimum. Under (d)(4)(A), do not request more from the OS or store than the Act needs.
- Do not share the signal. Under (d)(4)(B), do not pass it to a third party for a purpose the Act itself does not require. We read that as ruling out ad networks, attribution SDKs and analytics vendors.
- Do not nudge users to change their age. Under (d)(1)(B), no entity subject to the Act may prompt a user to change age information.
- Do not over-request. Under (e), no person may request a signal unless the Act or another law requires it.
- Handle the installed base. Under section 1798.502(b), if your app was last updated on or after 1 January 2026, was downloaded before 1 January 2027, and you have not requested a signal for that user, request one before 1 July 2027.
Section 1798.504 reduces the load in three ways. You need not request a signal at every login after account creation, you may request one periodically, and the Act imposes no liability arising from use of a shared device or app by someone other than the user the signal describes.
The safe harbour is in section 1798.503(c). A developer that makes a good-faith effort to comply, considering available technology and reasonable technical limits or outages, is not liable for an erroneous signal or for the OS's conduct. Document your integration and failure handling so you can show that effort.
What the signal triggers under other laws
The Act does not tell you to block minors or build parental consent flows. Section 1798.501(d)(4) tells you to use the signal to comply with applicable law, and three sets of rules matter most.
The CCPA. Under Civil Code section 1798.120(c), a business may not sell or share the personal information of a consumer it actually knows is under 16 without opt-in authorisation: from the consumer if aged 13 to 15, or from a parent if under 13. CCPA regulation section 7001(bbb)(4) also classes personal information of consumers known to be under 16 as sensitive. So a 13 to 15 signal means your ad SDKs, data sales and cross-context behavioural advertising for that user need an opt-in path or must switch off.
COPPA. An under-13 signal brings federal COPPA obligations into view for many apps.
California's 2026 children's bills. Both were chaptered on the day AB 1856 was. AB 1709 (Chapter 183) bars covered platforms from giving addictive features such as algorithmic feeds and autoplay to under-16s, and requires them to verify age under the Act first. Penalties reach $50,000 per affected minor for a knowing violation and $25,000 for a negligent one, and the Attorney General may adopt regulations. AB 2246 (Chapter 187) replaces the Age-Appropriate Design Code. Its new section 1798.99.29 tells businesses whose services are likely to be accessed by children to estimate age under section 1798.501(b), or give every consumer the child protections. That cross-reference matches the 2025 layout: since AB 1856, subdivision (b) concerns OS providers and developer duties sit in (d). Ask counsel how to read it.
Apple Declared Age Range vs Google Play Age Signals
Both platform owners are OS providers and store operators, and both already ship age APIs built for other age laws. Treat the table as what exists today, not as confirmed compliance with the Act.
| Item | Apple Declared Age Range | Google Play Age Signals (beta) |
|---|---|---|
| Availability | iOS, iPadOS, macOS and Mac Catalyst 26.0; all regulatory features need the 26.2 SDK or later | Library version 0.0.4; Android 6.0 or later; only apps updated by Google Play |
| Setup | Add the com.apple.developer.declared-age-range entitlement | Request API access, call requestAgeSignalsAccess, then checkAgeSignals |
| Age brackets | Up to 3 age gates; 13, 16 and 18 mirror the Act, but the system may override them in regulated regions | Default ranges 0-12, 13-15, 16-17, 18+; custom minimum ages replace them |
| Whose age | Person signed in to iCloud; parents choose always share, ask each time or never share for Family Sharing children | Play account user; guardian-managed age for supervised accounts |
| How age was set | Declaration type: self, guardian, or confirmed by a method such as credit card or government ID | ageRangeSource TIER_A (self-declared) to TIER_D (government ID plus selfie, or digital ID) |
| Region check | isEligibleForAgeFeatures and requiredRegulatoryFeatures | VERIFICATION_REQUIRED where sharing is mandatory and age is unknown; elsewhere the user or parent chooses |
| Named so far | New accounts: Utah from 6 May 2026, Texas from 4 June 2026, Louisiana from 1 July 2026; Brazil age categories | July 2026 docs: Brazil from 17 March 2026, eligible Texas accounts created after 28 May 2026; both dates still appear on Google's Android docs |
| Use limits | Compliance with laws is the developer's responsibility | Terms ban use for advertising, marketing, user profiling or analytics |
| Testing | Sandbox cases for under 13, 13-15, 16-17 and 18+ | FakeAgeSignalsManager test class |
Three Apple details affect logic. The system caches responses, so when a child turns 13 the API keeps returning the old range until the anniversary of the original declaration, unless the person updates it in settings. Outside regulated regions people can decline, which returns declinedSharing. On macOS, isEligibleForAgeFeatures returns false because the system does not require age assurance. Separately, Apple's June 2026 Time Allowances notice requires apps that declare social media features but disable them for under-13s to use the API at a minimum. Our App Store age assurance readiness guide covers that route.
On Android, Google advises calling the Play Integrity API alongside Play Age Signals so a tampered app cannot spoof the response. Its help page says signals can be retrieved while the app is open, which fits a first-launch request. It also says Texas SB 2420 is now in effect after a federal appeals court stayed the December 2025 injunction, and that similar state laws are coming. Sharing defaults to asking the user, and is locked to always share in regions that require it.
Build one internal age-signal service that can talk to both APIs, map their responses to the four statutory brackets, and record which source answered. If Apple or Google publish California behaviour in December, you change configuration, not architecture.
Penalty exposure: a worked example
Penalties apply per affected child for each violation, so exposure scales with your under-18 audience, not your total user count. Take a hypothetical fitness app with 40,000 California installs, of which 1,200 belong to users under 18. Assume no signal request shipped.
- One negligent violation per affected child: 1,200 x $2,500 = $3,000,000.
- One intentional violation per affected child: 1,200 x $7,500 = $9,000,000.
These are statutory maximums for one violation per child, not a ceiling, because the text charges each violation and no court has yet counted them. Only the Attorney General can recover them, in a civil action that can also seek an injunction.
The legacy deadline matters too. If those 40,000 installs predate 2027 and the app was last updated on or after 1 January 2026, each needs a signal request before 1 July 2027. From 1 January to 30 June 2027 is 181 days, so 40,000 / 181 is about 221 requests a day if spread evenly. A normal launch-time check handles that without a backfill job, though it cannot reach installs that never launch in the window, so log that gap.
Developer checklist for 1 January 2027
- Confirm scope. List every app you own or host in a covered store, including white-label builds and companion apps.
- Read the chaptered text. Use the AB 1856 version of Civil Code sections 1798.500 to 1798.504, plus section 1798.505, not 2025 summaries.
- Build the age-signal service. Normalise both APIs to the four brackets and record the source and timestamp.
- Trigger on first launch after install. Request the signal on the first launch of each install, and on first launch after an update for pre-2027 installs until 1 July 2027.
- Design failure states. Decide what the app does when the API is unavailable, the OS is too old to offer it, no signal returns, or the user or parent declines. Plan a route for apps on other Android stores, since Google's API serves only apps updated by Play. Log each outcome for your good-faith record.
- Propagate actual knowledge. If a signal arrives in the app, flag the account so your website and other clients apply the same age treatment.
- Reconcile internal data. Where your records clearly show a different age, such as a parent-set child profile, make that the primary indicator and document why.
- Quarantine the bracket. Keep the signal out of analytics events, ad SDK parameters, attribution payloads and warehouse exports. Pass on decisions derived from it, not the signal.
- Remove age-change prompts. Delete any UX that asks users to re-enter or raise their age after a signal arrives.
- Map brackets to obligations. With counsel, map each bracket to CCPA sale and share rules, sensitive-data handling, COPPA, AB 1709, AB 2246 and any content rules you choose to apply.
- Update disclosures. Refresh your privacy policy, App Store privacy labels and Google Play data safety form.
- Test with platform tools. Use Apple's sandbox cases and Google's FakeAgeSignalsManager to cover all four brackets plus decline and error paths.
- Watch for platform notices. Track Apple developer news and Google's Play Console help page for California instructions in December 2026.
Other states, Brazil and India: one architecture, several rulebooks
California's model differs from other states'. Texas (SB 2420), Utah (SB 142) and Louisiana (HB 570) make app stores verify age and get parental consent for minors' downloads and purchases. California instead creates device-level age infrastructure for every app and leaves content rules to other laws. Apple and Google also return age data in Brazil, where Google cites the Digital ECA. The same January date brings California's ADMT rules, a separate job for teams using automated decisions.
For Indian teams shipping apps to US stores, the obligation follows your California users, not your office address. The engineering overlaps with India's own rules: the DPDP Act treats under-18s as children and requires verifiable parental consent, so one age-signal service with jurisdiction-aware policies can serve both. Our DPDP Act engineering playbook covers the India side.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our AI and mobile application development services team can audit where age data flows today, build a shared age-signal service across Apple and Google APIs, and prepare test evidence for your legal team. Talk to us at /contact-us/.
Last updated: 2 November 2026.
