Same issue here. Not only is the image on iOS always black when on macOS it displays as expected, but on iOS some images are also displayed with a slightly wrong aspect ratio, as demonstrated by this code: import SpriteKit #if os(macOS) import AppKit #else import UIKit #endif class GameScene: SKScene { override func didMove(to view: SKView) { let systemImage = "square.and.arrow.up" let width = 400.0 #if os(macOS) let image = NSImage(systemSymbolName: systemImage, accessibilityDescription: nil)!.withSymbolConfiguration(.init(hierarchicalColor: .white))! let scale = NSScreen.main!.backingScaleFactor image.size = CGSize(width: width * scale, height: width / image.size.width * image.size.height * scale) #else let image = UIImage(systemName: systemImage)!.applyingSymbolConfiguration(.init(pointSize: width))!.applyingSymbolConfiguration(.init(hierarchicalColor: .white))! #endif let texture = SKTexture(image: image) print(image.size, texture.size(), image.size.width / image.size.height) let size = CGSize(width: width, height: width / image.size.width * image.size.height) addChild(SKSpriteNode(texture: texture, size: size)) } }

Thanks, I filed FB15081598.

Thanks for the log, it looks like it is truncated, and in this case it would be helpful to see the registers at the bottom. That's the complete contents of the .ips file I found in the Console app. I have no idea why it is truncated. How can I find out why it's truncated and how to produce a full report?

[quote='802657022, deeje, /thread/763173?answerId=802657022#802657022, /profile/deeje'] FWIW, early in my SceneKit days, I experienced similar crashes, and solved it by refactoring my code to add and remove SCNNodes only in main thread. [/quote] Thanks for the suggestion, but I already solved these kind of crashes a long time ago. I'm already doing scene changes on the main thread.

[quote='802655022, DTS Engineer, /thread/763173?answerId=802655022#802655022'] Acquiring crash reports and diagnostic logs can help you retrieve the crash report [/quote] Thanks. Here's the symbolicated crash report. It seems that it is indeed caused by the overlay SpriteKit scene. Crash report

Where can I find the full (symbolicated) crash log? I don't have any relevant crash reports in the Console app. The crash is happening while debugging the app in Xcode. Here's a screenshot of all the expanded threads:

[quote='802429022, DTS Engineer, /thread/762421?answerId=802429022#802429022'] You mention AppKit above, but also iOS, so I'm unclear on what your app's target platform is. [/quote] Sorry for the confusion. It's a macOS app. I just thought the contents of the bridging header could be meaningful, and I wanted to explain why I'm redeclaring enum vtype even if it's available on macOS (it's because it's not available on iOS, even though getattrlistbulk is, so in order to have the macOS and iOS versions as similar as possible I declare that for both targets).

[quote='802017022, DTS Engineer, /thread/762421?answerId=802017022#802017022'] any C++ code running within your process could cause the above [/quote] Do you mean that such code would have to be in its own .cpp file, or would it be sufficient to call it from a .swift file? Apart from the bridging header, my project only contains Swift files. This crash only seems to be happening to a couple users and it never happened to me, so I don't think I would be luckier trying to reproduce it on a smaller tester app. I guess I'll never find out unless macOS or Swift (I'm not sure which one is responsible here) shows more meaningful exceptions.

Thanks. Does that mean that C++ code caused the crash? My app is written in pure Swift with a bridging header that only defines these constants needed for accessing the results of getattrlistbulk on iOS: enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VFIFO, VBAD, VSTR, VCPLX }; When causing a crash on the main thread with the following code @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { // Insert code here to initialize your application DispatchQueue.main.async { fatalError() } } } I get this stacktrace in the crash report: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libswiftCore.dylib 0x1a06b906c _assertionFailure(_:_:file:line:flags:) + 592 1 problem2 0x100d1a8e4 closure #1 in AppDelegate.applicationDidFinishLaunching(_:) + 68 (AppDelegate.swift:19) 2 problem2 0x100d1a904 thunk for @escaping @callee_guaranteed () -> () + 28 3 libdispatch.dylib 0x1907fb750 _dispatch_call_block_and_release + 32 4 libdispatch.dylib 0x1907fd3e8 _dispatch_client_callout + 20 5 libdispatch.dylib 0x19080bbb8 _dispatch_main_queue_drain + 988 6 libdispatch.dylib 0x19080b7cc _dispatch_main_queue_callback_4CF + 44 7 CoreFoundation 0x190acead4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 8 CoreFoundation 0x190a8c258 __CFRunLoopRun + 1996 9 CoreFoundation 0x190a8b434 CFRunLoopRunSpecific + 608 10 HIToolbox 0x19b23519c RunCurrentEventLoopInMode + 292 11 HIToolbox 0x19b234e2c ReceiveNextEventCommon + 220 12 HIToolbox 0x19b234d30 _BlockUntilNextEventMatchingListInModeWithFilter + 76 13 AppKit 0x1942eacc8 _DPSNextEvent + 660 14 AppKit 0x194ae14d0 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 15 AppKit 0x1942ddffc -[NSApplication run] + 476 16 AppKit 0x1942b5240 NSApplicationMain + 880 17 problem2 0x100d1aacc specialized static NSApplicationDelegate.main() + 24 [inlined] 18 problem2 0x100d1aacc static AppDelegate.$main() + 24 (<compiler-generated>:10) [inlined] 19 problem2 0x100d1aacc main + 36 20 dyld 0x190623154 start + 2476 Or where you hinting at something different?

Since this issue is still happening 3 years later on macOS 14.6.1, I stumbled again on this post and I see only now that you asked for the bug number, but unfortunately I didn't subscribe to this post back then and wasn't notified of your reply. It's FB8979522.

How do you use the Quick Look Simulator? When I run my Quick Look Preview Extension in Xcode, that app opens but it only shows a search field.

[quote='797102022, DTS Engineer, /thread/760029?answerId=797102022#797102022'] If you only want to look at the app, rather than run it, you can ignoer the whole thing: [/quote] So I ran lldb ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp\ macOS\ 12.07.2024\,\ 20.43.xcarchive/Products/Applications/MyApp.app To translate the addresses from the crash report to lldb, it wasn't sufficient to subtract the binary image base address, but I found some help at Symbolicating with LLDB. By running lldb image list which outputs [ 0] 2521131E-2080-387D-B96E-8DB6AA18E011 0x0000000100000000 ~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/Products/Applications/MyApp.app/Contents/MacOS/MyApp /System/Volumes/Data/~/Library/Developer/Xcode/Archives/2024-07-12/MyApp macOS 12.07.2024, 20.43.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp [ 1] 37BBC384-0755-31C7-A808-0ED49E44DD8E 0x00000001800b8000 /usr/lib/dyld ... I found out that there is another base address here 0x0000000100000000 (which almost looks like 0x0) that I also have to subtract. So the real offset is 0x104468000 - 0x0000000100000000 = 0x004468000 which I could set with lldb target modules load --file MyApp --slide 0x004468000 So now I can disassemble by directly providing the addresses from the crash report, and I confirm that all crash report addresses point to the correct symbol names. But when I run lldb disas -a 0x00000001044fff28 (where 0x00000001044fff28 is the address for the call to MyViewController.myModalAction in the crash report), I get this relatively short and rather obscure output: MyApp`merged @objc MyApp.MyViewController.myModalAction(Any) -> (): 0x1044ffed8 <+0>: sub sp, sp, #0x50 0x1044ffedc <+4>: stp x22, x21, [sp, #0x20] 0x1044ffee0 <+8>: stp x20, x19, [sp, #0x30] 0x1044ffee4 <+12>: stp x29, x30, [sp, #0x40] 0x1044ffee8 <+16>: add x29, sp, #0x40 0x1044ffeec <+20>: mov x19, x3 0x1044ffef0 <+24>: mov x20, x2 0x1044ffef4 <+28>: mov x21, x0 0x1044ffef8 <+32>: mov x0, x2 0x1044ffefc <+36>: bl 0x1001d6a60 ; symbol stub for: swift_unknownObjectRetain 0x1044fff00 <+40>: mov x0, x21 0x1044fff04 <+44>: bl 0x1001d6664 ; symbol stub for: objc_retain 0x1044fff08 <+48>: mov x21, x0 0x1044fff0c <+52>: mov x8, sp 0x1044fff10 <+56>: mov x0, x20 0x1044fff14 <+60>: bl 0x1001d5ee4 ; symbol stub for: Swift._bridgeAnyObjectToAny(Swift.Optional<Swift.AnyObject>) -> Any 0x1044fff18 <+64>: mov x0, x20 0x1044fff1c <+68>: bl 0x1001d6a54 ; symbol stub for: swift_unknownObjectRelease 0x1044fff20 <+72>: mov x20, x21 0x1044fff24 <+76>: blr x19 0x1044fff28 <+80>: mov x0, sp 0x1044fff2c <+84>: bl 0x100008ce4 ; __swift_destroy_boxed_opaque_existential_0 at <compiler-generated> 0x1044fff30 <+88>: mov x0, x21 0x1044fff34 <+92>: bl 0x1001d6658 ; symbol stub for: objc_release 0x1044fff38 <+96>: ldp x29, x30, [sp, #0x40] 0x1044fff3c <+100>: ldp x20, x19, [sp, #0x30] 0x1044fff40 <+104>: ldp x22, x21, [sp, #0x20] 0x1044fff44 <+108>: add sp, sp, #0x50 0x1044fff48 <+112>: ret Whereas if I run lldb disas -n myModalAction I get a way longer output which contains the expected calls to my own other methods, starting with MyApp`MyViewController.myModalAction(_:): 0x1044f9578 <+0>: stp x28, x27, [sp, #-0x60]! ... Notice how the first lines of these two outputs differ: MyApp`merged @objc MyApp.MyViewController.myModalAction(Any) -> () vs MyApp`MyViewController.myModalAction(_:) What does this difference mean? The line in the crash report 13 MyApp 0x00000001044fff28 @objc MyViewController.myModalAction(_:) + 80 is the only one that doesn't make sense and couldn't possibly call the line above it.

[quote='797039022, DTS Engineer, /thread/760029?answerId=797039022#797039022'] you can use the Xcode organiser to export a development-signed version of your app [/quote] I selected the archive in the Xcode Organizer, clicked Distribute App > Custom > Debugging > Automatically Manage Signing > Export. Then launched the exported app from the Finder and in Xcode selected Debug > Attach to Process. It still gives me the exact same error as before, with the exact same Console messages. That’ll have the same code as the original app — including the same LC_UUID values — but with the code signing set up for development Does that mean that the entitlements file is actually modified when creating the archive? I ran the Terminal command codesign -d --entitlements - --xml /path/to/exported/app but it has the same entitlements as before.

I was looking forward to using lldb, but both when running the Terminal command or trying to attach from my running app in Xcode I get an error process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)) And the Console shows these messages: 3898 debugserver default 13:45:23.707652+0200 debugserver will use os_log for internal logging. 3898 debugserver default 13:45:23.708012+0200 debugserver-@(#)PROGRAM:LLDB PROJECT:lldb-1500.0.404.7 for arm64. 3898 debugserver default 13:45:23.708050+0200 Got a connection, waiting for process information for launching or attaching. 3898 debugserver default 13:45:23.708297+0200 [LaunchAttach] START 3898 vAttach to pid 605 3898 debugserver default 13:45:23.708436+0200 [LaunchAttach] (3898) about to task_for_pid(605) 3898 debugserver errore 13:45:23.708472+0200 error: [LaunchAttach] MachTask::TaskPortForProcessID task_for_pid(605) failed: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) 3898 debugserver default 13:45:23.708484+0200 1 +0.000000 sec [0f3a/0103]: error: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) err = ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) (0x00000005) 3898 debugserver default 13:45:23.719499+0200 [LaunchAttach] (3898) about to task_for_pid(605) 3898 debugserver errore 13:45:23.719532+0200 error: [LaunchAttach] MachTask::TaskPortForProcessID task_for_pid(605) failed: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) 3898 debugserver default 13:45:23.719543+0200 2 +0.011059 sec [0f3a/0103]: error: ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) err = ::task_for_pid ( target_tport = 0x0203, pid = 605, &task ) => err = 0x00000005 ((os/kern) failure) (0x00000005) and so on. The rest is attached as a text file, putting it inline in this reply shows a validation error "Your reply must include text in the body." (for which I created FB14466890). Console logs At first I tried 3 times from the Terminal, but each time the Mac stopped responding after a couple seconds and after a couple minutes restarted automatically (after the third time I created FB14466119). Xcode didn't freeze the Mac, but instead showed a button "report issue", which I clicked and automatically generated FB14466745.

Thanks for your insights. I created FB14466634 regarding the documentation. So does this mean that it would be impossible to port that sample project to iOS, since the network extension has no way of communicating with the app, i.e. it would be impossible to build an iOS app that shows network flows or allows to reject flows from real-time user input?