Hello @eskimo, I am experiencing exactly the same issue. I use UIDocumentPickerViewController to select files; receive urls in didPickDocumentsAt:; fopen these files to read; I select a file from Downloads; When I build it with Debug configuration and run it on my device – I can read the contents of these files. When I build it with Release configuration and run it on the same device – I get permission errors. In Debug configuration startAccessingSecurityScopedResource has effect – I can't access the file without it. Does not matter if I'm attached with a debugger or not, it's the build configuration that matters. UPDATE: ... so I diffed xcodebuild -showBuildSettings -configuration {Release,Debug}, and turned out it was SWIFT_OPTIMIZATION_LEVEL. With -Onone (Debug) I could read the files, but with -O (Release) I could not. The issue with my code turned out to be trivial :) My code: func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) { urls.forEach { assert($0.startAccessingSecurityScopedResource() } // ... I guess my assert(...) expression got stripped because of the optimization. // that worked: _ = $0.startAccessingSecurityScopedResource()

Hello, I am experiencing a similar crash while developing my macos app. I've found this post: https://www.nutrient.io/blog/dynamic-linking-crash-xcode-16/. It recommends disabling Thread Performance Checker. It seems to have an effect, wonder if it's placebo or not. My crash was kinda inconsistent. In my app I add overlays on videos using AVVideoCompositing, and I do [CIContext render:toCVPixelBuffer:]. On 30-second videos it was fine, but failed on longer ones. I tried disabling Thread Performance Checker and I could successfully render 2 "long" videos in a row without a crash. I wonder if it's placebo effect or if Thread Performance Checker and libRPAC have known flaws that may cause crashing.

Try that: https://developer.apple.com/forums/thread/79025?answerId=710450022#710450022 https://stackoverflow.com/a/71865625/1837959

These annoying messages come from libboringssl.dylib :: boringssl_metrics_log_event: int boringssl_metrics_log_event(...) { ... if (g_boringssl_log != nil && os_log_type_enabled(g_boringssl_log, OS_LOG_TYPE_ERROR) { os_log_error(g_boringssl_log, "%s(%d) Failed to log metrics", "boringssl_metrics_log_metric_block_invoke", 151); } ... } An easy way to silence these messages is to nullify g_boringssl_log. g_boringssl_log is a global variable: os_log_t g_boringssl_log = nil; It gets initialized in boringssl_log_open: void boringssl_log_open() { static dispatch_token onceToken = nil; dispatch_once(onceToken, ^{ g_boringssl_log = os_log_create("com.apple.network", "boringssl"); }); } IMO the easiest solution to nullify g_boring_ssl is to skip the execution of dispatch_once. That could be achieved with setting a breakpoint to __boringssl_log_open_block_invoke with action thread return. This breakpoint will be called once thanks to dispatch_once, but the function's body will not be executed because of immediate thread return. So g_boringssl_log will never be initialized, and there will be no logs in the Console.