Note: This is an initial draft of a post attempting to describe the details of how to sign DEXTs. While you are free to post general questions or comments, please post any questions about your specific issues as a separate thread.
The question of "how do I sign a DEXT" comes up a lot, so this post is my attempt to describe both what the problems and the best solutions are. So:
The Problems:
-
When DEXTs were originally introduced, the recommended development signing process required disabling SIP and local signing. There is a newer, much simpler process that's built on Xcode's integrated code-signing support; however, that newer process has not yet been integrated into the documentation library. In addition, while the older flow still works, many of the details it describes are no longer correct due to changes to Xcode and the developer portal.
-
DriverKit's use of individually customized entitlements is different than the other entitlements on our platform, and Xcode's support for it is somewhat incomplete and buggy. The situation has improved considerably over time, particularly from Xcode 15 and Xcode 16, but there are still issues that are not fully resolved.
To address #1, we introduced "development" entitlement variants of all DriverKit entitlements. These entitlement variants are ONLY available in development-signed builds, but they're available on all paid developer accounts without any special approval. They also allow a DEXT to match against any hardware, greatly simplifying working with development or prototype hardware which may not match the configuration of a final product.
Unfortunately, this also means that DEXT developers will always have at least two entitlement variants (the public development variant and the "private" approved entitlement), which is what then causes the problem I mentioned in #2.
The Automatic Solution:
If you're using Xcode 16 or above, then Xcode's Automatic code sign support will work for most cases. The specific flow for that is:
-
Change the code signing configuration to "Automatic".
-
Add the capability using Xcode.
If you've been approved for one of these entitlements, the one oddity you'll see is that adding your approved capability will add both the approved AND the development variant, while deleting either will delete both. This is a visual side effect of #2 above; however, aside from the exception described below, it can be ignored.
Similarly, you can sign distribution builds by creating a build archive and then exporting the build using the standard Xcode flow.
The Manual Solution:
NOTE: Unfortunately, I'm not confident that the flow I described below actually works today (12/5/2026). I'm leaving the information below as a useful starting point, but I'm afraid this case my require resorting to command line code signing.
The approach above works for all DriverKit Entitlements, with two exceptions:
- USB DriverKit
- PCI DriverKit
Both of those cases involve customized entitlement values, which then creates problems when attempting to distribute builds. Note that this is specifically about build distribution, NOT development builds. All development builds should use the flow above.
The solution for these two cases is manual code signing with the export flow. Here is exactly what the flow looks like:
-
Select the build you've archived in the Xcode Organizer and select "Distribute App".
-
Choose "Custom" from the set of distribution methods.
-
Choose the type of distribution (App Store or Developer ID).
-
Choose whether to Upload or Export.
-
Choose "Manually manage signing".
-
Provide a profile for each of the objects that make up your app bundle. See the "Provisioning Profiles" section of Account Help for detailed instructions on that process.
-
Continue through the rest of the process to finish build creation.
Finally, a note about both of the processes above. Quoting myself:
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware