iOS Age Verification: How Apple's Declared Age Range Works

Last updated: 2026-10-03

Apple's Declared Age Range API, the DeclaredAgeRange framework available from iOS 26.0, is how an iPhone, iPad or Mac app asks the operating system for a user's age range. Since June 4, 2026, Apple has shared age categories through it for new Apple Accounts in Texas under SB 2420. From January 1, 2027, California's Digital Age Assurance Act deems a developer that receives the signal "to have actual knowledge of the age range of the user". The app receives, as a value inside its process, a range relative to its own age gates, a declaration type (which records whether a card or ID confirmed the age) and parental-control flags. Apple keeps the birthday.

For Android, see the Play Age Signals explainer; state duties, dates and penalties are in our post on app store age verification laws.

What is Apple's Declared Age Range API?

Declared Age Range is a system framework that returns an age range for "the person signed in to iCloud on the device". An app gets access through the com.apple.developer.declared-age-range entitlement, a Boolean that Xcode adds with the Declared Age Range capability. From Apple's framework documentation:

Data from the Declared Age Range API is based on information declared by an end user, or their parent or guardian, and may be confirmed using a payment method (like a credit card), government ID, or another method.

Apple Support article 122770 (published September 14, 2026) states: "Your birthday determines this age range." Apple's age assurance Q&A states the API "is available worldwide". Apple's February 2025 paper Helping Protect Kids Online states the feature "won't provide kids' actual birthdates", and "Requiring age verification at the app marketplace level is not data minimization."

Which laws make Apple share an age range, and from when?

Texas may enforce SB 2420 during the appeal: the Fifth Circuit stayed the injunction pending appeal on June 4, 2026 (No. 25-51073), and the Supreme Court denied the application to vacate that stay on July 6, 2026 (25A1389). The appeal on the merits is pending. California, Utah and Louisiana follow in 2027.

On October 8, 2025, Apple told developers it was "concerned that SB2420 impacts the privacy of users". Apple's November 4, 2025 notice gives the Texas categories as "under 13, 13-15, 16-17, or over 18". After the district court enjoined the law, Apple paused its Texas plans on December 23, 2025. The panel had stayed the injunction administratively on May 28, 2026 (per the challengers' Supreme Court application). Apple's June 3 notice cites "a recent court ruling lifting an injunction" and applies the changes to new Texas accounts "starting June 4, 2026".

Apple's February 24, 2026 notice set account start dates of May 6, 2026 for Utah and July 1, 2026 for Louisiana. Utah's HB 498 and Louisiana's Act 185 have since moved them to May 6, 2027 and July 1, 2027. Apple's developer news has no later notice for either state, so whether Apple changed those account flows is open; a new Utah test account would settle it.

Under California's act, from January 1, 2027, a developer that receives a signal is deemed to know the range "even if the developer willfully disregards the signal" (Civ. Code 1798.501(d)(2)(A)), may not "Share the signal with a third party for a purpose not required by this title" (1798.501(d)(4)(B)), and the Attorney General can seek up to $2,500 per affected child for a negligent violation and $7,500 for an intentional one (1798.503(a)).

How does an iPhone app ask for an age range?

The app calls AgeRangeService.shared.requestAgeRange(ageGates:_:_:in:) in UIKit, or the requestAgeRange environment action in SwiftUI. From Apple's guide: "You can specify up to three age gates, which create up to four possible age ranges. Each range must be at least two years in duration."

Two properties report whether a law applies. isEligibleForAgeFeatures (iOS 26.2) returns true "when your app needs to support age assurance for the current user". requiredRegulatoryFeatures (iOS 26.4) returns a set of RegulatoryFeature values: declaredAgeRangeRequired, significantAppChangeRequiresParentalConsent and significantAppChangeRequiresAdultNotification. In some regulated regions, Apple's guide states, "the system automatically provides the person's age range", "they can't decline sharing", and the region's age gates may replace the ones the app passed.

Per the Q&A, "Existing Apple Accounts running iOS 18 and iPadOS 18, or earlier" are unaffected, and an app rated 18+ still calls the API "In regions where legally required".

What does the app receive, and what does Apple keep?

The response is .sharing(range:) or, in regions where Apple's guide lets the user decline, .declinedSharing.

confirmed means the range "was set using a scrutinized method, like a credit card or government ID".

Apple's guide states: "The system protects privacy by caching age range responses." When a user crosses into a new range, "the API continues returning the previous range until the anniversary of their original declaration." Whether caching also stops an app from probing with changing gates is untested; two gate sets on one account would show it.

How do parental consent and revocation work?

For a child, the app asks the parent to approve a "significant change", which the developer defines: it wraps a description in PermissionKit's SignificantAppUpdateTopic (iOS 26.2) and sends it as a PermissionQuestion, as Apple's sample code shows. For an adult where notice is required, showSignificantUpdateAcknowledgment(in:updateDescription:) (iOS 26.4) shows a system sheet. Texas treats a change in an app's age rating as significant (section 121.053(b)), and StoreKit's AppStore.ageRatingCode returns the current rating so the app can detect the change.

