Is there a setting in Settings for None, Ask, or Always for Declared Age? I cannot find anything in iOS 26.2 Settings app, nothing comes up in a search for "age" in Settings. I managed to setup a sandbox apple account (after creating a new email address) and I was able to go to Settings->Developer, login to the sandbox account, and try the various settings for age there, so that much is working. When I call AgeRangeService.shared.requestAgeRange(ageGates: 18, in: presenter) I get "The operation couldn’t be completed. (DeclaredAgeRange.AgeRangeService.Error error 0.)" Is there a way to test this with my regular personal apple unpaid developer account, my work apple developer account with MS SSO, or with the sandbox user? Should I be using requestAgeRange or isEligibleForAgeFeatures? We just have a regular app on the store, it doesn't have chat or anything like that, it's used by licensed truck drivers mostly CDL holders who are 99.99% 18+ in age, possibly some exceptions for 16+ farm drivers. And we would like to stay compliant. Other caveats are that only iOS 26.2 and up are supported, and a judge has blocked the Texas law. Is Apple still supporting the Declared Age Framework or has there been a change?

I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.

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.

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.

I've been trying to follow Apple's testing age assurance documentation here. After following each step and setting my user as "Texas, child 16-17, significant change declined", the AgeRangeService consistently throws the notAvailable error: do { let response = try await AgeRangeService .shared.requestAgeRange(ageGates: 18, in: self) // ... } catch AgeRangeService.Error.notAvailable { // Always throws this error }

Hey Apple Friends, We currently have an enterprise version of our app for debugging and internal distribution. Our release configuration uses our App Store account. However, it appears you cannot add a 'Declared Age Range' to the Enterprise app as a capability making it impossible to debug because we have added the 'Declared Age Range API' locally, but we cannot add it as a capability on the dev portal. Is there any work around for this?

操作步骤：1:调用let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures，返回YES后，再次调用 let response = try await AgeRangeService.shared.requestAgeRange(ageGates:18, in: viewController) switch response { case .declinedSharing: DispatchQueue.main.async { completion(.declinedSharing, nil, nil) } case .sharing(let swiftRange): DispatchQueue.main.async { let model = ARAgeRange(swiftRange: swiftRange) completion(.sharing, model, nil) }

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

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'm reading the "Testing Age Assurance in Sandbox" doc, but I couldn't figure out the step: 2. Tap Sandbox Testing from the main menu Where is the "main menu"?

I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!

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"

We are integrating Apple’s DeclaredAgeRange SDK. To comply with relevant regulatory requirements, our understanding is as follows: The app is only required to obtain the declared age range for users located in Texas. For users outside of Texas, we should not proactively request age range information. Accordingly, we would like to confirm the following: Are we required to present the age range request prompt to all users in the United States? If yes, we are concerned that this may significantly impact the overall user experience. If it is permissible to request age range only for Texas users, how can we reliably determine whether a user is located in Texas on the client side? For example, does Apple provide an API or recommended method for accurately identifying a user’s region (specifically Texas)?

We are getting the above mentioned error while uploading to TestFlight. We have used a Swift Class to request for the Age Range via DeclaredAgeRange Framework. We have exposed Swift class and a helper function to be available in Objective-C layer. We have enabled the following build settings SWIFT_OBJC_INTERFACE_HEADER_NAME = "Common-Swift.h"; SWIFT_OBJC_BRIDGING_HEADER = "Common-Bridging-Header.h "; ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES Also we are compiling the application using latest available Xcode release 17C52 Is there anything else we need to do to resolve the error?

While preparing my app for Declared Age Range capability usage, I've noticed a weird behaviour: the same code works for iOS, but not for macOS. My project uses same target for both platforms, so the capability is enabled for both platforms. The business logic layer is also shared across between platforms. Both UI layers are writter in SwiftUI. The iCloud account used for testing on iOS and macOS devices is the same, so even the consent is shared across both devices. While requestAgeRange(ageGates:) seems to work just fine for iOS app, for macOS app it always throws Not available error (DeclaredAgeRange.AgeRangeService.Error.notAvailable) Am I missing something? Could the API be somehow unavailable for macOS? Should I use AgeRangeService.shared.requestAgeRange(ageGates:in:) for macOS instead of SwiftUI's @Environment-based approach? Also, after giving permission, is there a way to actually revoke it? In Age Range for Apps menu I can only view the list of apps that have my consent to share my age range, but not the ability to revoke it.

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?

We are using AgeRangeService.requestAgeRange(ageGates:in:) with an age gate of 18 to verify adult users. The system prompt always displays the lower-bound wording (“17 or Younger”), even when the app’s requirement is to verify users who are 18 or older. We understand the UI is system-controlled; however, this wording causes confusion for users, QA, and product teams, as it appears to indicate a child-only flow even when requesting adult verification. Based on the demonstration video, it appears that they have another more coherent message. In Apple's example, it is different, and it is correct that we need to specify 18 years or older in the implementation. A little more context might be helpful, but we are creating a kind of wrapper with React Native that receives that value as a parameter, which is 18.

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?

Hello, we get in touch as we need some guidance from Apple regarding age verification for minors in our app. Our app supports iOS 17 and above. The Declared Age Range API is available only starting on iOS 26, but we must comply with legal requirements (e.g., Texas SB 2420) and ensure that minor users cannot access certain sections of the app, regardless of the version of the operating system. Our question: What is the correct and Apple-approved approach for handling age verification and restricting access for minor users on iOS versions prior to 26, given that the Declared Age Range API is not available on those systems? We want to ensure that our implementation aligns with the regulations, the App Store Review Guidelines and platform expectations.

#1) The docs for the significantAppChangeApprovalRequired option (https://developer.apple.com/documentation/declaredagerange/agerangeservice/parentalcontrols/significantappchangeapprovalrequired) are a bit unclear of the meaning. If this is set to true, does that mean (a) its an indication from Apple that the user is in a jurisdiction that requires approvals for significant app changes or (b) the App store has detected a significant app change and the app needs to use PermissionKit to re-obtain approval. #2) In section Sec.A121.053 of SB2420, it states "The developer of a software application shall provide notice to each app store through which the developer makes the software application available before making any significant change..." and there are several subsections that define what constitutes a signficant app change that include items like "change of personal data stored", etc. How can developers notify the app store that a significant change has occurred and how can the app then query the app store to detect these changes?