What AB 1043 actually requires

AB 1043 requires operating-system providers -- practically speaking, Apple and Google -- to build an age-signal-sharing mechanism. App developers who request and receive that signal are then required to use it to provide age-appropriate experiences. If you've read anything about Apple's Declared Age Range API or Google's Play Age Signals API already, the developer-facing mechanic here -- request a signal, act on it -- will look familiar, because it's functionally similar to what those APIs already do for the Texas/Utah/Louisiana laws.

What's genuinely different is the legal basis. AB 1043 is a data-privacy-style statute enforced through California's Attorney General and its existing consumer-protection apparatus, not a deceptive-trade-practices statute layered onto app-store operation the way Texas's SB 2420 is. Don't assume that satisfying the Texas/Utah/Louisiana requirement automatically satisfies AB 1043 -- the API call may end up looking similar, but the statute you're actually complying with, and the enforcement channel behind it, is not the same one.

The timeline: operative January 1, 2027, grace to July 1, 2027

AB 1043 was signed and chaptered on October 13, 2025. It becomes operative on January 1, 2027. A grace period extends that to July 1, 2027, but only for two specific situations, and it's worth reading them as a real test rather than a blanket six-month extension:

  • Devices and accounts where setup completed before January 1, 2027. If a user's device or account was already set up before the operative date, you get the extra six months on that user.
  • Apps last updated on or after January 1, 2026, for users whose devices received the app before the operative date. This is the one worth reading twice: the grace period for those pre-existing installs depends on your app's own update history, specifically whether you shipped an update on or after January 1, 2026. Developers who genuinely don't know their last shipped update date relative to that threshold should check their App Store Connect / Play Console release history now, not in December 2026.

Why the "last updated" test matters more than it looks like it does

Most compliance deadlines are pure calendar dates: everyone hits the same date, no matter what they did before it. AB 1043's grace period isn't purely a calendar date for the pre-existing-install case -- it's conditioned on your own release history. Two developers with functionally identical apps and identical California user bases can land in different grace-period buckets purely because one of them shipped a routine update in, say, November 2025 and the other shipped one in February 2026. If you maintain an app with a slow release cadence, or one that's effectively in maintenance-only mode, this is a genuine reason to check your actual last-update date against the January 1, 2026 threshold now, rather than assuming the grace period automatically covers you.

Don't reuse your Texas/Utah/Louisiana compliance work without checking

The build shape looks similar -- request an age signal from the platform, act on the result -- and for many teams the underlying API call (Apple's Declared Age Range API, Google's Play Age Signals API) genuinely will be shared infrastructure. But "the API call is shared" is not the same claim as "the compliance obligation is satisfied." AB 1043 is a separate statute with its own operative date, its own grace-period test, and its own enforcement channel (California AG / consumer-protection, not DTPA-style). Verify the mapping explicitly rather than assuming 1:1 coverage from your other-state build.

What to check now

  • Confirm you have California users. If you distribute nationally, you almost certainly do.
  • Find your app's actual last-update date and check it against January 1, 2026 -- this determines your grace-period bucket for pre-existing installs, per the mechanic above.
  • Don't assume your Texas/Utah/Louisiana API integration automatically satisfies AB 1043. The developer-facing call may be reusable; the compliance obligation is a separate statute. Confirm rather than assume.
  • Build toward January 1, 2027, not July 1, 2027. The grace period is narrow and conditional, not a blanket six-month delay for everyone -- treat the earlier date as your real target.
  • For the actual Apple/Google API mechanics once you know you need them, see our companion guide comparing the Declared Age Range API and Play Age Signals API.

How to re-verify this yourself

Do this before you rely on any date here for a real compliance decision, and repeat it roughly every 60–90 days while the operative date is still in the future:

  1. Check the California Legislature's own bill page for AB 1043 (bill number 202520260AB1043 on leginfo.legislature.ca.gov) directly, not just a law-firm summary of it -- the bill page is the actual primary source for the current, controlling date.
  2. Search "AB 1043" amendment 2026 or 2027 -- both Utah's and Louisiana's ASAA deadlines moved by amendment after this kind of law was originally enacted; that pattern is worth checking for AB 1043 too, even though no such amendment has surfaced as of this writing.
  3. Cross-check Apple's and Google's own developer-news pages against the date you just found -- our companion state-by-state guide documents a real case where Apple's own page ran months out of date on a different state's deadline. Don't assume platform documentation and state law are synchronized.
  4. Note the publish date of anything you read, including this article. A compliance date sourced from an undated blog post is not verified -- it's a guess with a citation attached.

Sources checked directly for this article: the California Legislature's own bill page for AB 1043 (leginfo.legislature.ca.gov, bill 202520260AB1043); cross-checked against the IEEE Standards Association's summary and Alston & Bird's "California Enacts Digital Age Verification Law."