We ship an iPadOS app with an embedded USBDriverKit extension that drives Citizen/DNP dye-sub photo printers. It works: on a development-provisioned iPad the dext registers, matches, opens its user client and prints, verified on two units in hand (DNP DS-RX1 0x1343:0x0005, DNP QW410 0x1452:0x9201).
The extension declares twelve IOKitPersonalities, each pinned to one exact idVendor/idProduct pair plus bConfigurationValue and bInterfaceNumber. Those twelve span two vendor IDs — 4931 (0x1343, Citizen Systems) and 5202 (0x1452, Dai Nippon Printing) — because the same printer families ship Citizen-badged on one and DNP-badged on the other. We have one USB Transport – VendorID request per vendor ID, both currently Submitted.
Thread 842748 already answered the scope question for us, so I'm not asking that one: at twelve devices we read vendor-level as the right ask rather than twelve VendorID+ProductID requests, and we've kept the personalities narrow so the entitlement is a ceiling rather than what actually matches. Please correct me if that's the wrong reading for two vendor IDs rather than one.
My actual question is about a mistake in one of the submissions. The older request also asked for UserClient Access, which we now understand is macOS-only (com.apple.developer.driverkit.userclient-access lists DRIVER_KIT and MAC_OS, not IOS). We don't need it — on iPadOS the app opens the dext's user client with com.apple.developer.driverkit.communicates-with-drivers, which needs no approval.
- Does an inapplicable entitlement on a submitted request need to be formally withdrawn, or is it simply ignored during review? I'd rather not leave a macOS-only entitlement sitting on an iPadOS request if that's something a reviewer has to resolve.
- If it does need correcting, what's the mechanism? Re-filing would create a third request, and I'd rather not muddy the queue. (Developer Support told me request handling is outside their scope, which is what brings me here.)
- Is there any way to indicate that two requests belong to one driver extension and are only useful together?
Happy to post the Info.plist personalities or the dext's entitlements if useful. Thank you.
Does an inapplicable entitlement on a submitted request need to be formally withdrawn, or is it simply ignored during review? I'd rather not leave a macOS-only entitlement sitting on an iPadOS request if that's something a reviewer has to resolve.
In this particular case, it didn't really matter (I believe your request was approved today). For reference, there's a thread here that outlines exactly how all of the user client entitlements work, but what's relevant here is that com.apple.developer.driverkit.userclient-access is an app entitlement, NOT a DEXT entitlement. Once your request is approved, your account will have two entitlements added— one that's used to sign the DEXT and the other which you'd use to sign your macOS app. The fact your team has the macOS entitlement won't have any effect on your iPadOS app.
In terms of the approval process, we don't really differentiate between macOS/iPadOS in a "strong" way. Even if your product is iPadOS only, my longstanding recommendation is to use macOS as your initial/primary development platform, so the entitlement would still be moderately useful even if you never ship a macOS product. More to the point, I can't think of any situation where we'd approve a DEXT request but NOT approve a user client request. The DEXT is the truly "dangerous" component and there are legitimate reasons why basically "any" product would want its own communication channel to its DEXT.
If it does need correcting, what's the mechanism?
There isn't anything to correct here, but if there is a specific configuration problem with an entitlement grant then you should file a Code Level Support Request asking for help. Note that this is specifically for configuration issues, not approval delays or other administrative problems.
(Developer Support told me request handling is outside their scope, which is what brings me here.)
I'm not sure which channel you were talking to here, but the guidance above is correct, given that I'm the person you'd ultimately be emailing with.
Is there any way to indicate that two requests belong to one driver extension and are only useful together?
Your request was fine, as the critical points are to tell us that you have another request and what values are in the other request. The main suggestion I'd have for any future request (from you or other readers) is that it's very helpful to list all your VID/PIDs in a way that "groups" them all together and also makes hex/decimal clear. So including a section like this:
I need these VIDS-PIDS
0x12ad/4,781 - 0x0023/35
0x12ad/4,781 - 0x0024/36
0x1aef/6,895 - 0x0029/41
...is better than spreading those same elements across your request. Having all the data in one place makes it easier to confirm the configuration is correct and makes us less likely to overlook something.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
