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:

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

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