AB 1043 existing installs: what app developers must do before July 1, 2027
Most AB 1043 coverage is about January 1, 2027. The law has a second date: July 1, 2027, for people who installed your app before 2027. If you shipped any update this year, it probably applies to you.
What the statute says
Civil Code 1798.502(b), in full: "If an application last updated with updates on or after January 1, 2026, was downloaded to a device before January 1, 2027, and the developer has not requested a signal with respect to the user of the device on which the application was downloaded, the developer shall request a signal from a covered application store with respect to that user before July 1, 2027."
Three conditions, all of which must be true for a given user:
- Your app was last updated on or after January 1, 2026. Any release this year counts, including bug fixes.
- The user downloaded it before January 1, 2027.
- You haven't already requested a signal for that user. Once your regular launch-time request (1798.501(b)(1)) has run for them, this duty is met.
Two details are easy to miss. First, 1798.502(b) says to request the signal "from a covered application store," while the general rule in 1798.501(b)(1) allows "an operating system provider or a covered application store." Second, operating system providers get the same deadline: for devices set up before 2027 they must offer an age-entry interface before July 1, 2027 (1798.502(a)). So for some older devices a signal may not exist until shortly before your deadline.
Who is in scope
| Your situation | 1798.502(b) |
|---|---|
| Shipped an update in 2026; users installed in 2025 or 2026 | Applies to those users |
| No update since December 31, 2025 | The "last updated on or after January 1, 2026" condition isn't met while that stays true. Your next update changes that |
| User installs on or after January 1, 2027 | Covered by the general download-and-launch rule instead |
| Your launch-time request already ran for the user | Already requested; record when |
The simplest way to comply: request on every launch, for everyone
You don't need to work out who installed when if the release that adds the AB 1043 request asks on launch for every user who hasn't been asked yet. A user who opens your app in the first half of 2027 gets the request either way. In practice:
- Ship the request before January 1, 2027, or as soon as you can. Apple's Declared Age Range is on iOS 26 and later (Apple says to build against the iOS 26.2 SDK for all age-assurance features), and Google's Play Age Signals SDK is at 0.0.4 (beta). Our developer guide has the calls.
- Store a "requested" marker per user or install: when you asked, the app version, and the outcome (signal received, declined, unavailable). That marker is how you show condition 3 for each user.
- Raise the minimum supported version over time, so users stuck on builds without the request are prompted to update before July 1, 2027.
- Watch adoption: the share of active users on a version that requests the signal, by month.
If you do want install dates for reporting, Android's PackageInfo.firstInstallTime gives the install time on the device (it resets on reinstall), and on iOS StoreKit's AppTransaction includes the original purchase date. Neither is needed if you request for everyone.
The platform catch
As of October 27, 2026, neither Apple nor Google has announced a California-specific date for returning AB 1043 signals. Google's Play Age Signals API says it returns signals for users in Brazil and for eligible Texas accounts created after May 28, 2026, with "ongoing updates ... in advance of age verification bills in other US states." Apple's announcements cover Texas, Utah, Louisiana, Brazil, Australia and Singapore. Your request may return "not shared," "verification required" or "unavailable" for a while. Make the request anyway, record the outcome, and re-request on a later launch.
Questions to put to counsel
- Users who never open the app between your release and July 1, 2027: an in-app request can't run for them.
- Whether your first-launch-after-update request satisfies 1798.502(b) for users whose earlier request returned "unavailable."
- How long to keep the "requested" records, especially if you also distribute in Texas, where SB 2420 requires deleting store-provided age data once verification is complete (Bus. & Com. Code 121.055(b)).
What to record
| Record | Example |
|---|---|
| Release that adds the request for existing users | v4.12.0, shipped December 9, 2026 |
| Launch point | First launch after update, before sign-in |
| Per-user marker | requested_at, app_version, outcome |
| Adoption by month | Share of monthly active users on v4.12.0 or later |
| Minimum-version plan | Force update below v4.12.0 from May 1, 2027 |
The penalties are the same as for the rest of the title: up to $2,500 per affected child per negligent violation and $7,500 per intentional violation, in actions by the California Attorney General (1798.503(a)). See the AB 1043 compliance checklist for the other records to keep.
Written by AI agents for Age Signal Ready and checked against the sources below on October 27, 2026. General information, not legal advice. Spotted an error? Email hello@agesignalready.com.
Sources
- California Civil Code 1798.500-1798.505 (official text)
- Apple: Age assurance frameworks Q&A
- Android: Request age signals (Play Age Signals)
- Android: PackageInfo.firstInstallTime
- Apple: AppTransaction
- Texas SB 2420 enrolled text (Bus. & Com. Code ch. 121)
Need the paper trail, not just the API call? The Age Signal Ready kit adds a fill-in AB 1043 decision log, data-minimization and privacy-policy text, documented edge cases, and launch-time wiring for iOS, Android, Expo and Flutter. $99 pre-order, delivered by email by December 1, 2026, or an automatic full refund.