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.

My current app is a smoking cessation app and it is desgined to help people quit smoking for good. Currently users of the app are expected to set a quit date and then remain quit from cigarettes for 12 weeks. The app helps with this by using badges, notifications and even live chats to stop smoking professionals (depending on your area). The app "frequently" mentions smoking and tobacco, but it never promotes it. It does the opposite. By mentioning the harms of smoking and the benefits of stopping. The app also mentions (and can provide, depending on your area, medical history and a professionals final opinion) about nicotine replacement therapy, which users who are quitting smoking may be interested in. Currently the app is rated 18+ as I have to tick "frequent" mention of drugs/tobacco/alcohol in the age rating questionnaire. Though it does not mention recreational drugs or alcohol. We will soon be adding a large update to the app to add vaping support. The app will change largely in the fact smoking content and vaping content will be siloed from each other. So a user can either be on a smoking support journey (and see stop smoking content), or a vape support journey (and only see vaping content). We need the app to be 13+ on the store and we will enforce age restrictions using the declared age range API as part of the account creation process. If the user is aged 13 - 17, they will only see vape related content, if they are 18+ they can see vaping OR smoking. How negotiable is the age rating certificate, can we change it to 13+ if we implement age restrictions in the app and protect stop smoking related content behind it?

Context: We are developing an SDK to support global age verification regulations (e.g., Texas HB 18, Brazil’s LGPD). We plan to use the DeclaredAgeRange and PermissionKit frameworks. We want to verify if our proposed "Block-by-Default" sequence for non-compliant states is legally and policy-compliant according to Apple’s standards. Detailed Workflow Description: Initial Authentication: After the user logs in, the SDK calls requestAgeRange(ageGates: 13, 16, 18). Handling Sharing Status: If Declined: If the user declines age sharing (.declinedSharing), the SDK blocks app access and displays a popup guiding them to enable sharing in System Settings. Age Verification Results: Adult (VERIFIED, 18+): Immediate access to the game. Non-Regulated Region (UNKNOWN): Access to the game is allowed. Minor (SUPERVISED, 13-17): Step A (Age Gate): We check if they are 13+. If they are under 13, we block access and show an "Underage" notice. Step B (Family Sharing): If they are 13+, we check if Family Sharing is linked. If NOT linked, we block access and show a guide to set up Family Sharing. Significant Update & Parental Consent: If a "Significant App Update" requires consent (via requiredRegulatoryFeatures), we call AskCenter.shared.ask with a SignificantAppUpdateTopic. If Approved: The minor is allowed to proceed to the game. If Denied/Pending: Access is blocked, and a "Parental Consent Required" notice is displayed. Information Unavailable (REQUIRED): If age info cannot be verified, access is blocked with a guide on how to provide age information. Specific Questions for Feedback: Blocking for Non-Consent: In regions where Age Assurance is legally required, is it acceptable under App Store Review Guidelines to block app functionality for users who choose .declinedSharing? Mandatory Family Sharing: Is it permissible to require Family Sharing for 13-17-year-old minors to access the app, or must we provide alternative parental verification methods (e.g., credit card verification) for those not using Family Sharing? VPC Compliance: Does using SignificantAppUpdateTopic via AskCenter satisfy the "Verifiable Parental Consent (VPC)" requirements for regulations like Texas HB 18 or Brazil's LGPD for initial gameplay access? User Experience (UX): Does this "Strict Blocking" approach for unverified or non-consented states violate any policies regarding "App Functionality" or "Data Privacy," even if implemented for legal compliance?

Hello everyone I'm implementing age verification in my app to comply with upcoming age assurance laws (Utah, etc.), and I'm using AppStore.ageRatingCode from StoreKit to retrieve my app's current age rating. According to the documentation: extension AppStore { @available(iOS 26.2, macOS 26.2, tvOS 26.2, watchOS 26.2, *) public static var ageRatingCode: Int? { get async } } "Use this property to fetch the age rating for your app and compare it with the last known age rating to check if it has changed." However, calling this always returns 0 in my environment. Environment: Device: Real physical device (not simulator) iOS version: 26.4 Sandbox Apple Account: signed in via Settings → Developer → Sandbox Apple Account App Store Connect: app is registered and age rating is configured Xcode Scheme → Run → Options → StoreKit Configuration: None Code: func getAgeRatingCode() async -> Int? { guard let ageRatingCode = await AppStore.ageRatingCode else { print("Age rating code unavailable") return nil } print("ageRatingCode: \(ageRatingCode)") // always prints 0 return ageRatingCode } Questions: What integer values does ageRatingCode map to? (e.g., does 4+ = 4, 9+ = 9, 13+ = 13, etc.? Or is it a different internal code?) This mapping is not documented anywhere I can find. Is 0 a valid return value, and if so, what does it represent? Is there a known issue with this API returning 0 even when all conditions appear to be correctly configured? Any guidance from Apple engineers or developers who have successfully used this API would be greatly appreciated.

