Thanks for your help :) I want to show the sheet "when the app launches", meaning specifically when its main window first shows after launching (it's a single window app). Since I want to present my welcome as a sheet, I need a window in which to show it, so I've tried: calling showWelcome from inside the main ViewController (as provided by the "Main" storyboard in Xcode's default app template), both in viewDidLoad (crashes) and in viewDidAppear (shows the sheet again every time the app becomes visible). from inside applicationDidFinishLaunching — doesn't work as it seems NSApplication.shared.mainWindow is not available yet at this point. Anyway as far as I can see, NSApplication.shared.mainWindow isn't great for this purpose because the user might minimise the app after launching it, but before its main window shows. I was thinking there must be a nice place in the launch lifecycle for me to call showWelcome. I was looking for somewhere that fires "once the app has launched and we have the main window to work with". I'm starting to think I will just have to put it in the main window's content view controller's viewDidAppear, and maintain an "isFirstAppearance" boolean or some such.

Just as a follow-up; I did indeed end up triggering the sheet from viewDidAppear, with some logic around it to ensure it only happens once, on first appearance. It seems to work fine. My first attempts at this failed because I was expecting presentAsSheet to work from viewDidLoad or similar; apparently it will only work once the presenting view has appeared... which still seems non-obvious to me, but it is what it is.

@Kemmor — good find! I have a 2021 MBP 16" M1 Pro with this same issue, and get the same entries in my console every time the crackle happens. In this case IINA was running: CAReportingClient.mm:508   message {     "device_is_aggregate" = 0;     "input_num_tap_streams" = 0;     "input_scalar_volume" = "1.000000";     "io_buffer_size" = 512;     message = StartHardware;     "output_avail_phys_formats" = "{ [32/96000/2 lpcm], [32/88200/2 lpcm], [32/48000/2 lpcm], [32/44100/2 lpcm] }";     "output_avail_virt_formats" = "{ [32/96000/2 lpcm], [32/88200/2 lpcm], [32/48000/2 lpcm], [32/44100/2 lpcm] }";     "output_bits_per_channel" = 32;     "output_bytes_per_frame" = 8;     "output_bytes_per_packet" = 8;     "output_channels_per_frame" = 2;     "output_device_source_list" = "Internal Speaker";     "output_device_transport_list" = BuiltIn;     "output_device_uid_list" = BuiltInSpeakerDevice;     "output_format_id" = lpcm;     "output_frames_per_packet" = 1;     "output_num_tap_streams" = 1;     "output_scalar_volume" = "1.000000";     "sample_rate" = 44100; }: (     1799591297333 ) I'm interested to know if those with older hardware / macOS versions also get the same. Just open Console.app, filter on "Internal Speaker" and then wait for the problem to occur, and see if an entry appears simultaneously.

Ah. Well that's a shame. Thanks so much for your helpful reply though! Saved me hours :)

By far the easiest way to do this is to sublaunch lsof. In my experience, this has been frustratingly unreliable. My app runs local servers (nginx, apache, etc etc) and I'm simply trying to ascertain whether the ports they require (eg 127.0.0.1:443) are already in use, as a quick "sanity check" before launching them. Prior to discovering -F (thanks for your suggestion above, I'll rewrite my lsof parsing code at some point) I was calling it like this: lsof -i +c 0 -P -n -R -sTCP:LISTEN which works 99% of the time, but that 1% where it times out is super annoying. I think it's due to deadlocks — eg I sometimes noticed lsof was spawning a second lsof, which is mentioned in the man page as one of its deadlock-breaking strategies. Would you recommend I add -b to my lsof calls to "avoid kernel functions that might block"?

Sadly that does not seem to be the cause; I checked and found that ENABLE_USER_SCRIPT_SANDBOXING is already set to "No" in my project. Thanks for your suggestion.

Wow, thanks @eskimo — you were right... as always 😆 plutil reformatted my entitlements to the following, which then worked perfectly: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.cs.disable-library-validation</key> <true/> </dict> </plist> The changes were: <!DOCTYPE moved to its own line https became http <dict> entry outdented one tab a final line ending was added (they were already in "Unix" format according to Sublime Text) Somewhat annoyingly, I can use codesign -d --entitlements - --xml /path/to/binary to print the binary's entitlement as XML, but it's not in the pedantic format which codesign itself can read.

@vslavik very glad to hear it's not just me having this problem. With Apple never giving an official OS release date, I'm stressed, because my app is visually broken, and for all I know Tahoe might be released in a week. And I didn't know for certain whether the issue is my bad code, or Apple's bad code, or something else entirely. There's a lot of uncertainty for me! Thanks for the suggested fix; I had tried to completely remove the view without success, but hopefully hiding it will work for me also!

I sometimes wonder if nobody at Apple actually uses Spaces. It's had more bugs added every year for a long time now :(