The Implementing age assurance and permissions sample code is available for download. The sample demonstrates how to create a significant change flow to inform people about important updates in your app and request age-related permissions. It supports iOS 26.5 or later.

Hello Apple Developer Support Team, We understand from the Declared Age Range documentation that, in some regulated regions, the system automatically provides the person’s age range and they can’t decline sharing it with the app. We have implemented the API as prescribed in the documentation. For certain users in Texas, the API returns: isEligibleForAgeFeatures == true declaredAgeRangeRequired == true However, in our testing we observe that these Texas users can still decline sharing their age range, either via the system prompt or later via Settings, which results in no age range being provided to the app. This behavior appears inconsistent with the documentation’s statement that, in regulated regions, the person “can’t decline” sharing their age range, and it also raises questions for us about how this aligns with the applicable legal requirements in Texas. Could you please clarify: Whether this behavior (Texas users being able to decline sharing their age range even when declaredAgeRangeRequired is true) is expected, and Under what exact conditions the “they can’t decline sharing” behavior is enforced for Texas accounts (for example, only for new Apple Accounts created in Texas after a certain date, or only for particular age categories)? Any guidance on how we should interpret isEligibleForAgeFeatures and declaredAgeRangeRequired in this scenario would be greatly appreciated. Thank you.

Hi, I have two questions: Is there any way to test the revoke consent flow on a local build of our app? When I try using Sandbox to "Revoke App Consent" with the application bundle ID of a locally built and deployed app, it fails with "Cannot Trigger Notification. The bundle ID you provided is invalid or you do not have access to the app." https://developer.apple.com/support/age-assurance/#responsibility states that "When a parent or guardian revokes consent for their child to access an app, Apple will prevent the app from launching." However, when using the Sandbox to revoke app consent, the app is still launchable. Does anyone know if the app being launchable is exclusive to Sandbox, and how this works in prouduction?

Hello, Quick clarification regarding age ratings: If a user is 17 years old and wants to download a 16+ app, is parental approval required? Or is parental consent only needed if the app’s rating does not match (or exceeds) the user’s actual age? Also, is this fully enforced by Apple, or is it up to developers how to implement these checks? Thanks!

https://developer.apple.com/documentation/DeclaredAgeRange/AgeRangeService/isEligibleForAgeFeatures returns a bool. I assume that means that it will return True for the states where their laws are in effect. The TX law and the UT/LA/AZ laws have different requirements though: TX requires the app verify the user's age on every app launch. These other states require the app verify the user's age "no more than once during each 12-month period" A future law (Brazil maybe?) might do something else. How can we determine if the user is eligible for the TX versus other state requirements?

Hello Apple Developer Team, I'm implementing the DeclaredAgeRange framework to support age assurance requirements related to Texas SB 2420. After reading the documentation for: AgeRangeService.shared.isEligibleForAgeFeatures I noticed the discussion states: "Check whether the person using your app is in a region that requires Age Assurance." My understanding is that isEligibleForAgeFeatures uses the user's location and account settings internally to determine whether age assurance requirements apply. However, I am unclear about the expected implementation flow. My questions are: Should developers manually determine whether a user is located in Texas (for example using Core Location, IP-based geolocation, or other methods) before calling requestAgeRange()? Or is Apple recommending that developers simply call: let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures and rely entirely on the framework to determine whether Texas age assurance requirements apply? If a user is located in Texas and age assurance is required, will isEligibleForAgeFeatures reliably return true without the app needing any location permission? Is there any supported API that allows developers to know which specific region/state triggered the age assurance requirement, or should developers treat isEligibleForAgeFeatures == true as the only signal needed? My goal is to implement the framework according to Apple's intended design while avoiding unnecessary collection of location data. Thank you for any clarification.

Hello, While reviewing the latest FAQ and documentation for the Declared Age Range API, we have some questions regarding the behavior of checkEligibility()—specifically how it relates to user eligibility, geographic jurisdiction, and regulatory requirements. Context From the documentation, it appears that checkEligibility() indicates whether a user is eligible to share their declared age range. However, it is unclear whether this eligibility also incorporates jurisdiction-specific requirements (e.g., certain U.S. states with age assurance regulations). We would appreciate clarification on the following points: Eligibility vs Region: Does checkEligibility() return true based on the user’s eligibility to share age information only, or does it also depend on the user’s geographic region (e.g., specific U.S. states like Texas)? Region-Specific Laws (Texas Example): In scenarios where certain jurisdictions (such as Texas) require age assurance features, while other U.S. states may not, how does checkEligibility() behave? User Consent vs Regulatory Requirement: If a user denies age sharing, but they are located in a region where age-related regulatory features are mandated, how does checkEligibility() behave? Will it return false because the user denied consent? Or will it still return true due to regulatory requirements overriding user preference? Source of Region Determination: Does the Declared Age Range API internally determine the user’s applicable region (e.g., based on IP address, Apple ID region, or device settings) when evaluating checkEligibility()? Should developers independently determine jurisdiction (e.g., using IP-based geolocation) to apply region-specific rules, or is checkEligibility() intended to fully abstract both eligibility and jurisdiction requirements?

