Many thanks for your swift reply. I have attached updated crash logs to a separate post in this topic. Please let me know if there is anything else I can do.

Looking at crash logs from our other application that shares a big chunk of the codebase of this one, I see more SIGSEGV crashes caused by _dispatch_source_set_runloop_timer_4CF. For example, in the callstack of another SIGSEGV crash I see _CFURLStorageSessionCopyCache, followed by 3x _CFNetworkSetATSContext, after which a crash occurs in _dispatch_source_set_runloop_timer_4CF. Without knowing the implementation of that function, could it be that some GCD resources have been exhausted, resulting in the segmentation violation?

Thank you for the analysis. Is there any news regarding this issue? We still seem to experience it on the latest iOS release (15.4.1). Are there any known workarounds? We are considering reimplementing our networking stack using SwiftNIO, but this will take some time

Bug number is 10663350 (sorry only got around filing one just now). I have shared extra information regarding a thread that contains application-specific code, that is consistently in a mach_exception_callback function of PLCrashReporter. I see the same in thread 8 in a similar crash report here: https://developer.apple.com/forums/thread/112915. Perhaps the issue is in PLCrashReporter, or in the interplay between PLCrashReporter and CFNetwork? Is there any progress on this issue from Apple side?

No. Still occuring in iOS 16.4.1.

My hypothesis is that UIAppearance selectors cause this crash when an image constructed with +[UIImage new] is used as the argument value in an appearance selector. I will change this to using a transparent PNG to see if this solves the crash. It will take some time though (maybe 2 months) before users have updated the application.

Sounds plausible. No luck resolving it. I still see it, but not very often. I know on my phone that when I kill an app and immediately relaunch it, this app always crashes (regardless of which app). Perhaps it's this crash that is being logged? Clearly this is an issue in iOS. Is this the crash that you refer to?

Same issue here. Interestingly only my SPM test target fails. My library target succeeds.

Is there a workaround available without having to step away from generics? I'm also running into this issue and I use multiple models that conform to the same protocol, it would be painful to resort to concrete queries for those. Also I filed a dupe as FB16866464