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.

Your original.mov has got crazy values in the "ctts" atom. HEVC and H.264 has got a frame type called B that can reference previous and future frames, so they are stored out of order. This means the presentation timestamp (pts) and the decode timestamp (dts) are different, and the offset between the two is stored in the mov/mp4 ctts atom. Some players ignore this atom and uses the info stored in the video bitstream, so they might not display the issue. I would check the pts/dts of the sample buffers you are passing to AVAssetWriter.

The alert is shown only if there is a quarantine flag set on the app/executable. Homebrew doesn't add such flag.

Does it happens in Xcode 14.3?

Is that a space before "MetalHUDEnabled" or it's just Xcode indenting things in a weird way?

My understanding is that Apple takes 30% of every digital good sold inside your app. But check the App Store rules for confirmation.

Either crash or throw an exception probably. Did you ever test on 10.10?

I guess it depend where are you using those buffers. If you are encoding them with VideoToolbox or AVFoundation it will probably convert them to the appropriate colourspace set in the encoder, or maybe it will completely ignore it. Try and see.

Is there a quit menu item in the menu extra?