To avoid such things randomly exploding, it's better to add a three letter prefix to each category method of system classes. Objective-C has got no namespaces, so if you add a category to a system class, and then Apple implements something with the same name, bad things happen™. Maybe Apple's symbol it's in a library that's not loaded in the simulator? The simulator it's not an emulator, so often there are many differences.

You aren't shipping any H.264 decoder or encoder in your app, so there is no fee to pay. However, if you want to be as sure as possible, ask a lawyer.

There is no way to know until Apple actually releases a chip that supports it.

There is no guarantee. It would be better to keep a reference to the previous CVPixelBuffer, so will be sure it's the one you want.

That's the accent color, you can see it in your app Info.plist, check https://developer.apple.com/documentation/bundleresources/information_property_list/nsaccentcolorname for more info.

Yes that seems backwards. macOS 14 SDK defaults to false, it doesn't clips to bounds.

Maybe set up a single CI server can checkout and compile a repository provided by the developer. So the certificate will be only on that server, and it won't be accessible by anyone.

What's the reason for setting locale? Unless you are using some old C standard library or posix API, there is usually no reason to change it.

You won't get any official answer about the App Store policies here, but the App Store reviewers look at the actual app experience, not at the way you built it. Each update you send will be reviewed as usual, it doesn't matter if you change the whole thing or not.

NSTableCellView are reused, to avoid wasting memory. So you will have to keep this in mind when designing the way you update the cells. One way to is subclass NSTableCellView, add a property that contains the object doing the work, and then observe the progress of the object. This avoid having to find the right cell everything. When a cell is reused, just swap the object and refresh the observers.

The AppleTV 4th doesn't have an hardware HEVC decoder, so decoding HEVC is limited to software, maybe there isn't enough CPU power to decode it when FairPlay DRM is used, or there is some arbitrary check that disables it.

MetalCPP is simply an header wrapper around the Metal Objective-C API. It's already possible to call every Objective-C API from C++, by using Objective-C++ in a .mm file.

Are you sending setNeedsDisplay to the right view?

How are you getting the CVImageBufferRef? Are you releasing it after you are done? Try to run the clang static analyzer in Xcode.

From my experience, VideoToolbox dictionaries are often incomplete or wrong. Anyway, yes, H.264 and HEVC encoders and others are always hardware accelerated on iOS.