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.

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.

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.

/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

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.

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

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

Platforms tab, press the + button.

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

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.

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.

@available requires that the symbols in the code block are available in the sdk. If you are using a previous sdk, you have to fall back to the good old C preprocessor and disable the code block. @available is not a way to make it possible to compile code that requires a newer sdk on an older Xcode version.

Try to set a constrain on the width.

Xcode ships only one SDK per platform. Xcode 14 still has the old macOS 12 SDK, while the beta had the macOS 13 SDK. This is because, just like last year and the year before, the new macOS version is still in beta, and Apple doesn't ship a beta SDK in a public release. The macOS 12 SDK allows to deploy to 10.9, the 13 SDK that was in the beta and that will be in Xcode 14.1 will allow only to deploy to 10.13 and higher.

Xcode 14 doesn't ship the macOS 13 sdk. All these changes that were in the Xcode 14 beta will be in Xcode 14.1.