macOS 14 SDK sets NSView clipToBounds property to NO by default. So it's wrong to use dirtyRect like that, because it could extend outside the NSView bounds.

NSView clipToBounds is set to NO by default now. See the others similar thread in the [AppKit] category on this forum, and the AppKit release notes of macOS 14.

Probably it's not a bug, just the new behaviour. When linking to the macOS 14 SDK, the clipsToBounds property of NSView is set to false. Either update your drawing code, or set it back to true. See the macOS 14 AppKit release notes for some info.

If the app is sandboxed, it won't have permission to replace itself. Sparkle works around this issue by using a non sandboxed helper. It's open source, so you can check exactly what's Sparkle is doing and replace it if you want.

Xcode 15 / macOS 14.

That's possible, but you need the Pro Video Formats package installed and you have to call MTRegisterProfessionalVideoWorkflowFormatReaders() too. Probably you already found out, but if someone else needs this info now there is an answer.

That part of the QuickTime format has been deprecated, and doesn't work anymore with modern QuickTime (version 10 and later). Actually browser plug-ins have been deprecated and removed too. The good news is that HTML and javascript have all the tools needed to created such thing nowadays.

On which machine is it failing? Did you try with an higher resolution video?

Is the size of the destination buffer right? In your example is your source 640x480? If so the destination buffer should be 480x640. VTPixelRotationSession works correctly in my app.

You can move your crosshairs to a separate CALayer or to multiple one, so you don't have to redraw anything but just changed the coordinate of such layers. No need to redraw the diagram each time. Or use CATiledLayer or something similar.

Yes.

Like the message says, you have to had NSNumber to the set of allowed classes that you pass to NSKeyedUnarchiver.

Xcode's clang is an Apple maintained fork, so it won't be exactly the same as the main clang, and I guess libc++ is different too.

Apple rewrote the whole layout and text framework used by Cocoa views. The rewrite was incremental, so some features were not yet available on some previous macOS versions, and some behaviours may differ. Anyway, setting a layout manager makes it use the old layout and text framework, so you will have the same behaviour as in older macOS versions. You can either try to find a way to get the wanted behaviour with the new framework, or keep using the old one for now I guess. I think there is some info on the AppKit release notes and in various WWDC sessions.

If it's not compiled in, it means there is no reference to it in the binary at all. So it can't be an issue.