It used to be possible with the pluginkit command, but it stopped working in Monterey. I’m not sure if that was deliberate or accidental. Otherwise, there is no way to do this. I would be interested in a solution too.

For others that might encounter, probably something like this to create a missing preboot:  Enter recovery and open terminal. diskutil list (to get disk for virtual apfs container to use below) diskutil  apfs addVolume disk2 apfs Preboot -role B diskutil info disk2s1 | grep "Volume UUID" mkdir /Volumes/Preboot/A579A99E-9795-4086-890E-04E2112D1E78 (UUID from previous command) diskutil apfs updatepreboot /Volumes/Macintosh HD Reboot back in to recovery so FileVault syncs up with volume. Reinstall operating system over existing. This is nondestructive. There might be a shortcut to reinstalling the OS, but this is as deep as I went.

@deep-mac Try changing your Bundle ID, run the app once from Xcode, then change it back. That should force Launchd to update the apps known code signing requirements. Launchd caches code signing requirements and sometimes that cache gets corrupted when code signing changes. Such as what might happen when deploying to Test Flight. Forking your project wouldn't work unless that fork uses a different Bundle ID.

I run in to this sometimes. launchd seems to get confused every so often if code signing changes on a binary, but the bundle ID remains the same. That could happen when moving between release and a development builds or anything else that might alter code signing without the bundle ID changing. This is not specific to Xcode launching your binary. If your binary is launched by a job in the LaunchDaemons or LaunchAgents folder, you could run in to the same situation if code signing changes. In this situation I've had to remove the Launchd job plist, reboot, then put it back. More information on this issue here: https://developer.apple.com/forums/thread/126187

To be clear, you only want to look at "Command Availability". The Availability details in the sidebar is not relevant in this context since it relates to binary APIs. Currently Mac should use Managed Preferences instead. When using Managed Preferences (MCX) payloads on Mac, make sure not to include anything sensitive. That payload will install settings to the "/Library/Managed Preferences" folder where it is easy to read them with the defaults command. They also appear in System Preferences. I wouldn't be surprised if Apple makes these iOS App Settings universal one day. MCX settings are a throwback to Open Directory and might see modernization treatment someday.

Not in RealityKit or RealityKit 2. The physics support is primitive in the current release. Although not easy, you could create your own ECS components to support for another physics engine such as PhysX.

Model I/O can do it with voxels as mentioned. Using Voxels and BSP trees don't normally produce very clean results. Unfortunately there isn't a good library to use out-of-the-box. Here is a good article/algorithm for producing cleaner meshes: http://sandervanrossen.blogspot.com/2009/12/realtime-csg-part-1.html