DriverKit entitlement eligibility for independently supporting an EOL third-party USB audio device

I am developing an independent macOS compatibility driver for the Avid/Digidesign Eleven Rack, an EOL USB audio device that does not have an Apple-silicon-compatible OEM driver. The existing hardware identifies as: Vendor ID: 0x0DBA — Digidesign/Avid Product ID: 0xB011 — Eleven Rack Transport: USB 2.0 high-speed isochronous audio The proposed implementation uses AudioDriverKit and USBDriverKit. It consists of a DriverKit system extension packaged inside a macOS control application. The USB entitlement would be restricted to this exact VID/PID. I am an independent developer and do not own the Digidesign/Avid VID. I am not manufacturing hardware or attempting to use that VID for a new USB product. The driver would only match existing Eleven Rack devices. The implementation is independently written for interoperability, and no Avid executable code would be included. I currently have a working direct user-space USB proof of concept, but I cannot properly activate and test the AudioDriverKit extension with SIP enabled without the required entitlements. Before enrolling in the paid Apple Developer Program, I would appreciate clarification on the following: Does Apple consider DriverKit development and distribution entitlement requests from independent developers supporting existing EOL hardware when the developer does not own the device’s VID? Is written authorization from the VID owner always required, or are these requests evaluated individually? Would restricting the USB transport entitlement to the exact 0x0DBA:0xB011 device affect eligibility? Is there a way to obtain an initial eligibility determination before purchasing Apple Developer Program membership? The anticipated entitlements are: com.apple.developer.driverkit com.apple.developer.driverkit.family.audio com.apple.developer.driverkit.transport.usb com.apple.developer.system-extension.install for the host application Restricted user-client access between the host application and driver I understand that the forum cannot grant an entitlement. I am trying to determine the appropriate process and whether manufacturer authorization is a prerequisite before submitting a formal request.

Answered by DTS Engineer in 902351022

Does Apple consider DriverKit development and distribution entitlement requests from independent developers supporting existing EOL hardware when the developer does not own the device’s VID?

Yes. I'm not sure we've ever explicitly said this, but our goal has never been to restrict driver development to the original hardware developer. Historically, 3rd party driver development was a significant part of our KEXT ecosystem and there's no reason DriverKit would change that.

Is written authorization from the VID owner always required, or are these requests evaluated individually?

Outside of very unusual circumstances, we don't require any specific authorization and nothing you’re describing sounds particularly unusual or concerning.

Would restricting the USB transport entitlement to the exact 0x0DBA:0xB011 device affect eligibility?

The basic answer here is that you should ask for what you think you'll need. If you only ever intend to support one device, then you should ask for that. If you plan to support several devices, then ask for that.

The grey area here is that, as the device count rises, it reaches the point where it's more sensible to simply grant the vendor entitlement instead of restricting by PID. There isn't a hard and fast "rule" for what that limit is, but if you plan to support 10+ devices, then it's certainly reasonable to just ask for the vendor entitlement.

In practice, a lot of this comes down to whatever is most practical. If you're planning to support a number of different devices from a particular vendor, but you haven't finalized the exact list and expect it to grow over time, then it's totally reasonable to simply ask for the VID match. Having you submit a request every 3-12 months as you grow your supported hardware set is busy work that doesn't really help anyone.

One thing to keep in mind here— the DriverKit entitlements control what your DEXT COULD match against, NOT what your DEXT WILL match against. This post has more detail on how this actually works, but the key point is that the kernel uses your IOKitPersonalities to determine whether your DEXT can match a given device, then checks your entitlements to see whether or not you’re "allowed" to.

The critical point there is that this means a DEXT that matches a specific device has EXACTLY the same load behavior regardless of whether it's signed with:

  • The VID/PID entitlement configuration (Specific VID/PID only)

  • The VID entitlement configuration (Specific VID, Any PID)

  • The Development entitlement (ANY USB device)

...because, in all three cases, the kernel only bothers looking at the entitlements AFTER your IOKitPersonalities has already matched with the specific device.

Is there a way to obtain an initial eligibility determination before purchasing Apple Developer Program membership?

We don’t really have a formal process for that but, based on what you've described, I don't see any reason we wouldn't approve your entitlement request.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Accepted Answer

Does Apple consider DriverKit development and distribution entitlement requests from independent developers supporting existing EOL hardware when the developer does not own the device’s VID?

Yes. I'm not sure we've ever explicitly said this, but our goal has never been to restrict driver development to the original hardware developer. Historically, 3rd party driver development was a significant part of our KEXT ecosystem and there's no reason DriverKit would change that.

