I watched the session multiple times, but it just gives a high level overview that doesn't really say much about this very exciting and complex new feature. It only mentions actually talking to the driver in passing with a single sentence "apps use the IOKit framework to open user clients". Then the presenter says for an example of that we can check out "communicating between a driverkit extension and a client app", which is a macOS app that doesn't even use IOKit, and trying to import IOKit into an iPadOS target doesn't work anyway because the framework is not there. Am I missing something, or is this simply not available in Xcode 14 seed 1? Release notes don't mention anything either, and docs are only updated to reflect that some of this stuff is now available on iPadOS 16...

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?

You don't seem to be able to provision USB or PCI iPad DriverKit drivers, so I tried the null driver which requires only the driverkit entitlement, which can be automatically managed by the Xcode 14 beta. I can get it to deploy, but when it is enabled or when it matches, I see errors like "job failed to spawn," Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x105706980 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}} I wonder why that happens for me but didn't happen in the demo.

Xcode 14.0 beta (14A5228q) refuses to build a DriverKit extension's installer app unless the dext's bundleID a single . suffix added to the bundling app's bundle ID. The error is error build: Embedded binary's bundle identifier is not prefixed with the parent app's bundle identifier. Is this behaviour intentional? Maybe it makes sense for non-driverkit bundled things, but it breaks existing software, invalidates existing dext bundle IDs and leads to awkward bundleIDs like com.foo.installer.mydriver.

There is currently no way to "Bring your driver to iPad with DriverKit" because it's impossible to develop a driver because developers can neither deploy to the device nor run there because there is no way to procure development provisioning profiles with the required entitlements for actual hardware (USB, PCI). I bought an M1 iPad just to test this alleged new capability and the only thing it's good for so far is theoretically transferring files quickly or attaching some kind of ethernet dongle. My 1 month no-questions-asked returns window is going to close soon! FB10152280 FB10244398 FB10244627 FB10160665 FB10152361 FB10160793 FB10152210 FB10160567 FB10244046 FB10427776

There is no documentation for running, debugging and testing system extensions on iPadOS16. The WWDC 2022 session "Bring your driver to iPad with DriverKit" does not count because (as of beta 2) it is completely unreproducible. This document tells us that to test our system extensions we must disable SIP so it's clearly only for macOS: https://developer.apple.com/documentation/driverkit/debugging_and_testing_system_extensions It would be nice if this document were updated with reproducible instructions for testing system extensions on iPadOS! FB10427776

With the advertisement of enhanced IO support on iPadOS16 - Will developers be able to take advantage of IOKit aswell?

Will it be possible to create drivers on iPad for Human Interface Devices such as an external stylus?