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://aninterestingwebsite.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://aninterestingwebsite.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.

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.