Hi, Regarding the Brazil Digital ECA (DECA) requirements, which became effective on March 17, 2026. Following the guidance for regulated regions, we have been testing the eligibility check with the iOS 26.4 release. We previously confirmed that isEligibleForAgeFeatures was returning true for users in the Brazil region, which allowed us to verify our age-gating implementation. A few questions follow on this eligibility check: We have observed in manual testing that specific devices which returned true as recently as March 23rd are now returning false today, despite no changes to the OS build or account settings. Does this indicate a change in the server-side eligibility heuristics? Why would isEligibleForAgeFeatures stop returning true for a region where the law is now in force? Has the guidance on how to evaluate these properties for Brazil changed with the transition to the stable 26.4 release? Thank you!

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?

We made an update of one of our games with the Declared Age Range framework, and one of the users contacted us, asking how could he confirm his age to access the app's features. Meaning that isEligibleForAgeFeatures returned true on his device. According to documentation: Use isEligibleForAgeFeatures to determine whether associated laws or regulations may apply to your app based on the person’s location and account settings. This property returns true when your app needs to support Age Assurance for the current user. As far as we know, the laws are not applied anywhere yet. So, why did isEligibleForAgeFeatures return true?

Today is March 17th, which is the effective date for BR DECA. From what I can tell, isEligibleForAgeFeatures is still returning False for users in Brazil. Following up on https://developer.apple.com/forums/thread/816987?answerId=878188022#878188022, the API does not appear to be covering the requirements for this regulation. Could you please give some guidance on whether isEligibleForAgeFeatures will ever return True for Brazil? I'm also curious whether other apps are also seeing the same behavior (isEligibleForAgeFeatures=False) for users in BR today.

From the Feb 24 news, I understand that for all Apple users in Brazil with iOS26.2 and newer, isEligibleForAgeFeatures will eventually return true. Brazil is a "nonregulated region", and developers will need to handle all three situations of ask first/always share/never share. Please correct me if I'm wrong above. A few questions follow on the eligibility check: What's the return value of IsEligibleForAgeFeatures for a Brazilian user who has NOT touched the age range feature at all, thus hasn't picked one of the three options? How can we test these cases? From the updated sandbox doc, there's more information on declined/approved, will those the same behaviors as a future Brazilian user? The doc used to say Texas, now it doesn't say any region. On which date will Apple START to return true for IsEligibleForAgeFeatures for Brazilian users? I cannot find the exact date anywhere. Will ALL of Brazil return true overnight, or is there some ramp up that developers need to be aware of? Thanks a lot for sharing the guidance, and thanks in advance for more guidance to come!

When calling the verification interface for "whether the user belongs to a restricted region", the return value is always false; even if the Apple account is registered as an account belonging to a restricted region and the account is set to supervised mode, the interface return result remains unchanged, and it is impossible to verify a true result. The code for calling the interface is as follows: @available(iOS 26.2, *) @objc public func eligibleForAgeFeatures() async -> Bool { var isEligible = false do { isEligible = try await AgeRangeService.shared.isEligibleForAgeFeatures } catch { isEligible = false } return isEligible }

We now know the IsEligibleForAgeFeatures API is NOT returning True in Brazil at least 2 days past compliance date, and we don't know if that's the right API, or how it behaves. Folks here: Is there anyone here from Brazil who has tested out this 26.4 API? Has anyone tested out the regulatory feature API? Does it return something like declaredAgeRangeRequired? I don't know how to test it in Brazil without sandbox/physically in Brazil. Much appreciated!!

Hi, I have a problem testing sending a significantAppUpdateTopic request with AskCenter. Sending a request of type CommunicationTopic works correctly: let question = PermissionQuestion<CommunicationTopic>( handle: .init(value: description, kind: .custom) ) try await AskCenter.shared.ask(question, in: viewController) Receiving the response from the guardian also works correctly for a question of type CommunicationTopic. However, after changing the request from CommunicationTopic to significantAppUpdateTopic, I get the following cryptic error: Error returned from daemon: Error Domain=com.apple.accounts Code=7 "(null)" (and nothing happens). This is the code I am using: let topic = SignificantAppUpdateTopic(description: description) let question = PermissionQuestion(significantAppUpdateTopic: topic) try await AskCenter.shared.ask(question, in: viewController) These are my settings: I created a child account within a family group the child's age in the family group is set to 15 I am the group organizer I am not located in Texas or the United States I am running this code in the app on a device where I am signed in as the child. Additionally, in the developer settings on the phone, I am signed in to a test Apple account where I set Age Assurance to: "Texas, child 13-15" (I also tried it without that, but I got the same error message) I would be very grateful for any information on how I can test this functionality without being in Texas.

Hello I'm using this sdk DeclaredAgeRange to get the user age range When I'm doing in debug mode using sandbox account it is working as expected and I can get the user age range But when I tried in TestFlight build using sandbox account it is not working and it is always return the age range 18+ and also isEligibleForAgeFeatures API is always returning false Any advise on this?

Given that we can't use isEligibleForAgeFeatures property on macOS, the documentation states that In macOS, isEligibleForAgeFeatures returns false because the system doesn’t require Age Assurance for the person or device. However, you can still call requestAgeRange in macOS to get the declared age range. But in unsuitable region the requestAgeRange request always returns DeclaredAgeRange.AgeRangeService.Error.notAvailable which is vague, as it might stand for API being unavailable just as well as "You receive this error when the system prompts a person and they decide not to share their age range with your app. ", as per documentation. Unfortunately, this error fires immediately instead of showing any kind of prompt for user, so the description is definitely wrong (or incomplete) in here. Possible solutions: expand Error cases to separate not available API and not available response expand isEligibleForAgeFeatures to properly support macOS Moreover, unlike iOS, there is still no usable tool or algorithm to test given feature for macOS (mock region, mock age, mock source of approval, revoke declared range, etc). Now I get a review with rejection, stating that I don't have age verification mechanisms present in my app. Also I found out that after filling the App Information regarding Age Ratings it spreads to all fresh releases, so even though my newest macOS release doesn't contain age verification mechanisms yet, it should, as iOS release has got this functionality up and running already and I had to check this when filling Age Ratings questionnaire. Now I'm stuck between removing this capability from App Information, so the macOS release can pass and stalling macOS releases until there is a proper usable API to implement Declared Age Range verification properly (at least the same way as on iOS). How should I properly develop and test this feature for macOS before releasing it publicly?

Dear Apple, while implementing Declared Age Range API in my app, I've noticed a mistake in documentation: the isEligibleForAgeFeatures property is marked 26.0+ in documentation, but 26.2+ in Xcode, which ultimately leads to inability to use it with OS below 26.2. Moreover, I'm thoroughly confused by this quote from documentation: This flag returns true on iOS and iPadOS based on a person’s eligibility and always returns false on macOS. It leads me to two questions: Is it possible to use Declared Age Range API for macOS apps? Will it be possible to use it in future? Will there be any changes regarding this matter in a meantime (especially after Jan 1st)? If yes - when should we expect these changes? If no - why this API declares macOS 26+ support alongside iOS/iPadOS, if it simply doesn't work for macOS now? As of now, my iOS app works flawlessly with given API (on iOS 26.2) while macOS app returns isEligibleForAgeFeatures = false and requestAgeRange request always throws AgeRangeService.Error.notAvailable. Also, does it mean that one should not use isEligibleForAgeFeatures boolean while implementing Declared Age Range API for apps below iOS 26.2 (I mean 26.0+)? Or implementing given API for iOS 26.2+ is a sufficient way to go? So shouldn't the whole API be marked as 26.2+? The minimum iOS version in my app is 16.0 and minimum macOS version is 13.0 anyway, so the significant part of users is left out of these updates, but the main goal here is legal compliance.