Because when not dragged/moved the app runs from a randomised location, maybe this breaks something inside your app. Some info on https://developer.apple.com/forums/thread/724969

The mp4 file format has got a creation data and modified date field that are set to the date of when it was created, so those will be different. You should check if the actual audio data is the same. Or you can use some app like l-smash to dump the structure of the mp4 file and compare the actual differences.

Xcode 14.3 has already been released yesterday.

Is there a quit menu item in the menu extra?

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.

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

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

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

Does it happens in Xcode 14.3?

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

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.

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.

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.

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.

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