How to deliver a USBDriverKit driver in an SDK or Framework for sale to third parties?

Question

Created 10h

Replies 2

Boosts 0

Participants 3

I have a product that currently communicates to a piece of proprietary Medical hardware via USB. We have a driver created with USBDriverKit that is a hard requirement for this product to function.

Currently, we are delivering an iPadOS application that utilizes the driver. Our next step is to create an SDK that includes all of the Frameworks and the driver utilized by the application.

Since the driver is a system extension that lives in the application, how do we bundle it with our SDK and make it available for use by third-parties?

Answered by DTS Engineer in 893113022

Currently, we are delivering an iPadOS application that utilizes the driver.

Note that my answer here is specifically about only iPadOS, NOT macOS. My answer on macOS would be very different and more complicated.

Since the driver is a system extension that lives in the application, how do we bundle it with our SDK and make it available for use by third parties?

So, my first question here is what the software usage patterns around this hardware are going to look like. Is it:

A single device will be "owned" by a single app install (or set of apps from the same team), with that app handling everything related to that device.
Multiple apps, particularly from different vendors, may be interacting with the device.

The problem here is primarily about driver versioning and how those apps interact with each other and different driver versions. If multiple apps from different vendors are all embedding the same driver, then exactly which DEXT will ultimately control the device isn't well defined (I suspect it will "newest version" but it might be last installed), making the entire situation quite chaotic.

The simplest way to sidestep that issue is exactly what was suggested here:

Can you make installation of your iPadOS application a requirement for use of the driver?

...since now there is only one app that's actually managing the DEXT installation.

Unfortunately, if you want to ship the app embedded in individual apps then I'm afraid that's going to be somewhat complicated. The team that is shipping the app will need to sign the DEXT "themselves", which means:

They'll need all of the same DriverKit entitlements as your team.
They'll also need to at least partially build your DEXT "from scratch", since they'll need to be able to configure and sign it with their own bundle ID (not "yours").

Finally, this may significantly complicate #2, as the different bundle IDs mean the system considers each of those DEXTs to be independent of each other (not different versions of the same thing). I think they could all still use the same driver, but only if you were careful to change just the bundle ID without making any other changes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 1

ssmith_c OP

9h

Can you make installation of your iPadOS application a requirement for use of the driver?

The delivery system for your dext would be your own app (which I think the user has to run once to install your driver). Once installed, any app can communicate with your driver if the driver has the com.apple.developer.driverkit.allow-third-party-userclients entitlement.

Your app (or your customer's app) needs the com.apple.developer.driverkit.communicates-with-drivers entitlement.

Answer 2

DTS Engineer OP

Apple

7h

Recommended

Currently, we are delivering an iPadOS application that utilizes the driver.

Note that my answer here is specifically about only iPadOS, NOT macOS. My answer on macOS would be very different and more complicated.

Since the driver is a system extension that lives in the application, how do we bundle it with our SDK and make it available for use by third parties?

So, my first question here is what the software usage patterns around this hardware are going to look like. Is it:

A single device will be "owned" by a single app install (or set of apps from the same team), with that app handling everything related to that device.
Multiple apps, particularly from different vendors, may be interacting with the device.

The problem here is primarily about driver versioning and how those apps interact with each other and different driver versions. If multiple apps from different vendors are all embedding the same driver, then exactly which DEXT will ultimately control the device isn't well defined (I suspect it will "newest version" but it might be last installed), making the entire situation quite chaotic.

The simplest way to sidestep that issue is exactly what was suggested here:

Can you make installation of your iPadOS application a requirement for use of the driver?

...since now there is only one app that's actually managing the DEXT installation.

Unfortunately, if you want to ship the app embedded in individual apps then I'm afraid that's going to be somewhat complicated. The team that is shipping the app will need to sign the DEXT "themselves", which means:

They'll need all of the same DriverKit entitlements as your team.
They'll also need to at least partially build your DEXT "from scratch", since they'll need to be able to configure and sign it with their own bundle ID (not "yours").

Finally, this may significantly complicate #2, as the different bundle IDs mean the system considers each of those DEXTs to be independent of each other (not different versions of the same thing). I think they could all still use the same driver, but only if you were careful to change just the bundle ID without making any other changes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware