MoltenVK simply calls the Metal API in the end, there isn't any issue at all from an App Store review point of view. The main issues are that it adds an overhead over calling Metal directly, and that it might be missing some of the newer features available in Metal, but it's up to you and to what you actually needs are whether it's could work for your app or not.

MoltenVK doesn't use any private API, and it's already used on both the iOS and macOS App Store. You shouldn't have any issue.

There is nothing weird in MoltenVK, it's just another library that calls the Metal API.

Platforms tab, press the + button.

You are trying to link some libraries, installed by homebrew, that are compiled only for arm64.

TextEdit on Ventura uses TextKit 2, probably it's a bug. It would be better to create a feedback in Feedback Assistant.

Code signing is needed to make the binary run if the binary is arm64. But you don't need a paid developer id certificate to code sign, you can generate your own certificate or use a default ad hoc one. However, to avoid the untrusted modals you need to code sign the binary with a developer id certificate (99$ a year) and to notarise it. Gatekeeper (a name for a cluster of checks on the binaries) used to run only if there was a quarantine flag set, this flag is set by the application that downloaded the file from the internet so if it was used one application that did not set it, there would have been no check at all. This changed recently and even not quarantined binaries are checked sooner than later.

/usr/bin/make is a shim, it will use the make version of the currently selected Xcode toolchain (see xcode-select command or Xcode preferences). The second issue is caused by minimum deployment target not being set. See https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html

You are not doing anything wrong. That's an issue of NSOpenPanel and there nothing you need to do, it's up to Apple to fix that.

Same as before. OpenGL 4.1 plus a bunch of extensions if I remember correctly. It's deprecated, so it might be removed in the future, but probably not anytime soon. There are a working open-source implementation of OpenGL ES3 running over Metal, and some in-work progress to run OpenGL on Metal. So even if it will be removed (in a far future) there will be a way to run old OpenGL code in a way or another.

I I remember correctly Safari (and so WebKit) removed support for NPAPI plugins years ago. So no there is no way to enable a Java plugin to run Java applets.

VTDecompressionSession can decode a large number of formats, including HEVC. You can also list the available decoders to be sure what are the supported format on a particular device.

The documentation says: In macOS, in order for the system to provide a default Metal device object, you must link to the Core Graphics framework. You usually need to do this explicitly if you’re writing apps that don’t use graphics by default, such as command line tools.

Try to wrap the content of the procQueue.async closure in an autoreleasepool. The queue has got it's own autoreleasepool that don't always drain after each closure is executed probably.

I don't think so, that would make the entire feature pointless. It was made to shown users that something added a login or background item, so it being always shown is by design.