@DTSEngineer Can you please reply to one of these threads with the expected bahavior of isEligibleForAgeFeatures ?

@DTSEngineer Can you please reply to one of these threads with the expected bahavior of isEligibleForAgeFeatures ?

We asked weeks ago and got no response from Apple. https://developer.apple.com/forums/thread/809829 My assumption is that it should currently return false everywhere and begin to return true only for users from Utah and Louisiana whenever those laws some into effect. https://developer.apple.com/forums/thread/809829?answerId=870440022#870440022

Given the Federal Court Injunction on Dec 23, will isEligibleForAgeFeatures now accurately return false for minors in Texas?

Related to termination, my advice is to NEVER terminate your app. In the past, some of our Apps had a Decline button on the Terms of Service (ToS) screen that terminated the app, but App Review flagged that behavior as a Crash and blocked our app submission. Now our ToS screens only have an Accept button and the user can press that or they can close the app themselves; this always gets through App Review. For Age Verification, we have implemented similar: If an eligible user Declines to share their Age Range or is a minor without parental consent, they see a screen explaining that they are blocked with a link to App Store documents about the law and settings. There is no way out of that screen other than closing the app.

Apple's hands have been tied Apple could have implemented it much more simply. The way Google Play is doing it is simple to understand, clearly documented, easy to implement, and just as privacy-secure for end users. https://developer.android.com/google/play/age-signals/overview From my reading and discussions, I believe raising an app's Age Rating to 18+ and Geo-Blocking Texas are both NOT COMPLIANT with the Texas (or UT (later in 2026), LA (later in 2026), and CA (January 2027)) law. AgeRangeService.shared.isEligibleForAgeFeatures is currently broken though: https://developer.apple.com/forums/thread/809829 My team is working under the assumption that it will eventually work and it's on Apple to fix their backend so it correctly returns True or False based on the user being in the impacted region.

It's known to crash with iOS 26.2 RC and XCode 26.2 RC. I've seen it working in my tests with the released versions of iOS 26.2 and XCode 26.2.

Answering the question in the OP and not the discussion about the blue warning box: I am not a lawyer, but my reading of the TX law is that implementing the age verification and parental consent workflows applies to all app developers regardless of target age range of the app. It DEFINITELY applies to all apps usable by minors in TX.

Question 3 is resolved now with the release of 26.2, but Questions 1 and 2 are still unanswered.

Some time in past 3 weeks, they added a new instance property to the AgeRangeService that might do what we want here. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures My team has this other post about it asking for clarification because it doesn't currently work as we expect: https://developer.apple.com/forums/thread/809829

These DeclaredAgeRange issues are blocking my team from completing development on our work to comply with the Texas law that comes into effect on January 1st and effects all apps on the app store ( https://developer.apple.com/news/?id=btkirlj8 ). What progress has been made in the past 6 days?

To be more clear than my post from August 2025, the solution is to rebuild all of your upstream dependencies with a version of XCode that includes the same version of clang that your version of XCode includes. The easiest way to be sure that upstream and your app uses the same clang is to build them both with the same XCode. If you rely on a library that you cannot rebuild, you need to file a bug with the maintainer for them to do that rebuild. Until those things have ALL been built with the same version of clang, you will not be able to see code coverage data.

This issue is a dup of https://developer.apple.com/forums/thread/770289?answerId=853752022#853752022 and is a fundamental limitation of how XCode uses/includes clang and LLDB and how they are not backward compatible with earlier versions.

I have figured out what's happening here. Code Coverage will ONLY work if ALL upstream dependencies have also been built with the newer version of XCode (and therefore the newer version of clang). A single profraw file will have multiple sections from the many different binaries that make up your build and each of those sections will have a header containing the raw profile version format of the clang that built that binary. For example, my framework built in XCode26 that depends on a binary framework built in XCode16.2 will have profraw headers with both 8 and 10 as the version, meaning that the resulting profraw file cannot be read in XCode26 (which can only read version 10) nor in XCode16.2 (which can only read version 8).

I'm seeing the same issue in XCode26 but now it's complaining about raw profile format version = 8; expected version = 10 :cry: