Hello guys, We are receiving feedbacks from various users facing kernel panics when using one of our products. Our analysis of the crash reports shows that all panic traces report the exact same panic cause: Sleep transition timed out after 35 seconds while creating hibernation file or while calling rootDomain's clients about upcoming rootDomain's state changes. Various versions of MacOS are affected, including the latest ones. It seems obvious, with the user feedbacks we have, that our product plays a role in those KP. But we can seen on the forums that it is not specific to our users. Our product does use not-so-common APIs (it uses the EndpointSecurity API in AUTH mode for some events notalby), and it can have a pretty important IO activity on disk, with a memory footprint of multiple hundreds of MB. My understanding of hibernation is that when it happens, the applications are frozen (i.e. with no access to the CPU), and thus that no endpoint security event would be generated during the hibernation process. As a consequence, we did not implement any specific behavior for hibernation. Do you think it is a valid assumption ?

Since we migrated to Xcode 15.4, we are facing a crash of one of our application on Intel machines due to a missing symbol error: Symbol not found: _$s7Network13NWPathMonitorCMa This symbol is used by one of our internal SPM packages, targeting macOS 10.13, but the code using it is tagged @available(macOS 10.14.0, *). After investigating, I can fix this crash by targeting 10.14 instead of 10.13 in package manifest. Sadly, this is not an option, as this SPM is used by products that supports macOS 10.13. The linked libraries reported by otool differs significantly between the build targetting 10.13 and the build targetting 10.15: The build targetting 10.13 weakly links links to /System/Library/Frameworks/Network.framework/Versions/A/Network The build targetting 10.15 does not link to Network.framework, but does link (not wealky) to a library that didn't appear before /usr/lib/swift/libswiftNetwork.dylib In previous builds that were performed by Xcode 14, the produced binary was weakly linking to @rpath/libswiftNetwork.dylib What can I do to work around this problem introduced by Xcode 15 ?