I requested "DirverKit UserClient Access" Entitlement, But I Distribute App failed.

I think when I request "DirverKit UserClient Access" I make a mistake. I fill in two Bundle IDs in the "Request a System Extension or DriverKit Entitlement" form's "UserClient Bundle IDs" item.

So, the problem here is that entitlement configuration you were granted is inherently invalid. When requesting multiple user client targets, each DEXT bundle ID should be a separate entry in an array, but in your case the entitlement was granted as a single string (as you described above). Unfortunately, that then fails because bundle IDs cannot include spaces.

I reapply "DirverKit UserClient Access" Entitlement. But decline. The result is "decline".

Going over your requests, it looks like a number of different requests were submitted which contradicted each other, which led to their rejection. I had the team clear out that backlog by rejecting all but one of your requests. The last one was then approved with an array of 5 different bundle IDs, which I extracted from the earlier requests:

<array>
<string>com.turing.TuringTouch</string>
<string>com.turing.TuringTouch.TouchDriver</string>
<string>com.turing.TuringTouchDriver</string>
<string>com.turing.virtualpad</string>
<string>com.turingdraw.DigidrawTouch.DigidrawDriver</string>
</array>

Note that you'll include that full set above as the value for this entitlement, even if the app you’re shipping will only work with a subset of that driver bundle ID list. The "extra" values don't matter and will simply be ignored.

Please help me. Please tell me, how should I do now?

You may need to delete any existing profiles and generate new ones, but once that's done your new configuration should work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin,

We're hitting the exact same malformed encoding on our team (MZR5GHAQX4 / Lumasoft LLC) and would appreciate the same kind of manual fix. The DriverKit UserClient Access capability was granted on case CC3TUTNMR7 on 2026-05-05. The malformed array reproduces today (2026-05-10) on freshly regenerated provisioning profiles — single 77-character string with an embedded \n at offset 38:

'co.lumasoft.lumabooth.dnpprinterdriver\nco.lumasoft.lumashare.dnpprinterdriver'

array.count == 1, type == str.

Affected App IDs (the host-side ones — the DEXTs use allow-any-userclient-access and don't need this list):

• co.lumasoft.lumabooth
• co.lumasoft.dnpdriverhost
• co.lumasoft.lumashare

The intended values (separate array entries):

co.lumasoft.lumabooth.dnpprinterdriver
co.lumasoft.lumashare.dnpprinterdriver

Runtime consequence: IOServiceOpen() from the host returns kIOReturnNotPermitted (-536870174) because no valid bundle ID can match the malformed entry. The DEXT itself matches IOUSBHostInterface, opens it, and copies bulk pipes correctly — failure is strictly at the kernel-side host entitlement check. Confirmed not bypassable by running as root.

Tier-1 support case 102887359854 was deflected to the forums, so following that direction here.

Would you be able to re-enter the array on the affected App IDs the same way you did for the OP? Happy to provide our decoded profile or security cms -D -i output by DM / radar if helpful. Also filed Feedback Assistant feedback for the portal-side encoding so a permanent fix can land downstream.

Thanks

To anyone who stumbles across this thread in the future, I've locked this thread so it doesn't turn into a long collection of team specific issues.

If your team:

• Has already been approved for one or more DriverKit entitlements.

AND

• You believe there is a technical issue with the configuration you were granted (see above as an example).

...then the best way to handle that is to file a code-level support request. In that request, make sure you include the following:

1. Your team ID.

2. The entitlement you believe is misconfigured and a description of how it was misconfigured.

3. A link to this post.

That will get your request to me, at which point I'll sort things out without cluttering up the forums.

Please note:

• DTS does NOT handle standard DEXT entitlement requests and is not the escalation point for general concerns or rejections. This is specifically for sorting out odd technical mistakes or edge cases, not as a general escalation point.

• If you receive a reply from DTS redirecting you to the forums, that’s specifically because I’ve reviewed your account configuration and have determined that the problem is NOT caused by your portal configuration and I would prefer to help you with your issue publicly.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware