After some experimentation with copying multiple DriverKit SDKs into /Applications/Xcode.app/Contents/Developer/Platforms/DriverKit.platform/Developer/SDKs/DriverKit, it's become clear that Xcode only supports the DriverKit version that ships with it. There is no way to configure an alternative SDK within a project and changing to a different one results in strange build warnings and errors.
This begs the question - how are developers supposed to develop and support dexts? Here's one example scenario: SCSIDriverKit introduced a breaking change in DriverKit 24.4 (macOS 15.4 and Xcode 16.3) due to a new feature. Once a dext is built against that kit, it will not function on macOS 15.0-15.3 whether that feature is implemented or not. We found a similar thing with NetworkingDriverKit as well. So, over the course of maintaining a Sequoia product while working in Sequoia itself, simply updating Xcode breaks the product. Not to mention trying to maintain a Sequoia product in Tahoe when it is released.
- How is this a good developer experience?
- Are developers resigned to having a myriad of Xcode versions which may require booting into multiple macOS versions to use? That would in turn produce a myriad of product versions that would need to be deciphered by the user or an installer?
- Shouldn't developers be able to use the latest tooling while still being able to produce products for OSes that are just a year or two old?
- Or should DriverKit files be conditionalized so configuring a deployment version in Xcode actually builds the right thing even with the latest SDK?
I just don't get it. Help me understand. Replacing kexts with dexts seems like a development nightmare.
After some experimentation with copying multiple DriverKit SDKs into /Applications/Xcode.app/Contents/Developer/Platforms/DriverKit.platform/Developer/SDKs/DriverKit, it's become clear that Xcode only supports the DriverKit version that ships with it. There is no way to configure an alternative SDK within a project, and changing to a different one results in strange build warnings and errors.
Yes, that's correct. Xcode has never supported moving SDKs between versions.
This begs the question - how are developers supposed to develop and support dexts?
The way it's supposed to work is that DEXTs built on the latest SDK should work fine on earlier systems, just like DEXTs built on older systems work fine on newer systems.
That's because this:
Here's one example scenario: SCSIDriverKit introduced a breaking change in DriverKit 24.4 (macOS 15.4 and Xcode 16.3) due to a new feature.
Is that a real example or a hypothetical? If it's a real example, please post the bug number so I can follow up on it.
Once a dext is built against that kit, it will not function on macOS 15.0-15.3 whether that feature is implemented or not.
...should not happen. As long as a DEXT does not call methods that are not implemented by older systems, a DEXT built with a newer SDK should work fine on those older systems.
We found a similar thing with NetworkingDriverKit as well. So, over the course of maintaining a Sequoia product while working in Sequoia itself, simply updating Xcode breaks the product.
This was a bug that has been fixed. However, what's worth understanding is that the bug here wasn't actually in Xcode as such. The break here wasn't just that DEXT built with the latest SDK wouldn't run on older systems, it's that DEXT built with our older tools wouldn't run on the new system EITHER. For obvious reasons, that's not an acceptable situation, which is why the bug has been fixed.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
