NSToolbarItem manages its own style when isBordered is set to true (for example in your code is not manually adding a NSButton subview). On the other hand, your SwiftUI code is manually adding a Button instead, and probably NSToolbarItem isn't smart enough to recognise the pattern and fall back to its internal NSButton subclass. I don't know if there is a workaround, I would send a feedback of the issue and keep avoid NSHostingView for simple toolbar buttons, it doesn't like there isn't any advantage in SwiftUI for such things anyway.

AVFoundation/QuickTime Player have artificial restrictions on what it can read. Safari brings its own webm demuxer, and the VP9 decoder is not enabled by default, so to playback it in your on app (at least from a .mp4 file), you need to call VTRegisterSupplementalVideoDecoderIfAvailable(kCMVideoCodecType_VP9) I think at the moment the only way to read a WebM file in AVFoundation is stored write your own demuxer using the MediaExtension framework ( https://developer.apple.com/documentation/mediaextension )

https://developer.apple.com/documentation/macos-release-notes/macos-26_6-release-notes

I don't know, but an actual port will require a manual conversion to Metal, and automated shader conversion maybe, and manual ones for some shaders, so something not working in D3Metal will make little difference.

I think you are misunderstanding the goal of GPTK. The D3DMetal library is not meant to be shipped with your game, it's just an environment to do a preliminary test. Or am I misunderstanding your question?

I can't speak for Apple, but they seldom give any official reassurance. If they wrote that Rosetta 2 will be around for virtualization and for some older games, that's all it will work for. If your app is not a game, it's time to make a native version, everything else is just delaying the inevitable.

Everyone and their dog are vibe coding slop and sending it for review. And this is the result.

Are you subdividing some work between different thread? The M4 Max has more cores, and it might expose some multi-threaded issues that aren't visible with fewer cores. Or there is some random out of bounds writing somewhere that for some random reason doesn't cause a crash on your Mac. Try to run it address sanitizer first, and then with thread sanitizer.

Because NSArray can contain only objects, and NSNumber is the class that has been used to box bools, integers, floats, and double since a long time ago.

Like the message said, NSKeyedUnarchiver will require a complete list of all possible types for better security in the future.

The destination folder should be configurable, not hard-coded to the Documents folder.

https://developer.apple.com/documentation/security/accessing-files-from-the-macos-app-sandbox

Is your app sandboxed? If so, the only way is to show a NSOpenPanel and ask the user to select the Documents folder (or any other folder). Showing an open panel and asking the user where to put the files is the best option even if the app is not sandboxed. Please don't litter the Documents folder with random things by default.

Attach them after the CVPixelBufferCreate call. The attributes dictionary that can be passed to CVPixelBufferCreate is just to setup the pixel format, not to attach other attributes. So call CVBufferSetAttachments after the CVPixelBuffer is created and set them. P.S.: modifying CVPixelBuffer attributes is quite expensive, do it only as needed.

Yes, there are some borders. So just make the image you insert into icon composer a bit smaller, and that's it. The colors look the same here, but it could be your original image hadn't a color profile assigned, and it looked differently on a DCI-P3 display. Assign a color profile before importing it in Icon Composer.