Following this thread (https://developer.apple.com/forums/thread/674277?answerId=662833022#662833022), it appears that this is a 14.5 simulator bug. Running iOS 14.5 on an actual device should work fine, in case this helps anyone.

My colleagues and I have seen the same problem on x86 MBP's. No network activity works on iOS 14.5 under simulator. Mobile Safari is unable to connect to any website http or https.

These are REST endpoints requiring authorization headers, so it's hard to test in Safari. But my main question was whether there's something I can do programmatically in my apps to be able to capture more details when the app encounters SSL errors like this. I just found other posts that lead me to URLError, which I think has the details I'm looking for. In my own testing, I've seen these errors: _kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9816, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11]}}, _kCFStreamErrorCodeKey=-9816 Not sure if this is the only error. But this suggests the server is closing the connection. So now I just have to find out if the server ever actually got the connection request...

Thanks for the reply. I'm just using self to store some of the contents from NWPath and they are properly protected for asynchronous access using semaphores. So far I haven't found a good way to stress test this callback, other than to plug/unplug an ethernet cable on my development system while running under simulator. But if I find a way to reliably reproduce this, I'll provide a proper crash report. In the mean time, I can include some screenshots from the crash reporter... Any tips you can provide would be greatly welcomed! In case it matters, we have several different libraries each creating their own instance of NWPathMonitor within a single app. They all appear to have proper thread safety precautions. Unfortunately there doesn't appear to be a way distinguish the different instances by looking at the stack traces.