I'm developing for compliance with Texas law in the United States. Currently, I'm encountering an issue where I want to test the feature point "when the app undergoes significant changes, a supervised user initiates a request." However, during actual testing, the app pops up an error message: "Can't Ask, An Unknown error occurred." Additionally, I see the following error message in the Xcode Console: "Error Domain=AskToCore.ATMessageComposeValidationError Code=4 'The user is in a region that does not support this type of ask.' UserInfo={NSLocalizedFailureReason=The user must be in a supported region to use this feature., NSLocalizedRecoverySuggestion=Please ensure the user is in an eligible region., NSLocalizedDescription=The user is in a region that does not support this type of ask.}" I am indeed not in the Texas region. I want to conduct full-process testing before the feature is released to the App Store. What should I do? Apart from Sandbox testing (which, in fact, doesn't show any pop-ups either), how can I test under real-world conditions?

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!

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!!

We are in the process of preparing our app to support the new Texas law (SB2420) that takes effect 1/1/2026. After reviewing Apple's recent announcements​/docs concerning this subject, one thing isn't clear to me: how to associate an app install with a​n App Store Server RESCIND_CONSENT notification​ that could be delivered to our server. Our app is totally free so there isn't an originalTransactionId​ or other similar transaction IDs that would be generated as part of an in-app purchase (and then subsequently sent as part of the payload in the notification to our server during an in-app purchase scenario). So my question is: How do I associate an app (free app) install with an App Store Server RESCIND_CONSENT notification​ that is sent to our server​?

I've been writing about the DeclaredAgeRange a bit on LinkedIn and now it is time to take to the developer forums. In my efforts to prepare my apps for new local requirements, I've run across some rough edges. The DeclaredAgeRange API is missing on several platforms, and extension types. First and foremost, watchOS. An Apple Watch is a clear single user platform and for standalone apps, the DeclaredAgeRange being absent is felt by developers. FB20954931 - DeclaredAgeRange: Framework not available on watchOS making compliance a challenge for watchOS standalone apps In the same vein of thinking, while users on Apple Vision Pro are far fewer numbers than Apple Watch, it is also a miss. The tricky part would be testing on the simulator. So far I haven't gotten the simulator and sandbox testing to work and give real values across any platform. I don't think an Apple Store will let me try my app out via TestFlight on their devices and they're still too expensive to reasonably buy for most developers. Too bad Feedbacks are not a currency that developers can trade in for gear. FB20955020 - DeclaredAgeRange: Framework not available on visionOS making compliance a challenge for visionOS apps I'll recognize that the user model is different on tvOS, and that as a user while I have family group setup, I don't have any children on the account. I have to imagine that child accounts on an Apple TV exist and would be able to account for the sharing of age ranges to apps. Yes, the user could just switch profiles, but, app developers could still integrate the age range into their apps. Maybe it needs more robust system level support but here is the feedback just the same. FB20955029 - DeclaredAgeRange: Framework not available on tvOS making compliance a challenge on tvOS apps And finally, let's not forget about App Clips. While the App Clips might not be 'downloaded' from App Store itself, it is powered by App Store technologies to an extent. I'd rather not bifurcate my code more than it already is for the shared code between my apps and app clips. Rounding out platform support to App Clips, since it is iOS, would close the loop. FB20954846 - DeclaredAgeRange / App Clips: Add support for DeclaredAgeRange framework for App Clip targets - capability exist, Xcode cannot generate entitlement for it Oh wait, actually, not quite. To fully close the loop, make the DeclaredAgeRange work fully on macCatalyst. The documentation says it is compatible, but from my experiments trying to get it to even compile when targeting macCatalyst apps simply doesn't build. FB21117325 - DeclaredAgeRange: API documentation states available on mac catalyst - but fails to compile in Xcode 26.2

Like any good developer, I try to add tests where I can. The AgeRangeService.AgeRange type does not provide an initializer. I know the routine, create an interface or a simple struct that I control and use that instead. Thanks to extensive time with frameworks like Core Bluetooth or Core Location, this is a well understood practice (looking at you CBPeripheral...). Great I'll make my own 'AgeRange' struct. Make it Hashable, make it Sendable, use the framework types as properties. Scratch that, most of the properties on AgeRangeService.AgeRange type are not Sendable and many are also not Hashable. This is proving to be challenging. I hope to open source my little Swift Package wrapper library for DeclaredAgeRange which will add types with full Hashable and Sendable conformance. I hope Apple updates the API and makes this obsolete. I don't see why these simple types can't be Hashable and Sendable. They're structs, enums, and OptionSets (structs). FB20959748 - DeclaredAgeRange: DeclaredAgeRangeAction is not sendable causing main actor compile errors with default isolation settings FB20960560 - DeclaredAgeRange: AgeRangeService.AgeRangeDeclaration is not sendable as expected FB20960574 - DeclaredAgeRange: AgeRangeService.ParentalControls is not sendable as expected FB20960590 - DeclaredAgeRange: AgeRangeService.ParentalControls is not hashable as expected On the note of the library and using the types as-is, there are some issues using the new cases in AgeRangeDeclaration and the isEligibelForAgeFeatures property. I started another thread over here: https://developer.apple.com/forums/thread/808144

Hello, I need clarification regarding the new Declared Age Range requirement. App Name: Hanna Lab Our app is a utility/scientific BLE app that connects to instruments, reads measurement values, and displays logs in a table or a Graph. We do not collect age data or provide any age-restricted content. I would like to confirm: Is AgeRangeService mandatory for an app that does not use age-based features? Do we need to add the Declared Age Range capability in Xcode → Signing & Capabilities for such a utility app? Thanks for any guidance.

After reading the news below, we are currently working on updating our app in preparation for the enforcement of Texas SB 2420. https://developer.apple.com/news/?id=2ezb6jhj Based on the information in the announcement, we understand that parents will be able to revoke their consent for apps. However, we are unsure how an app is supposed to obtain or verify the parent’s consent status in the first place. We reviewed the Declared Age Range API and PermissionKit’s Significant Change API, but could not find any functionality related to this. If anyone with expertise on this topic has insight, we would greatly appreciate your guidance. Thank you in advance.

After reading the news below, we are currently working on updating our app in preparation for the enforcement of Texas SB 2420. https://developer.apple.com/news/?id=2ezb6jhj Based on the information in the announcement, we understand that parents will be able to revoke their consent for apps. However, we are unsure how an app is supposed to obtain or verify the parent’s consent status in the first place. We reviewed the Declared Age Range API and PermissionKit’s Significant Change API, but could not find any functionality related to this. If anyone with expertise on this topic has insight, we would greatly appreciate your guidance. Thank you in advance.

Hello, I’m currently reviewing and implementing age assurance and parental approval flows using AgeRangeService and PermissionKit (AskCenter) in the context of Texas regulatory compliance requirements. While the high-level APIs are clear, there are several technical aspects where the intended usage patterns are not fully explicit in the documentation. Clarification on these points would help ensure our implementation aligns with system expectations and regulatory obligations. ⸻ Querying the current approval state for SignificantAppUpdateTopic AskCenter.ask(...) returns Void, and AskCenter.responses(for:) provides an AsyncSequence of approval events. Is there an official or recommended way to determine whether a SignificantAppUpdateTopic has already been approved when the app launches, or is listening for future responses events the only supported mechanism? ⸻ Behavior of AskCenter.responses(for:) regarding past approvals When subscribing to AskCenter.responses(for:): • Does the stream replay previously recorded approval or decline decisions? • Or does it only emit events that occur after subscription? This affects whether the listener must be registered early in the app lifecycle. ⸻ Recommended lifecycle timing for registering a responses(for:) listener What is the intended or recommended time to register a responses(for:) listener? • At application launch • Immediately before calling ask(...) • When entering a specific gated feature Clarification on the expected lifecycle usage would be helpful. ⸻ Repeated calls to ask(...) after approval If AskCenter.ask(...) is called again for the same SignificantAppUpdateTopic after parental approval has already been granted: • Is the request ignored? • Is a new approval request sent to the parent? • Or is the call handled idempotently by the system? ⸻ Delivery of approval results when the child app is not running If a parent approves or declines a SignificantAppUpdateTopic while the child app is not running: • Will the approval decision be delivered as a responses(for:) event on the next app launch? • Or is the app expected to persist approval state locally? ⸻ Persistence of approval state Is the approval decision for SignificantAppUpdateTopic persisted by the system at the OS level, or is the app responsible for storing approval state? Additionally, does the approval persist across: • app restarts? • app deletion and reinstallation? ⸻ Meaning of activeParentalControls.significantAppChangeApprovalRequired How is activeParentalControls.significantAppChangeApprovalRequired determined? • Is this value explicitly configured by a parent (for example via Screen Time)? • Or is it automatically determined by the system based on region, age, or regulatory requirements? ⸻ Relationship between significantAppChangeApprovalRequired and AgeRangeService When activeParentalControls contains significantAppChangeApprovalRequired, is it still expected that apps call AgeRangeService.requestAgeRange(...)? Or can the presence of this flag be treated as sufficient indication that the user is a minor for gating purposes? ⸻ Recommended interpretation of AgeRangeDeclaration Is the intended usage of AgeRangeDeclaration to handle each case individually, or is it acceptable and recommended to interpret the values as different trust levels (for example, self-declared vs. government ID or payment verified)? Clarification on these points would help ensure that implementations of age assurance and parental approval flows are consistent with system behavior while meeting regulatory compliance requirements. Thank you for your guidance.

For other permission prompts in the iOS ecosystem, we have the option to configure the text shown in the prompt via keys in the Info.plist. This does not appear to be the case with regards to the age range permission prompt. The text of the prompt implies the app includes a differentiated experience for child or teen content and that confirming age unlocks more features (making it seem optional for using the app). Is there a plan for app developers to be able to update that permission prompt similarly to how we can configure others? If so, is there any timeline we can expect that on?

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.

HI When I try to add Declared Age Range in the capability, there is no such thing... I'm on XCode version 26.2 (17C52)

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

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?

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)

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

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.

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.

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!