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.

I am working on an e-commerce app (retail/marketplace) that allows users to place orders for both free and paid products. After receiving a DeclaredAgeRange API response — retrieved via the Family Controls / Screen Time framework — indicating that a user is a minor, I want to understand the recommended approach for handling payment flows. Specifically, is it necessary to block payments for users identified as minors via DeclaredAgeRange, even though our app uses server-side encrypted card processing rather than Apple In-App Purchases (StoreKit)? Any guidance on best practices or App Store policy requirements for this scenario would be greatly appreciated.

I am working on an e-commerce app (retail/marketplace) that allows users to place orders for both free and paid products. After receiving a DeclaredAgeRange API response — retrieved via the Family Controls / Screen Time framework — indicating that a user is a minor, I want to understand the recommended approach for handling payment flows. Specifically, is it necessary to block payments for users identified as minors via DeclaredAgeRange, even though our app uses server-side encrypted card processing rather than Apple In-App Purchases (StoreKit)? Any guidance on best practices or App Store policy requirements for this scenario would be greatly appreciated.

Anyone knows to comply with Laws in Brazil, should we use all of the available age verification categories except the case selfDeclared category? In other words does Apple have a specific recommendation on which IOS categories for the verified age categories are recommended/not recommend to use for compliance? I didn't find any info regarding this

While the recent news says "Developers who are distributing apps in Brazil can use the updated Declared Age Range API to obtain a user’s age category.", the guidance in the API did not mention Brazil. Can we confirm that Should all iOS developers follow that guidance for Brazil compliance? Will IsEligibleForAgeFeatures return true for in scope users in Brazil? (We don't have any explicit confirmation on this, and we cannot test if this is the case today in sandbox)

Our team is in the process of updating our apps to comply with Texas's new state law. In order to minimize user confusion and provide the most ideal flow to access the app as possible, we have a few questions we would like answered. Summary of questions: Is isEligibleForAgeFeatures intended to be accurate and accessible before the user has accepted the Age Range permissions prompt? As other US states and/or other countries adopt a similar law going forward, will this instance variable cover those locations? Will the runtime crashes on isEligibleForAgeFeatures and other symbols in the DeclaredAgeRange framework be addressed in a future RC or in the official release? Details and Investigations: With regards to isEligibleForAgeFeatures, our team has noticed that this value is always false before the age range prompt has been accepted. This has been tested on the XCode RC 26.2 (17C48). Assuming the request needs to be accepted first, isEligibleForAgeFeatures does not get updated immediately when the user chooses to share their age range (updated to true, when our sandbox test account is a Texas resident). Only upon subsequent relaunches of the app does this return a value that reflects the sandbox user's location. Is isEligibleForAgeFeatures intended to be accurate and accessible before the user has accepted the Age Range permissions prompt? This leads to our follow-up question to clarify whether isEligibleForAgeFeatures explicitly correlates to a user in an affected legal jurisdiction–if future US states and/or other countries adopt a similar law going forward, will this instance variable cover those locations? Can we also get confirmation about whether the runtime crash on isEligibleForAgeFeatures and other symbols in the DeclaredAgeRange framework will be addressed in a future RC or in the official release? Thank you.

The documentation for isEligibleForAgeFeatures states: Use this property to determine whether a person using your app is in an applicable region that requires additional age-related obligations for when you distribute apps on the App Store. But what does "region" mean? Is this going to return true if the user has downloaded the app from the US App Store? Or will it go further and geolocate the user and identify them as being within a particular relevant state within the US?

Does our app need to check the location or can we fully reply on this API to decide whether we wanna comply for the law of places that requires age range information? Looks like it's only covering Texas now..? would it add other places by apple..? And also this API is really hard to test a user in other places, Iike I don't know a user in Brazil gonna return true for false now, but the law in Brazil also requires the age information.

Hello Apple Developer Support Team, We are developing an iOS iPhone application and would like clarification on whether Apple provides any APIs or system-level support to implement parental approval workflows aligned with certain regional regulatory requirements (for example, Texas, Utah, and Louisiana). Our intended use cases are outlined below: Initial Approval (App Download Stage) We understand that, in some situations, when a minor attempts to download an app from the App Store on iPhone, iOS may require approval through Family Sharing / Ask to Buy. We would like to confirm: • Whether there is any developer-accessible API that allows an iPhone app to detect if installation was approved via parental consent. • Whether apps can receive any callback, status indicator, or system signal confirming parental approval or rejection. • Whether the Declared Age Range API or any related framework provides access to parental approval or age verification signals. Ongoing Approval for Significant Changes For regulatory compliance, we may need to request parental re-approval when introducing significant application updates (for example, adding chat functionality, social interaction features, or modifying data collection practices). We would like clarification on: • Whether iOS provides any mechanism or API that allows iPhone apps to trigger or request parental re-approval after the application has already been installed. • Whether Apple provides any built-in workflows, system prompts, or entitlement-based approaches that support this type of re-approval process. In-App Handling of Parent Approval Requirements If our backend determines that a minor user requires parental approval before continuing to use certain app features, we would like to understand: • Whether Apple provides any APIs, SDKs, or recommended frameworks that allow initiating or facilitating parental authorization from within the iPhone app. • Whether there are any callbacks, permission states, entitlement checks, or system notifications that developers can use to determine and track parental consent status. If any such capabilities exist, we would greatly appreciate links to official documentation, technical guidance, or sample implementations demonstrating how approval status can be retrieved and handled in an iOS iPhone application. Also from which iOS version this capabilities will work & how to handle lower iOS version which is not supporting. Additionally, if Apple recommends alternative compliance approaches using existing frameworks such as Family Sharing, Screen Time APIs, or Declared Age Range, we would appreciate guidance on best practices for implementation. Also, could you please clarify the minimum iOS version that supports these capabilities? We would also appreciate recommendations on how developers should manage or implement fallback handling for devices running lower iOS versions where these capabilities are not supported. Thank you for your assistance and guidance in ensuring compliance with Apple platform policies and regional regulatory requirements. Kind regards

Hi all, I've been attempting to implement the Texas age range restrictions for an app I work on. I've banged my head against it for the last week and have a flow that is 99% working. I have all of the cases working exceptt when a significant change is approved. The issue I'm running into, is that let responsesSequence = AskCenter.shared.responses(for: SignificantAppUpdateTopic.self) is not receiving a response the first time it's called. It's only after the second time it's called that a response is registered and then I allow a user to access my app. When I set significant app change declined, then responses(for: ) returns on the first call to it. I can't for the life of my figure out why one works and the other doesn't. Has anyone else encountered this or have suggestions for me? I'm happy to post more code here in order to come to a resolution on this issue.

The tutorial only says a notification will be sent, but what happens next..? what should we do about the child account..? are we blocking them..? what happens on the child account? https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox

For testing permission response we can use the sandbox account However, when testing permission requests using the AskCenter API, none of the ask API works for me in xcode 26.2 rc and iOS 26.2 rc. For SignificantAppUpdateTopic, I got errors like "The user is in a region that does not support this type of ask" in the console log, but I've already set my billing address to Texas. For CommunicationTopic, the console shows several XPC-related errors, and I’m not sure which of them are relevant. Both of them show an alert view of "Can't ask, An unknown error occurred" Can someone help to guide us how to test the request flow? Thanks

I've tried pass different value like 13,16,18, but I don't see any difference..? could anyone tell what could happen differently if I pass a different value here?

I found currently there is no way to revoke sharing age to an app after I shared to it, no matter in testing or in app settings

We recently released an update to our app to prepare for TX SB2420. Almost immediately on release, we started getting crash reports of crashes when calling isEligibleForAgeFeatures. Crashed: com.apple.root.user-initiated-qos.cooperative EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000004 Is it possible that these are beta users that have IOS 26.2 RC or is there a bug in the release version of IOS 26.2? Note: The crash reports are coming from Crashlytics so we are not getting OS build identifiers other than version "26.2"