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?
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)).
that was a 4. the dev forums are weird
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:
When you request an entitlement, you cannot get a wildcard entitlement. You must request the vendor IDs that you would like to match with. The wildcard entitlement that is provided for development is not valid for distribution.
Distribution is the least of my worries because I can't develop anything because entitlements don't work. Not even wildcard ones.
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?
If you are attempting to develop without restricted entitlements, make sure to set your dext's signing identity to "Sign to Run Locally" as noted here: https://developer.apple.com/news/?id=c63qcok4. In Xcode 14, you will also need to add the AD_HOC_CODE_SIGNING_ALLOWED user-defined variable to your dext's "Build Settings." However, this will only work for macOS, as iPadOS does not allow ad-hoc code signing. Unfortunately, I'm unable to see the content of your feedback.
In order to add a restricted entitlement to your provisioning profile once granted, please navigate to the identifier in the developer portal and add it from the "Additional Capabilities" tab. If you are using automatic code signing, Xcode will then need to re-generate the provisioning profile. Once the profile has been re-generated, the provisioning profile should contain the restricted entitlement.
Thanks @Drewbadour for your replies. Am I understanding you correctly that it is impossible to develop (emphasis on develop, not distribute) a dext with the com.apple.developer.driverkit.transport.pci entitlement without the entitlement being granted by Apple?
To ask the same question another way: How can I develop a dext with the com.apple.developer.driverkit.transport.pci entitlement if I have not yet been granted the com.apple.developer.driverkit.transport.pci entitlement from Apple?
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.
