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.

When in doubt, check the framework header directly, you can find the one you want in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/MediaToolbox.framework/Versions/A/Headers/MTProfessionalVideoWorkflow.h

NSDictionary doesn't make any guarantee about order, it's a data structure that is not meant to be ordered, so it's not a surprise the result looks like that. There is a NSJSONWritingSortedKeys option if you want things in lexicographic order when converting from NSObjects to json. If not you will have to use an NSArray.