I've compiled an xcframework with ENABLE_TESTABILITY set, but it doesn't seem to allow for @testable import to work on the module. There's an Apple forums post on this at How to build an xcframework module… | Apple Developer Forums, but didn't have much response.
Swift.org - Library Evolution in Swift suggests that this isn't a library evolution problem, not sure what the cause would be though.
@testable import exposes a module's internal APIs for testing, but an xcframework's module interface only contains the public APIs regardless of whether you compile for testing. Part of this is a limitation of the format (though I've paged out what those are by this point, since I no longer work at Apple), and part of it's a reasonable design choice—it doesn't make sense for someone else to be accessing your module's internal APIs, and if it's you trying to access your module's internal APIs, you can presumably build it yourself locally and not use xcframeworks. (I did read your original post that you linked and I'm not sure why you're using xcframeworks?)
That said, I can think of one scenario in which it would make sense to do this, which is running the same test suite against past versions of your framework. So it'd be reasonable to file a feature request bug for this.
(The -allow-internal-distribution option for create-xcframework will avoid stripping out the compiled module when it constructs the xcframework from your build products, and that will let @testable import work…but only within the same version of Xcode. That might be what you need, though.)
Explains why it works for the frameworks from the xcarchives but not inside the xcframework then!
...it doesn't make sense for someone else to be accessing your module's internal APIs, and if it's you trying to access your module's internal APIs, you can presumably build it yourself locally and not use xcframeworks
Yeah fully agreed here, there's a bit of history with this app where it's a bunch of modules and this one was built alongside at one point so this was less an issue, but some time ago was split out to be precompiled for organizational/security/general corporate access control reasons (whatever the validity of it), so has been shipped as a framework but with some coupling on using @testable to get access to the internal module for the purpose of creating mocks and overriding classes. It's access control and general architecture is definitely not where it should be, which is part of why this is even an issue.
(The
-allow-internal-distributionoption forcreate-xcframeworkwill avoid stripping out the compiled module when it constructs the xcframework from your build products, and that will let@testable importwork…but only within the same version of Xcode. That might be what you need, though.)
Unfortunately we do need to build this to be forwards-compatible, but this flag is actually super useful for another build-cache related thing I've been poking around with so thank you!