This is now being investigated by Apple. It turns out to have nothing to do with our kext as it occurs even without our kext loaded. It reproduces on Macs with Apple silicon.

Our solution is to install two copies of Xcode, version 15 and version 14.3.1. The older version is located at "/Applications/Xcode_14.3.1.app". Then the build script can just set the environment variable on the command line which causes xcodebuild: env DEVELOPER_DIR="/Applications/Xcode_14.3.1.app/Contents/Developer" xcrun xcodebuild build -configuration ......... This avoids the need for root access (which xcode-select requires) as well as ensuring that the older developer tools are only used for this one build step.

The lack of a macOS 14 installer is severely limiting our ability to test our applications and drivers with the new version of macOS. We do not have enough Macs to dedicate a separate test Mac for each of our test engineers just for testing macOS 14. Each new build of our products has to be tested on multiple versions of macOS; all of our products support macOS back to 10.14, some of them back to 10.12. In addition, we are completely blocked on testing on Intel Macs. Just some feedback from outside Apple's walled garden. Tim Standing VP Software Development Other World Computing, Inc.

Your driver can't match and out-score an Apple supplied driver until around 120 seconds after startup. Since there is an Apple supplied driver which recognizes IOMedia objects with GPT partition maps, that driver will always load, and IOKit will not load your driver, until after the 120 second time window. This behavior was introduced in macOS 10.14 - I believe for security reasons.

Is there a similar command to determine the the boot security settings on a Mac with Apple silicon? I understand that this is configured on a volume by volume basis but can't find any security settings reported by diskutil.

No, not yet...

Quinn from Developer Support gave me the answer to this one. I was building my macOS application with the wrong architecture. For ARM based Macs, the kernel and user space code using different architectures: kernel code uses arm64e and user space code uses arm64. From what I have read, the major difference is that arm64e uses pointer authentication whereas arm64 does not. Applications and other user code needs: arm64 (i.e.: -arch arm64 on the command line with xcodebuild) For kexts: arm64e (i.e. -arch arm64e on the command line with xcodebuild) To build a fat application on the command line use: xcodebuild -arch x86\_64 -arch arm64 .... To build a fat kext on the command line use: xcodebuild -arch x86\_64 -arch arm64e .... Tim

Yes, I am seeing the same problem.... still searching for an answer...

To upgrade to beta 10, I used the information from the DTK information regarding upgrading to beta 10: "Please re-run the BAU in order to access macOS 11 Big Sur beta 10. Alternatively, you can download the image via the “Download” button to the right." From this page: https://developer.apple.com/download/universal/ When I wedged my DTK Mac earlier, I had to do the recovery steps outlined here: https://download.developer.apple.com/Documentation/Universal_App_Quick_Start_Program_Resources/DTK_Release_notes.pdf Hope this helps. Tim