Crash in URLSessionConfiguration init in Xcode 26.0 beta (17A5241e)

Question

Created Jun ’25

Replies 31

Boosts 25

Views 4.9k

Participants 23

It's not yet fully clear why and when does this crash occur, but I'm creating this post so there's a centralized thread for this.

Some hints collected so far:

The crash is occurring for existing Xcode projects opened with new Xcode 26.0 beta (17A5241e); no one's been able to reproduce on a project created in Xcode 26. I even tried creating a project with Xcode 16.2 and open it in Xcode 26, but it's all working fine there (don't have older Xcode at the moment, to try with many versions)
It crashes right at the line of code that initializes URLSessionConfiguration. If you call URLSession() without parameters (which is deprecated as of iOS 13), the session initializes without the crash.
It's NOT occurring only for libraries installed through package manages. In a project where it crashes, one should be able to reproduce by adding URLSessionConfiguration.default as the first line in didFinishLaunchingWithOptions
It crashes when running an app on an iOS 26 simulator. (I don't have a device running beta iOS 26 to test on it!) It's working fine when running the app on a simulator or a device running iOS 18 or older.

Related issue on Firebase GitHub repo: https://github.com/firebase/firebase-ios-sdk/issues/14948

Sorry to not be able to provide more info at the moment. I wanted to report this so in case someone from Apple knows about it, we could at least get some feedback or workarounds, until fix is released -- and, to prevent us all from duplicating this report in repositories of each library, as this isn't related to libraries.

Answered by DTS Engineer in 846043022

this is still an issue with Xcode 26 Beta 2 as well.

Indeed.

For the record, the ‘lead bug’ here is FB18043319, and that’s not fixed in 26.0b2.

However, we do now fully understand the problem, so there’s no need for any more bug reports about this. Thanks to everyone who chipped in here.

I don’t have any info to share as to when this’ll be fixed. If this is causing you significant grief then I suggest that you temporarily apply the workaround suggested by salla.an in this post. I just happened to bump into this issue myself last week and that workaround got me past it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

HolgerDe OP

Jun ’25

Thank you for posting this here! Our app is affected as well and I have been trying to produce a minimal example in a new project all afternoon but failed, just like you said.

To add some information: I can crash our app by simply accessing URLSession.shared or URLSessionConfiguration.default (but not by simply accessing URLSessionConfiguration.ephemeral) in the initializer of our AppDelegate.

3

Answer 2

mgalijot OP

Jun ’25

Thanks @HolgerDe, you're right; I can also confirm accessing URLSessionConfiguration.ephemeral does not crash for me. But then initializing URLSession with this configuration does crash.

PS: taking this chance to share the feedback report id: FB17876117

0

Answer 3

CreamyK OP

Jun ’25

Don't have much to add in the way of resolution but wanted to report this happening to our application as well (via the Firebase SDK).

0

Answer 4

jln19 OP

Jun ’25

Also happening in Alamofire

extension AlamofireExtension where ExtendedType: URLSessionConfiguration {
    public static var `default`: URLSessionConfiguration {
        let configuration = URLSessionConfiguration.default //Thread 1: EXC_BREAKPOINT (code=1, subcode=0x257b8318c)
        configuration.headers = .default

        return configuration
    }
}

1

Answer 5

Frameworks Engineer OP

Apple

Jun ’25

We are looking for a sample project reproducing this issue. Would anyone be able to share one? Thanks

0

Answer 6

bstillitano OP

Jun ’25

@Frameworks Engineer how do we share source code privately with you? I have a project I can share.

0

Answer 7

DTS Engineer OP

Apple

Jun ’25

how do we share source code privately with you?

The best thing to do is file a bug in Feedback Assistant, attach the project, and then post the bug number here.

See Bug Reporting: How and Why? for lots of general advice on this, but in this case we only really need the test project.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 8

jcabrido OP

Jun ’25

My app is experiencing this crash in the Xcode26 beta and I just want to add that for our project, changing the minimum deployment target to iOS 26.0 resolved the issue, though this feels like a workaround

2

Answer 9

mgalijot OP

Jun ’25

GitHub user salla-andre figured a workaround: https://github.com/firebase/firebase-ios-sdk/issues/14948#issuecomment-2960860573

Add

nw_tls_create_options()

at the top of didFinishLaunching!

I'm still not able to provide a sample project as this only crashed for me on client projects, which I can't share.

13

Answer 10

fernandofromguarulhos OP

Jun ’25

Make sure you don't have other dependencies doing a method swizzling on the URLSessionConfiguration.default. I was having exactly the same crash on our app and found the Hyperconnectivity package was doing swizzling on URLSessionConfiguration.default like this:

+(void)load
{
    orig_defaultSessionConfiguration = (SessionConfigConstructor)HTTPStubsReplaceMethod(@selector(defaultSessionConfiguration),
                                                                                          (IMP)HTTPStubs_defaultSessionConfiguration,
                                                                                          [NSURLSessionConfiguration class],
                                                                                          YES);
    orig_ephemeralSessionConfiguration = (SessionConfigConstructor)HTTPStubsReplaceMethod(@selector(ephemeralSessionConfiguration),
                                                                                            (IMP)HTTPStubs_ephemeralSessionConfiguration,
                                                                                            [NSURLSessionConfiguration class],
                                                                                            YES);
}

I temporarily fixed the crash by disabling the package

0

Answer 11

fernandofromguarulhos OP

Jun ’25

@Frameworks Engineer for me it only crashed when I had another dependency doing method swizzling. I have a Feedback with the complete stack FB17891691

0

Answer 12

RCP_at_Socure OP

Jun ’25

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.

0

Answer 13

fernandofromguarulhos OP

Jun ’25

Here the crash stack

Thread 2 Crashed:
0   ???                           	       0x1dee7618c ???
1   ???                           	       0x1dee73d14 ???
2   ???                           	       0x1dee73b8c ???
3   ???                           	       0x1dee73b68 ???
4   ???                           	       0x1dee73c98 ???
5   ???                           	       0x1dee7d1bc ???
6   ???                           	       0x1dee7d8e4 ???
7   ???                           	       0x1dee73b8c ???
8   ???                           	       0x1dee73b68 ???
9   ???                           	       0x1dee7d888 ???
10  ???                           	       0x19138fefc ???
11  ???                           	       0x19139224c ???
12  ???                           	       0x190918618 ???
13  ???                           	       0x1909184b0 ???
14  libdispatch.dylib             	       0x1802364b0 _dispatch_client_callout + 12
15  libdispatch.dylib             	       0x18021e3d4 _dispatch_once_callout + 28
16  ???                           	       0x19091b94c ???
17  CFNetwork                     	       0x180fe856c -[NSURLSessionConfiguration initWithDisposition:] + 356
18  CFNetwork                     	       0x180fe8b04 __56+[NSURLSessionConfiguration defaultSessionConfiguration]_block_invoke + 36
19  libdispatch.dylib             	       0x1802364b0 _dispatch_client_callout + 12
20  libdispatch.dylib             	       0x18021e3d4 _dispatch_once_callout + 28
21  CFNetwork                     	       0x180fe8818 +[NSURLSessionConfiguration defaultSessionConfiguration] + 64

0

Answer 14

bstillitano OP

Jun ’25

Worth noting here that on a project that this was happening on for me, I migrated away from using an AppDelegate and it resolved the issue as well. No need for the nw_tls_create_options() once moving away from an AppDelegate

1

Answer 15

salla.an OP

Jun ’25

Actually I just chose the nw_tls_create_options() method without a special reason.

To workaround this you just need to call ANY Network method, not this one necessarily. For instance, calling nw_endpoint_create_url("www.google.com") will have the same effect.

Maybe it’s something related about how the Network lib instantiates its internal properties or some concurrency problem with the lib. If I remove the call I make to the Network lib (NWParameters.PrivacyContext.default) from my static framework, it also fixes the problem.

Static frameworks referencing the Network lib seems to be the culprit.

1