On macOS 10.15, if the user does the following: install version 1 of an app to /Applications and activate an embedded driverkit system extension copy a newer version 2 of the app & extensions to /Applications, overwriting the original when the version 2 app tries to activate its updated extension, it gets the error OSSystemExtensionErrorUnknown. Furthermore the user can not delete the app, as the finder now hangs when it tries to deactivate the extensions - presumably because the copy has damaged the original installation. Similarly, "systemextensionctl uninstall" also hangs. As far as I know, the only ways to recover are: issue the shell command "systemextensionctl reset", which is a bit drastic force-quit the Finder, reboot and then delete the app before reinstalling and running Any suggestions as to how to work around this? I have tried to issue an explicit deactivation request from the updated app, but unsurprisingly this also fails with ErrorUnknown.

With kexts, macOS would evaluate all candidate drivers and then load the most appropriate for the hardware. But with dexts, what I observe is that all matching drivers are started. So for example, if I create two distinct dexts that will match to a USB device, both are loaded as well as any kext that also matches the device. This means that it appears to be impossible to implement the equivalent as a codeless kext in DriverKit. How can I avoid this race condition, and ensure that the dext takes priority over a kext? FWIW, in the specific case we have an external device that when placed in to an update mode gets assigned to the macOS Bluetooth driver (macOS 11.2 kext), which then try to use it as a wireless adapter. This stops our app from running and also breaks the Mac's Bluetooth connections in the process. We want to stop the Bluetooth stack from binding to this device.

I need to migrate functionality previously implemented in a kext probe() function to DriverKit. However, I am unable to find an equivalent method. The probe() method was used to tighten the matching criteria over that possible with the Info.plist, by performing additional checks on USB configuration data. I can implement this in the driver's Start() method, returning an error if the additional USB checks fail. However, this appears to leave the driver instance in a broken state - for example, the driver's free() method is never called to release resources allocated in init(). What is the correct way to implement probe() functionality in DriverKit?