I think you're supposed to use AUv3 audio units and instead let the UI be loaded into the AU hosting app. Although you wrote my goto AUv3 sample code (auv3test5) so I guess there's some reason why AUv3 is not a solution to your problem.

Pass through virtual kext drivers have migrated over to user level AudioServerPlugins of which BackgroundMusic and Blackhole are excellent examples.

Enabling/disabling mute in bluetooth input in Monterey Audio MIDI Setup app enables/disables mute in the output, so looks like this is new behaviour. Whether it's intentional or not is another matter. Log a bug I guess.

Huh, adding that no-op callback on 12.1 beta really does work. What a strange bug.

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)).

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.

oops, the feedback was FB10244046

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.

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

Not resolved with Xcode 14 beta 2

Not resolved in iPadOS 16 beta 2

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