I'm still having this issue on Xcode 26.6. I deleted and reinstalled the latest simulator runtime available ("iOS 26.5.1 + iOS 26.5 Simulator" / SDK version 26.5.1 (23F81a) / Simulator version 26.5 (23F77)), relaunched Simulator.app and created a fresh simulator. For me, the issue also happens when tests are launched from Xcode directly. The workaround of launching the app manually and then launching the tests does not work, even though the Configuration.storekit file is in place in the filesystem hierarchy. Many methods on SKTestSession result in errors like [SKTestSession] Error saving configuration file: Error Domain=SKInternalErrorDomain Code=3 "(null)" or [SKTestSession] Error deleting all transactions: Error Domain=SKInternalErrorDomain Code=3 "(null)" or Failed to purchase com.mycompany.product.id in off-device buy mode: Unable to Complete Request My tests were legacy scheme-based tests; I converted them to test plans which made no difference. I have submitted FB23721564 with these details.

You can temporarily mitigate this issue (or at least I could) by disabling the new chained fixups link method that was enabled per this change in the Xcode 13.3 release notes: The new chained fixups format is the default linking method when targeting macOS 11 or later, iOS 13.4 or later, watchOS 7.0 or later, and tvOS 14.0 or later. This new format results in smaller LINKEDIT segments in binaries. When targeting earlier operating system releases, the linker continues to generate the traditional opcode format in LINKEDIT for fixups, rebases, and binds. (85572905) To disable the chained fixups, go to the "Other Linker Flags" build setting in Xcode and add two in the following order: -Xlinker -no_fixup_chains. (It's surprising to me that you need -Xlinker here but I got errors without it). This should be viewed as a temporary workaround, because the chained fixups is a legitimate improvement to binary size and build time. Ideally Apple will correct this so that we can leverage that improvement on older versions of iOS like they seem to have intended.

xcrun dyld_info -fixup_chains /path/to/Framework.framework/Framework also reports this issue "chained fixups, seg_count exceeds number of segments" so it seems like something is corrupted in the dynamic linking information of the binary. Following a hunch that I got from reading info on this related issue https://forums.swift.org/t/async-await-crash-on-ios14-with-xcode-13-2-1/54541/48, I disabled the "enable bitcode" build setting for my framework (it was already disabled for my app, so this isn't a problem - unfortunately bitcode really should be enabled, but this might be a temporary fix while we wait for an official one). I hypothesize that disabling bitcode altogether makes Xcode not put any bitcode segment in the binary, which fixes the seg_count issue (the cause of which, according to the swift.org link is that Xcode stripped the bitcode segment but didn't update the seg_count properly).

Having the same problem. My app will launch "tethered" from Xcode on iOS 14 but will not launch from SpringBoard. Also inspected binary with otool, everything looks good. This appears to be due to the following change from the Xcode 13.3 release notes: "The new chained fixups format is the default linking method when targeting macOS 11 or later, iOS 13.4 or later, watchOS 7.0 or later, and tvOS 14.0 or later. This new format results in smaller LINKEDIT segments in binaries. When targeting earlier operating system releases, the linker continues to generate the traditional opcode format in LINKEDIT for fixups, rebases, and binds. (85572905)". I wonder if there is a way to disable this new chained fixups format as a temporary fix.