When a parent withdraws consent, "Apple will prevent the app from launching" (Q&A). The developer's server receives an App Store Server Notification of type RESCIND_CONSENT. Apple documents every version 2 notification as a JWS signedPayload whose signature the server can validate; a captured sandbox RESCIND_CONSENT notification would confirm this type uses that format.

Is the age range safe? Can it be faked or read by an SDK?

On privacy, Apple keeps the birthday and the app receives only the rows marked Yes in the table above. On security, Apple documents no signed token for the range, and two attacks are untested on a device: faking the value and an SDK requesting it.

First, requestAgeRange returns a Swift value inside the app's process, and Apple documents no server endpoint that returns the range, so a server that receives the range from the app trusts the client. On a jailbroken device, or in a re-signed build instrumented with Frida, a hook on requestAgeRange or on the AgeRange getters could return any value; a hook on a test device would establish it.

Second, the entitlement is granted to the app, and every framework linked into it runs in its process under its signature, so a third-party SDK could call AgeRangeService.shared.requestAgeRange and receive the result. A test build, or a shipped SDK framework that imports the requestAgeRange symbol, would establish it. Outside regions with automatic sharing, the call shows the user a sheet.

The Apple Developer Program License Agreement, section 3.3.3(O), allows use "only for the purposes of providing age-appropriate content and/or features for end users in Your Application, or to comply with laws that require Your Application to receive age range information", and states: "You may not share or sell user data obtained from this API to data brokers or information resellers." From January 1, 2027, California adds 1798.501(d)(4)(B) on third-party sharing and 1798.501(e): a person "shall not request a signal" unless the title or another law requires it.

How can an app get around the signal, and what happens if it does?

An app can skip the call, sign users up on a website, which bypasses the store flow, or ship through an EU or Brazilian alternative marketplace. Exposure falls under state law, the COPPA Rule, the CCPA and, for misuse, Apple's developer agreement.

Skipping the call. Apple's Q&A states "there are no changes to the App Review process". In Texas, "A violation of this chapter constitutes a deceptive trade practice" (section 121.101). Utah's private action, from May 6, 2027, covers violations of section 13-76-202(4), which bars a developer from enforcing its terms against a minor without verifying parental consent through the store and from sharing "age category data with any person", with the greater of actual damages or "$1,000 for each violation". A search on October 3, 2026 found no state enforcement action that treats not calling the API as a violation.

Web sign-up. California's deemed knowledge covers "Any platform of an application, including an internet website owned, maintained, or controlled by a developer, through which the user may create an account" once the developer has received a signal (1798.501(d)(2)(A)(i)). COPPA applies to an operator "that has actual knowledge that it is collecting or maintaining personal information from a child", and CCPA section 1798.120(c) requires opt-in before selling or sharing data of a consumer the business knows is under 16. Whether a received range is actual knowledge under COPPA is open; no case was found.

Alternative distribution. In the EU, apps can be installed from alternative marketplaces or a developer's website, and notarization "applies to all apps, regardless of their distribution channel". In Brazil, alternative marketplaces open from iOS 26.5, with "requirements that help protect children from inappropriate content and scams". Whether the API returns a range for such installs is open; Apple's age assurance pages name neither channel, and a test install from an EU or Brazil marketplace would settle it.

License breach. Section 3.3.3(O) names no remedy of its own; section 11.2 lets Apple terminate the agreement for a breach not cured within 30 days.

How can a user see which apps received the age range?

Settings > [name] > Personal Information > Age Range for Apps. Per Support 122770, each app that asked is listed with "Shared" or "Not Shared", and its detail page gives the last request date. The page also states: "In some states, countries, or regions, age range is always shared with developers."

What do a CanITrustThat scan and a traffic capture show?

An iOS build that uses the API contains a load command for /System/Library/Frameworks/DeclaredAgeRange.framework/DeclaredAgeRange (the install name in Apple's iOS 26.1 SDK; a weak link lets the app run before iOS 26), the com.apple.developer.declared-age-range entitlement in the code signature, and imported Swift symbols with the prefix $s16DeclaredAgeRange, such as the one that decodes to AgeRangeService.requestAgeRange(ageGates:_:_:in:). CITT's iOS extractor records the linked libraries, external symbols and entitlements of the main binary and each embedded SDK framework separately; a statically linked SDK counts as main-binary code. Imports of PermissionKit and StoreKit's ageRatingCode are the consent-flow artifacts. The mangled names of symbols added after iOS 26.1 (requiredRegulatoryFeatures, confirmed, SignificantAppUpdateTopic, ageRatingCode) still need checking against an iOS 26.4 or later SDK. Presence shows the code is in the build; whether the call runs, which gates it passes and what happens to the result take a runtime test or a capture.

The range is delivered on the device, so a capture shows what the app and its SDKs send afterward: age fields in the app's own API calls, analytics user properties, and regs.coppa, user.yob and device.ifa in OpenRTB bid requests. Linking a sent value to Declared Age Range takes the binary evidence plus matching timing and values across an adult and a child account. The methodology sets out what a scan checks and the limits of a scan. Scanned apps are listed in the app index, and I can run a list of iOS apps through this extraction in bulk ahead of January 1, 2027. Sign up for a CanITrustThat (CITT) account to run your own research, or let us run an investigation for you.