Is written authorization from the VID owner always required, or are these requests evaluated individually?

Outside of very unusual circumstances, we don't require any specific authorization and nothing you’re describing sounds particularly unusual or concerning.

Would restricting the USB transport entitlement to the exact 0x0DBA:0xB011 device affect eligibility?

The basic answer here is that you should ask for what you think you'll need. If you only ever intend to support one device, then you should ask for that. If you plan to support several devices, then ask for that.

The grey area here is that, as the device count rises, it reaches the point where it's more sensible to simply grant the vendor entitlement instead of restricting by PID. There isn't a hard and fast "rule" for what that limit is, but if you plan to support 10+ devices, then it's certainly reasonable to just ask for the vendor entitlement.

In practice, a lot of this comes down to whatever is most practical. If you're planning to support a number of different devices from a particular vendor, but you haven't finalized the exact list and expect it to grow over time, then it's totally reasonable to simply ask for the VID match. Having you submit a request every 3-12 months as you grow your supported hardware set is busy work that doesn't really help anyone.

One thing to keep in mind here— the DriverKit entitlements control what your DEXT COULD match against, NOT what your DEXT WILL match against. This post has more detail on how this actually works, but the key point is that the kernel uses your IOKitPersonalities to determine whether your DEXT can match a given device, then checks your entitlements to see whether or not you’re "allowed" to.

The critical point there is that this means a DEXT that matches a specific device has EXACTLY the same load behavior regardless of whether it's signed with:

  • The VID/PID entitlement configuration (Specific VID/PID only)

  • The VID entitlement configuration (Specific VID, Any PID)

  • The Development entitlement (ANY USB device)

...because, in all three cases, the kernel only bothers looking at the entitlements AFTER your IOKitPersonalities has already matched with the specific device.

Is there a way to obtain an initial eligibility determination before purchasing Apple Developer Program membership?

We don’t really have a formal process for that but, based on what you've described, I don't see any reason we wouldn't approve your entitlement request.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

This is my first attempt at this type of development. At this time, it would only be for this one specific device, no others. What I do have going as of current is that I can communicate with the device and pass audio through to it, as well as reading the device state. The issue that I am having is that in order to go any further on my system I need the basic DEXT installed and communicating so that I can begin the advanced configuration of the driver. I am going to be working on latency and diagnostics as soon as I can get the entitlements needed to build, install and debug. Thank you for your response

This is my first attempt at this type of development. At this time, it would only be for this one specific device, no others. What I do have going as of current is that I can communicate with the device and pass audio through to it, as well as reading the device state. The issue that I am having is that in order to go any further on my system, I need the basic DEXT installed and communicating so that I can begin the advanced configuration of the driver. I am going to be working on latency and diagnostics as soon as I can get the entitlements needed to build, install, and debug.

Assuming you have a paid developer account, then you don't need to wait for the entitlement to be approved, but use the "Development Only" entitlement. See this forum post for the details.

A few other comments/suggestions:

  • DriverKit is not an easy API to work with, particularly if you're not already familiar with IOKit's kernel APIs. There's a list of documents at the start of this forum post that I'd recommend reviewing, as much of its design only really makes sense once you understand IOKit.

  • DriverKit development is kernel development, NOT app development. For example, it is entirely possible for a DEXT to panic the kernel or "wedge" in a way that makes the hardware unusable. Similarly, the general friction of working with the low-level system means that many "simple" tasks like getting a driver correctly matching often take much longer than you'd expect.

  • USB devices can also be directly controlled through the IOUSBHost Framework, as well as DriverKit. That framework only allows sending and receiving commands, not system-level integration, but that can be very useful when you're trying to understand the device’s behavior, NOT integrate with the system.

Expanding on that last point, if you're working with a device you don't fully understand, it's often much faster/easier to experiment/test with an app using the IOUSBHost Framework, then "port" that code into DriverKit once you've determined what/how something should work. Writing the same code "twice" might seem wasteful, but the reality is that the lower friction and faster test cycle of an app save FAR more time than the "extra" time required to write the same code for two different APIs.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I have requested the necessary entitlements, and in the meantime my driver and associated software is pretty much ready to go. I have at least 10 people interested in doing beta testing for me. The software and driver is exceptional in functionality and features. I am really excited to get this out there and find out what needs to be tweaked. How long does it usually take for entitlements? Can you look into this for me? request 65T2N7LR6D and JNJ5KFBK39

DriverKit entitlement eligibility for independently supporting an EOL third-party USB audio device
 
 
Q