PCI transport entitlement / capability

We're invited to write PCI drivers for iPad, but there's no capability for PCI Driver Kit in Xcode and a com.apple.developer.driverkit.transport.pci key in your entitlements does not find its way into your embedded.provisionprofile with Automatically Manage Signing nor can you manually add it in the appID portal, because it's not there.

Huh?

For entitlements requiring custom values like PCI and USB transport, you must manually add them to the plist outside of Xcode's capabilities editor. The next time the profile is re-generated by Xcode, it should include your restricted entitlement.

It should include my entitlement, but it doesn't. Only the entitlements available in the capability editor or in the portal seem to work, which doesn't help. FB10152280

should I log these separately?

  1. cannot create pci entitlement in capabilities editor
  2. cannot add pci entitlement in appID portal
  3. cannot automatically pick up PCI entitlement from entitlements file (as per your suggestion)

The same is true for USB fwiw

I'm also getting a "poisoned" bundleID (e.g. it got audio family at one point and would not go away, until I changed my bundle ID(s)).

  1. unneeded [supported] entitlements don't go away when removed

I created some not completely orthogonal feedsback: FB10160793, FB10160665, FB10160567, FB10152361, FB10152210, FB10152280

@Drewbadour said

For entitlements requiring custom values like PCI and USB transport, you must manually add them to the plist outside of Xcode's capabilities editor. The next time the profile is re- generated by Xcode, it should include your restricted entitlement.

Worryingly, I got a "works as expected" response from my feedback (FB10160793):

Please know that our engineering team has determined that this issue behaves as intended based on the information provided.

Automatic signing doesn’t support the PCI entitlement.

I haven't logged the equivalent FB for USB yet, but I'm not sure what the point of DriverKit for iPad is if you can't actually communicate with any devices.

"Public for development" also looked like a convenient and more production-like way of developing drivers for Ventura, too (e.g. you can avoid disabling SIP on a corporate MDMed machine), but if you actually can't create your entitlements then the feature is useless.

I appreciate your efforts to file feedbacks covering the issues you've found.

Automatic signing doesn’t support the PCI entitlement.

As mentioned previously, the Signing & Capabilities UI does not currently support the restricted entitlements for PCI and USB. If you enter the values manually into the entitlements file, the identifiers and provisioning profiles will be generated correctly. Is this not the case in your experience?

I haven't logged the equivalent FB for USB yet, but I'm not sure what the point of DriverKit for iPad is if you can't actually communicate with any devices.

USB transport supports a wildcard entitlement for development, (string value: *) which means that you can communicate with all USB devices from iPadOS during development.

You can request a PCI entitlement, which will allow you to communicate with PCI devices.

I appreciate your efforts to file feedbacks covering the issues you've found.

It's my rueful pleasure.

As mentioned previously, the Signing & Capabilities UI does not currently support the restricted entitlements for PCI and USB. If you enter the values manually into the entitlements file, the identifiers and provisioning profiles will be generated correctly. Is this not the case in your experience?

Correct - provisioning profiles with PCI and USB entitlements are not being generated correctly: FB10244398, FB10160793 And I received feedback that for PCI this was the intended behaviour.

USB transport supports a wildcard entitlement for development, (string value: *) which means that you can communicate with all USB devices from iPadOS during development.

So the problem with USB is that I'm being too specific? I'll try wildcards, thanks for the tip.

You can request a PCI entitlement, which will allow you to communicate with PCI devices.

Ouch - a review process just for local development? How long does that take?

So what can we actually do with "public for development" entitlements?

Not resolved in beta2

USB transport supports a wildcard entitlement for development, (string value: *) which means that you can communicate with all USB devices from iPadOS during development.

@Drewbadour can you elaborate on how to do this in practice? When requesting an entitlement I can only specify:

  1. that I want a USB entitlement
  2. a numeric vendor ID
  3. with user client access + its bundleID

Not resolved in beta3

@rhythmicfistman Have you made any progress on this issue? I am also trying to develop a PCIDriverKit dext without having requested entitlements from Apple, but in Xcode 14 my dext always fails to launch due to a code signing error. I filed FB10590428 but have not heard anything.

@Drewbadour My issue seems to be the restricted entitlements are not part of the provisioning profile. How exactly are we supposed to add the PCI transport entitlement to the provisioning profile?

Hi @jeff_f, @Drewbadour, I also encountered the same problem.Is there any conclusion?

After this AD_HOC_CODE_SIGNING_ALLOWED user-defined variable is added, only "Sign to Run Locally" can be used, no entitlements can be added, so pcie dext still cannot be used.

Is it possible to debug pcie dext only after requesting entitlements? I've made a Requesting, just let me follow up.

PCI transport entitlement / capability
 
 
Q