I’ve been using the Age Assurance support page and related Developer News posts as the source of truth for understanding Apple’s expectations around Age Assurance on Apple platforms: https://developer.apple.com/support/age-assurance/ https://developer.apple.com/news/?id=sg176nne Can anyone from Apple clarify whether anything has recently changed with App Review expectations related to Age Assurance? Specifically, are there any new requirements or updated guidance around implementing technologies like DeclaredAgeRange or PermissionKit? I didn’t see any sessions or announcements that indicated these frameworks are now required but with all of the new child safety announcements I thought I'd ask and document for the developer community. I did see the new sample code for implementing Age Assurance and permissions, but nothing suggesting their use is mandatory for App Store approval. https://developer.apple.com/documentation/declaredagerange/implementing-age-assurance-and-permissions Just trying to confirm whether current guidance remains the same, or if App Review expectations are evolving.

Hello, We are currently integrating the new Declared Age Range framework to comply with the age assurance requirements (such as the Texas regulatory rollout). We are specifically trying to test the AgeRangeService.RegulatoryFeature.significantAppChangeRequiresParentalConsent flow for minors. The Problem When testing in the Sandbox environment, the consent flow returns a mocked response immediately. While this validates our basic code logic, it does not allow us to test or see the actual end-to-end user experience/UI of the parental consent flow. When we attempt to test this outside of the Sandbox environment on a production build/device to see the true system UI, the AskCenter.ask(PermissionQuestion, in: ...) request fails immediately with the following error: Error: “The user is in a region that does not support this type of ask." UserInfo: {NSLocalizedDescription=The user is in a region that does not support this type of ask., NSLocalizedRecoverySuggestion=Please ensure the user is in an eligible region., NSLocalizedFailureReason=The user must be in a supported region to use this feature.} What We Have Tried Verified that our App Store Connect Sandbox account and test devices are configured correctly according to the "Testing Age Assurance in Sandbox" documentation. Attempted to change the region/location settings on our physical test devices to Texas/US to trigger the real flow, but the production environment still blocks it with the region error. Reviewed existing forum threads (such as 809889 and 809483) where other developers are facing the exact same roadblock without a clear solution. Our Questions Is there any supported way to trigger the full, unmocked system consent UI end-to-end during development/local testing? If changing the device's region settings isn't enough to bypass the production region check for AskCenter, how does Apple determine region eligibility for this specific API during local evaluation? Any insights, workarounds, or configuration steps to properly preview this UI before app submission would be greatly appreciated. Thank you!

Hi there, not sure anyone encountered the same situation, we rolled out our feature and we found that flag is all false for all the users in Brazil.. super weird.. anyone has any idea?

I have a question regarding parental control features within a region with age assurance regulations. The DeclaredAgeRange docs here suggests that age range can be "set" by the user or their parent or guardian: Check the ageRangeDeclaration to understand how the person or their parent or guardian set their age range. The declaration method indicates whether the age was self-declared, guardian-declared, or verified using a payment method, government ID, or another method. Based on this, I'm assuming the parent has the ability to override the user's real age (ex: 13 year old set to 18+?). Is that a correct assumption? Or do users that belong into a regulated region always return their true age for the purposes of Texas SB2420?

When the Age Verification framework validates a user based on both regulated region and age range, which location signal will the framework use for users in regulated regions? a.          The user's current physical location b.          The location associated with the user's Apple account c.          The billing or credit card location If multiple signals are available and inconsistent, what is the expected precedence order?   2. Can you provide a list of regions where age range is specified by default and regions where it is not? My app currently requests consent to share age range information during sign-in or sign-up, and the user's session remains active until sign-out. If a user was under 18 when the app was first installed and selected “decline to share,” but later turns 18 while remaining an active user, what is the recommended in-app approach for requesting age range information at that stage? Additionally, if parental consent is used to allow access for users under 18, how should the app determine when the user turns 18 and becomes eligible for direct age range collection? What are the exact requirements and limitations for receiving real (live) responses from the Declared Age Range API? Will these Age Verification rules/checks applied only to the new Apple Accounts or for existing users too?

The DeclaredAgeRange framework's 'actions' are not sendable. This means when the app is in swift 6 mode, the sample code provided in the documentation won't even compile due to the thread isolation. Is there any reason why the action closure in the environment can't be sendable? Otherwise @preconcurrency import for me. FB20959748

We're trying to implement proper age range verification in our app. However, one of my colleagues while testing AgeRangeService.shared.requestAgeRange got strange results and got stuck in this state. I wonder if this is a known bug and how can we deal with it. How many people may be affected? When he changed his birth date to be 17 years old the AgeRangeService.shared.requestAgeRange returned age range 13-15. When he changed back to his original birth date (1994) he still gets 13-15. He tried uninstalling the app, rebooting the system, nothing works. One thing that is different for his account than e.g. mine is that he's ageRangeDeclaration says .confirmed while mine is .selfDeclared. I read in the docs that "The system may override your age gates based on the local regulations of the person’s geographic location." but why on Earth would it think he's underage if he has this account for a really long time and is 30+?

Hello, I’m trying to clarify whether the new Age Range / Age Assurance Setup Assistant pane can be skipped on macOS when using a standard MDM Device Enrollment flow, not Automated Device Enrollment. Environment: Platform: macOS Tahoe 26.5.1 Enrollment type: MDM Device Enrollment, not ADE / DEP MDM: Microsoft Intune Profile deployment channel: Device profile Payload type: com.apple.SetupAssistant.managed Key used: SkipSetupItems Skip items tested: AgeAssurance AgeBasedSafetySettings The configuration profile installs successfully on the Mac as a device profile. I can confirm that the com.apple.SetupAssistant.managed payload is present on the device and includes the tested SkipSetupItems values. However, the Age Range / age-related Setup Assistant pane is still shown to the user. Example payload content: <dict> <key>PayloadType</key> <string>com.apple.SetupAssistant.managed</string> <key>PayloadIdentifier</key> <string>com.example.setupassistant.managed</string> <key>PayloadUUID</key> <string>REDACTED-UUID</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Managed Setup Assistant</string> <key>SkipSetupItems</key> <array> <string>AgeAssurance</string> <string>AgeBasedSafetySettings</string> </array> </dict> What I expected: When the com.apple.SetupAssistant.managed payload is installed as a device-level profile and includes the relevant age-related skip keys, the Age Range / Age Assurance pane should be skipped during Setup Assistant, or Apple documentation should state clearly that this pane can only be skipped in ADE. What actually happens: The profile installs, but the Age Range / age-related Setup Assistant pane still appears to the user on macOS 26.5.1. Documentation ambiguity: Apple’s Setup Assistant payload documentation says: The supported payload identifier is com.apple.SetupAssistant.managed Supported operating systems/channels include macOS device and macOS user Supported enrollment methods include User Enrollment, Device Enrollment, and Automated Device Enrollment SkipSetupItems is a list of Setup Assistant panes that can be skipped Apple’s macOS Tahoe 26 enterprise notes say: “The new Age Range setup pane is automatically skipped for devices using Automated Device Enrollment.” That wording clearly mentions ADE, but I have not found documentation that explicitly states whether the Age Range pane is intentionally unsupported for non-ADE macOS MDM enrollment, or whether there is a separate skip key required for macOS. Third-party MDM/tooling documentation appears to reference the following newer skip keys: AgeAssurance AgeBasedSafetySettings However, it is unclear whether those keys are supported on macOS, iOS/iPadOS only, ADE only, or all MDM enrollment methods. Questions: Are AgeAssurance and AgeBasedSafetySettings valid SkipSetupItems values on macOS 26.5.1? If yes, are they supported only during Automated Device Enrollment, or should they also work with standard MDM Device Enrollment? If these keys are iOS/iPadOS-only, what is the correct macOS skip item for the Age Range / age-related Setup Assistant pane? Is the Age Range pane intentionally only auto-skipped in ADE on macOS? Should Apple’s public Device Management / SkipKeys documentation be updated to list the correct key names, supported platforms, minimum OS versions, and enrollment requirements? This is important for Mac deployments where devices are enrolled into MDM but are not assigned through Apple Business Manager / Automated Device Enrollment. At the moment, it is difficult to determine whether the behavior is expected, unsupported, or a bug in macOS / Setup Assistant / MDM profile handling. Thanks.

I added a dummy view - copy paste directly from the Apple Developer Documentation, in a swift package using swift 6 and got concurency error. The fix is to switch to swift 5

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.

Hi Team, We are facing issue in testing the Age verification using Sandbox Account for your test environment. We tried to create region-specific sandbox test accounts as mentioned in the link (https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox) but we dont see an option to select Date of Birth and App Store Territory. After navigating to sandbox apple account setting and we tried to login with created sandbox test accounts(with gmail.com / qa.com/ test.com), its asking for two factor authentication. So, question here is which account should i use, sandbox account / real apple id? To overcome point 2, we created a gmail account and same is created as Sandbox test account, so that we can overcome two factor authentication. Now when we try to click on manage, nothing is happening. As per the link, it should show and option for select Age Assurance or Revoke App Consent. So if you can guide me with exact steps to follow on how to use the Sandbox account, that would be helpful for our app development. Thanks

Hi We are trying to set the child's age but kind of stuck in loop in Age Range SetUp. Attached a video for reference. Could you please suggest what steps we are missing or is this a Bug from Age Range Services Framework.

Hi, We have implemented Age Verification in iOS and wanted to test the workflow before releasing the app. How do we test the app before releasing it in production. We currently use Test Flight for testing. We created users in Sandbox but that shows just Texas in Age Assurance.