Posts

Post not yet marked as solved
12 Replies
Not resolved in beta3
Post not yet marked as solved
2 Replies
This is resolved in iPadOS 16 beta 3.
Post not yet marked as solved
5 Replies
This is resolved (for mac targets) in Xcode beta 3!
Post not yet marked as solved
12 Replies
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: that I want a USB entitlement a numeric vendor ID with user client access + its bundleID
Post not yet marked as solved
5 Replies
Not resolved with Xcode 14 beta 2
Post not yet marked as solved
12 Replies
Not resolved in beta2
Post not yet marked as solved
12 Replies
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?
Post not yet marked as solved
5 Replies
This is a requirement enforced by iPadOS, thus why you are seeing this error in Xcode. If you are attempting to create a non-iPadOS dext, and still seeing this error, please update your feedback request with that information. I can reproduce with macOS only projects. I've updated the feedback.
Post not yet marked as solved
5 Replies
oops, the feedback was FB10244046
Post not yet marked as solved
12 Replies
@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.
Post not yet marked as solved
12 Replies
I created some not completely orthogonal feedsback: FB10160793, FB10160665, FB10160567, FB10152361, FB10152210, FB10152280
Post not yet marked as solved
12 Replies
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? cannot create pci entitlement in capabilities editor cannot add pci entitlement in appID portal 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)).
Post not yet marked as solved
12 Replies
unneeded [supported] entitlements don't go away when removed
Post not yet marked as solved
3 Replies
Huh, adding that no-op callback on 12.1 beta really does work. What a strange bug.