Like the others have noted, this is still an issue with Xcode 26 Beta 2 as well.

I am experiencing this same issue in apps that include our SDK. I have tracked the crash down to when we call URLSession.shared during the SDK initialization. * thread #10, name = 'Task 1', queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x257b8318c) frame #0: 0x0000000257b8318c frame #1: 0x0000000257b80d14 frame #2: 0x0000000257b80b8c frame #3: 0x0000000257b80b68 frame #4: 0x0000000257b80c98 frame #5: 0x0000000257b8a1bc frame #6: 0x0000000257b8a8e4 frame #7: 0x0000000257b80b8c frame #8: 0x0000000257b80b68 frame #9: 0x0000000257b8a888 frame #10: 0x000000018931ccf4 frame #11: 0x000000018931f044 frame #12: 0x00000001888a3bfc frame #13: 0x00000001888a3a94 frame #14: 0x00000001801d34b0 frame #15: 0x00000001801bb3d4 frame #16: 0x00000001888a6f30 frame #17: 0x0000000184e9fc10 CFNetwork`-[NSURLSessionConfiguration initWithDisposition:] + 352 frame #18: 0x0000000184ea0174 CFNetwork`__65+[NSURLSessionConfiguration sessionConfigurationForSharedSession]_block_invoke + 36 frame #19: 0x00000001045919dc libdispatch.dylib`_dispatch_client_callout + 12 frame #20: 0x000000010457adf0 libdispatch.dylib`_dispatch_once_callout + 84 frame #21: 0x0000000184e9ff00 CFNetwork`+[NSURLSessionConfiguration sessionConfigurationForSharedSession] + 64 frame #22: 0x0000000184e239d4 CFNetwork`__30+[NSURLSession _sharedSession]_block_invoke + 24 frame #23: 0x00000001045919dc libdispatch.dylib`_dispatch_client_callout + 12 frame #24: 0x000000010457adf0 libdispatch.dylib`_dispatch_once_callout + 84 frame #25: 0x0000000184e239b8 CFNetwork`+[NSURLSession _sharedSession] + 192 The strange thing is that this DOES NOT crash with the previous version of our SDK. This latest release adds another library that has its own call to URLSession.shared in it. Whats even weirder is that none of that code is even executed when our SDK initializes. If I comment out the one line of code that accesses that library, I can launch my demo app with no issue.

This appears to have been fixed with Xcode 15.4.

I just checked the status of FB13704428 and the resolution was marked as: Investigation complete - Unable to diagnose with current information. This is a bit unbelievable as this is widely reported over the internet and I can reproduce the issue at will. I have customer's reporting this issue to me as well. And the workaround to making this work is to manually go in and edit the Info.plist file and put in a bogus value that is way greater than the MinimumOSVersion of the containing application??? I would appreciate if other people that are seeing this issue could both comment here, and open your own feedback and include FB13704428 and this forum post.  needs to get this fixed.

Hi @pedroatanasio, We also ship a closed source binary static .xcframework via SPM and Cocoapods and are hitting the issue where apps that consume our SDK aren't getting the PrivacyInfo.xcprivacy file embedded into their application. You mention in your initial post that you have been successful in making this work with both CocoaPods and SPM. Would you mind sharing what your Package.swift file looks like to get this to work? I just had a customer reach out to me stating that they were notified by Apple that they need to provide usage reasons for the required reason APIs and we are not sure how to best get them consuming the PrivacyInfo.xcprivacy file that we have shipped. Appreciate your guidance!

We develop a static .xcframework and ship it as a compiled binary. We have included the PrivacyInfo.xcprivacy file and sign the .xcframework as specified. The first issue that I see is that unless you embed the .xcframework in the app, then the app doesn't contain the PrivacyInfo.xcprivacy file. Being that the framework is already statically linked into the final app executable, embedding the .xcframework seems an odd requirement in and of itself. Secondly, consuming the binary .xcframework via SPM, Xcode doesn't even allow you to embed the static library in the final application. I have just received a report from on of our customers that they were flagged for using a "required reason" API and are not certain how to get our PrivacyInfo.xcprivacy file into their application.