AB 1043 for app developers: what to call on iOS, Android, Expo and Flutter
From January 1, 2027, California's Digital Age Assurance Act (AB 1043, Civil Code 1798.500-1798.505) requires app developers to ask the operating system or app store for a user's age bracket. Apple, Google and Expo already ship the APIs. Here's what the law asks for and how it maps to each platform.
What the statute requires of developers
- Request a signal. "A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched." (1798.501(b)(1))
- Four brackets at minimum: under 13; 13 to under 16; 16 to under 18; 18 and over. (1798.500(b), 1798.501(a)(2))
- Actual knowledge. Once you receive a signal you're "deemed to have actual knowledge of the age range of the user ... across all platforms of the application and points of access," even if you willfully disregard it. (1798.501(b)(2)(A))
- Primary indicator. Treat the signal as the primary indicator of age, unless you have "internal clear and convincing information" that the age is different; then use that. (1798.501(b)(3))
- Minimization. Don't request more than the minimum needed, and don't share the signal with a third party for a purpose the title doesn't require. (1798.501(b)(4))
- Existing installs. If your app was updated on or after January 1, 2026 and downloaded before January 1, 2027, request a signal for that user before July 1, 2027. (1798.502(b)) See the existing-installs guide.
- Penalties. Up to $2,500 per affected child for each negligent violation and $7,500 per affected child for each intentional one, in a civil action by the Attorney General only. (1798.503(a))
iOS: Declared Age Range
Apple's Declared Age Range API (iOS 26+) returns an age range when the person or their guardian shares it. Apple says that to use all its age assurance features you must build against the iOS 26.2 SDK or later with Xcode 26.2. iOS 26.2 adds isEligibleForAgeFeatures and the method used to confirm the age; iOS 26.4 adds requiredRegulatoryFeatures and significant-update acknowledgements. The app needs the com.apple.developer.declared-age-range entitlement, and Apple provides Sandbox testing from iOS 26.2.
let r = try await AgeRangeService.shared
.requestAgeRange(ageGates: 13, 16, 18, in: window)
// .sharing(range:) or .declinedSharing: log either outcome
Gates at 13, 16 and 18 line up with the statute's four brackets. Apple notes that developers remain responsible for their own age restrictions.
Android: Play Age Signals
Google's Play Age Signals SDK (0.0.4) uses two calls. requestAgeSignalsAccess(Activity) returns SHARED, NOT_SHARED or VERIFICATION_REQUIRED; only on SHARED do you call checkAgeSignals(), which returns ageLower, ageUpper, ageRangeSource and an installId. In US states whose laws require app stores to share verified age, Google says the in-app prompt isn't shown; unverified users get VERIFICATION_REQUIRED and must resolve it in the Play Store.
React Native / Expo: expo-age-range
Expo's open-source expo-age-range wraps both. On Android call requestAgeSignalsAccessAsync() first and continue only on 'SHARED'; then requestAgeRangeAsync({ threshold1: 13, threshold2: 16, threshold3: 18 }). One trap from Expo's docs: on platforms where the API isn't supported (earlier than iOS 26, and web) the call returns lowerBound: 18, "equivalent to the response of an adult user." Don't record that as a signal.
Flutter
Neither Apple nor Google publishes a Flutter plugin for these APIs. Call the native APIs through a platform channel, or vet a community plugin's source before relying on it for compliance.
Edge cases to decide and write down
| Case | What happens | Decide |
|---|---|---|
| User declines (iOS) | declinedSharing / ERR_AGE_RANGE_USER_DECLINED | Default gating; when to ask again |
| Not available | e.g. not signed in to an Apple Account | Retry on next launch; log it |
| Android not shared | NOT_SHARED | Default gating |
| Verification required | VERIFICATION_REQUIRED | Point the user to the Play Store; gate meanwhile |
| Old OS or web | Expo returns lowerBound: 18 | Treat as "no signal", not as adult |
| Your data disagrees | 1798.501(b)(3)(B) | What counts as "clear and convincing" for you |
The signal must not flow to third-party SDKs for purposes the law doesn't require. Review your analytics and ads SDKs. See the AB 1043 compliance checklist for what to document.
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)
- AB 1043 bill page
- Apple: Age assurance frameworks Q&A
- Android: Request age signals (Play Age Signals)
- Expo: expo-age-range
- Flutter: platform channels
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.