I think this is due to this other xcode 14.3+ issue and nothing wrong with Slather or Fastlane: https://developer.apple.com/forums/thread/734611

I'm seeing the same issue in all of my projects on xcode 15.0.1. For folks who got it fixed, how did you figure out which upstream dependency was breaking things?

After a bunch of debugging in the llvm-profdata source code to understand how .profraw Version 8 files work, and then doing some hex editing of my corrupted output .profraw file in DerivedData to remove the corrupted section of the file, I think I have determined which framework we include that is breaking my project: MBProgressHUD. After all of that, I was able to see a simple way of determining the included frameworks that will corrupt the ProfData: Go to the Carthage/Build folder (or wherever your included .xcframework folders are) and look at the modified date of each framework's Info.plist. Any really old ones are likely to break, and the only one I have in this project before 2023 is the one for MBProgressHUD (which is from 2021, which is definitely way before XCode 14.3).

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

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).

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.

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.

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?

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

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

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.

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.

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.

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.

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