IOUSBHostDevice(ioService:options:queue:interestHandler:) with .deviceCapture succeeds — the device is mine, its mass-storage driver terminated. setConfiguration(1, matchInterfaces:) succeeds. The failure is the very next call: IOUSBHostInterface(ioService:options:queue:interestHandler:) on interface 0 returns IOUSBHostErrorDomain -536870199 (kIOReturnInternalError, 0xe00002c9). Exactly one interface node is published under the device, IOServiceGetBusyState reports it idle, and it is refused identically on every retry over several seconds and across repeated re-captures — so this is not a publication race or a stale node. With Full Disk Access granted to the app, the same call claims it on the first attempt, every time. So I'm stuck. I have no choice but to use FDA which I absolutely do NOT want to do. To anyone from DTS reading this, is this a valid reason for granting me com.apple.vm.device-access? It looks like using DriverKit might not work either because the Driverkit entitlements are also restricted. What is the solution here?

We build an iPad photo booth app and have a DriverKit USB transport driver for DNP/Citizen and HiTi dye-sub photo printers. These printers have no vendor drivers for iPadOS, so a dext is the only way to print from an iPad. The driver is complete and hardware-validated on both printer families under a development profile. The only thing blocking distribution is the entitlement. Our requests have been in "Submitted" state since July: 72B5P53K28 (July 24, 2026): DriverKit, USB Transport, UserClient Access, vendor IDs 4931 (0x1343) and 5202 (0x1452) 4Z76G958GF (July 25, 2026): amendment adding vendor ID 3350 (0x0D16, HiTi Digital) Developer Support case 20000136465729 was opened for this and acknowledged on September 1, but there has been no decision. I noticed in https://developer.apple.com/forums/thread/826658 that a DTS engineer confirmed the identical configuration (one USB dext, vendor IDs 3350, 4931, 5202) was approved for another team on May 5, so the scope itself is clearly something Apple grants. Is there anything further needed from us to move these along, or a way to get a status on them? Team ID: 7B3398CSQU

Hey, We are developing a dext that would like to match with all USB devices, no matter the vendor. We use VendorID = * in the plist of the Dext to help achieve this when running it locally without entitlements. I know that the transport.usb entitlement requires a list of Vendor id's, but is it possible to receive an entitlement which is suitable for all VID's? Kind of like this: <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <string>*</string> </dict> </array> Thanks

Entitlements requested: com.apple.developer.driverkit.userclient-access com.apple.developer.driverkit.transport.usb com.apple.developer.driverkit.transport.hid com.apple.developer.driverkit.family.hid.eventservice com.apple.developer.driverkit.family.serial com.apple.developer.driverkit.family.scsicontroller com.apple.developer.driverkit.family.networking com.apple.developer.driverkit.family.hid.device , and the base com.apple.developer.driverkit entitlement Hi all, We recently received a decline on the DriverKit entitlement set listed above. The response noted: "Technical details within DriverKit mean that it is not a viable solution for security block or broad-scale system modifications." I'd like to get some clarity on how to bring our request in line with what's approvable, and I'm hoping the forum (or a Code-Level Support engineer) can point us in the right direction. Context on what we're building: We develop a Data Loss Prevention (DLP) product for macOS. We already hold the Endpoint Security entitlement (com.apple.developer.endpoint-security.client) and use it in production today for our core monitoring and policy-enforcement functionality. Why we're requesting DriverKit specifically: ESF gives us visibility and the ability to authorize/deny many file and process events, but it does not give us the control we need over removable/peripheral hardware. Two concrete gaps in our DLP policy enforcement that we're trying to close: Blocking data exfiltration via USB-connected Android devices — when an Android phone is plugged in, it mounts as a USB mass-storage/MTP-style device, and our policy needs to be able to prevent it from mounting or being written to, on a per-policy basis (e.g., disable an endpoint's ability to copy files to a connected Android device). Camera blocking — disabling the built-in/USB camera device at the hardware transport level as part of a DLP policy, rather than a userspace toggle that a privileged process could bypass. Our understanding was that "com.apple.developer.driverkit.transport.usb" combined with the HID/USB family entitlements would let us implement a DriverKit-based USB filtering driver to enforce this. Given the decline language about "security block or broad-scale system modifications," it sounds like Apple's position is that DriverKit is not intended to be used to build a general device-blocking layer this way. What I'm hoping to learn: Is per-policy USB mass-storage/MTP mounting control (blocking a specific class of device, e.g., Android phones, from mounting or transferring files) something DriverKit is intended to support at all for third-party DLP vendors, or is this fundamentally out of scope regardless of how the request is written up? If it is in scope, what should we change in the entitlement request write-up (use case description, scoping of which entitlements we actually need vs. what we requested) to make it approvable? We may have over-requested — for example, do we need family.networking and family.serial at all for USB mass-storage/camera blocking, or should we narrow the request to just the USB transport + HID/SCSI entitlements? Is there a preferred way to demonstrate that our use case is a scoped, policy-driven enterprise DLP control (with IT/MDM deployment, not a consumer app) rather than "broad-scale system modification," or does the entitlement review not distinguish on that basis? Any pointers — either on scoping this request correctly, or on whether this is simply not achievable via DriverKit and we should be looking at a different API — would be much appreciated. Happy to provide more detail on our exact enforcement flow if that's useful for a Code-Level Support ticket. Thanks in advance

I am developing an independent macOS compatibility driver for the Avid/Digidesign Eleven Rack, an EOL USB audio device that does not have an Apple-silicon-compatible OEM driver. The existing hardware identifies as: Vendor ID: 0x0DBA — Digidesign/Avid Product ID: 0xB011 — Eleven Rack Transport: USB 2.0 high-speed isochronous audio The proposed implementation uses AudioDriverKit and USBDriverKit. It consists of a DriverKit system extension packaged inside a macOS control application. The USB entitlement would be restricted to this exact VID/PID. I am an independent developer and do not own the Digidesign/Avid VID. I am not manufacturing hardware or attempting to use that VID for a new USB product. The driver would only match existing Eleven Rack devices. The implementation is independently written for interoperability, and no Avid executable code would be included. I currently have a working direct user-space USB proof of concept, but I cannot properly activate and test the AudioDriverKit extension with SIP enabled without the required entitlements. Before enrolling in the paid Apple Developer Program, I would appreciate clarification on the following: Does Apple consider DriverKit development and distribution entitlement requests from independent developers supporting existing EOL hardware when the developer does not own the device’s VID? Is written authorization from the VID owner always required, or are these requests evaluated individually? Would restricting the USB transport entitlement to the exact 0x0DBA:0xB011 device affect eligibility? Is there a way to obtain an initial eligibility determination before purchasing Apple Developer Program membership? The anticipated entitlements are: com.apple.developer.driverkit com.apple.developer.driverkit.family.audio com.apple.developer.driverkit.transport.usb com.apple.developer.system-extension.install for the host application Restricted user-client access between the host application and driver I understand that the forum cannot grant an entitlement. I am trying to determine the appropriate process and whether manufacturer authorization is a prerequisite before submitting a formal request.

We ship an iPadOS app with an embedded USBDriverKit extension that drives Citizen/DNP dye-sub photo printers. It works: on a development-provisioned iPad the dext registers, matches, opens its user client and prints, verified on two units in hand (DNP DS-RX1 0x1343:0x0005, DNP QW410 0x1452:0x9201). The extension declares twelve IOKitPersonalities, each pinned to one exact idVendor/idProduct pair plus bConfigurationValue and bInterfaceNumber. Those twelve span two vendor IDs — 4931 (0x1343, Citizen Systems) and 5202 (0x1452, Dai Nippon Printing) — because the same printer families ship Citizen-badged on one and DNP-badged on the other. We have one USB Transport – VendorID request per vendor ID, both currently Submitted. Thread 842748 already answered the scope question for us, so I'm not asking that one: at twelve devices we read vendor-level as the right ask rather than twelve VendorID+ProductID requests, and we've kept the personalities narrow so the entitlement is a ceiling rather than what actually matches. Please correct me if that's the wrong reading for two vendor IDs rather than one. My actual question is about a mistake in one of the submissions. The older request also asked for UserClient Access, which we now understand is macOS-only (com.apple.developer.driverkit.userclient-access lists DRIVER_KIT and MAC_OS, not IOS). We don't need it — on iPadOS the app opens the dext's user client with com.apple.developer.driverkit.communicates-with-drivers, which needs no approval. Does an inapplicable entitlement on a submitted request need to be formally withdrawn, or is it simply ignored during review? I'd rather not leave a macOS-only entitlement sitting on an iPadOS request if that's something a reviewer has to resolve. If it does need correcting, what's the mechanism? Re-filing would create a third request, and I'd rather not muddy the queue. (Developer Support told me request handling is outside their scope, which is what brings me here.) Is there any way to indicate that two requests belong to one driver extension and are only useful together? Happy to post the Info.plist personalities or the dext's entitlements if useful. Thank you.

This is my first driver and I have had the devil of a time trying to find any information to help me with this. I beg help with this, since I cannot find any tutorials that will get me over this problem. I am attempting to write a bridging driver for an older UPS that only communicates via RPC-over-USB rather than the HID Power Device class the OS requires. I have written the basic framework for the driver (details below) and am calling OSSystemExtensionRequest.submitRequest with a request object created by OSSystemExtensionRequest.activationRequest, but the didFailWithError callback is called with OSSystemExtensionErrorDomain of a value of 9, which appears to be a general failure to activate the driver. I can find no other information on how to address this issue, but I presume the issue is one of entitlements in either the entitlements file or Info.plist. I will have more code-based details below. For testing context, I am testing this on a 2021 iMac (M1) running Sequoia 15.7, and this iMac is on MDM, specifically Jamf. I have disabled SIP and set systemextensionsctl developer on, per the instructions here, and I have compiled and am attempting to debug the app using xcode 26.2. The driver itself targets DriverKit 25, as 26 does not appear to be available in xcode despite hints on google that it's out. For the software, I have a two-target structure in my xcode project, the main Manager app, which is a swift-ui app that both handles installation/activation of the driver and (if that finally manages to work) handles communication from the driver via its UserClient, and the driver which compiles as a dext. Both apps compile and use automated signing attached to our Apple Development team. I won't delve into the Manager app much, as it runs even though activation fails, except to include its entitlements file in case it proves relevant <dict> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> and the relevant activation code: func request(_ request: OSSystemExtensionRequest, didFailWithError error: any Error) { // handling the error, which is always code value 9 } func activateDriver() { let request = OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier: "com.mycompany.driver.bundle.identifier", queue: .main) request.delegate = self OSSystemExtensionManager.shared.submitRequest(request) //... } And finally the Manager app has the following capabilities requested for its matching identifier in our Apple Developer Account: DriverKit Communicates with Drivers System Extension On the Driver side, I have two major pieces, the main driver class MyDriver, and UserClient class, StatusUserClient. MyDriver derives from IDriverKit/IOService.iig but (in case this is somehow important) does not have the same name as the project/target name MyBatteryDriver. StatusUserClient derives from DriverKit/IOUserClient.iig. I have os_log(OS_LOG_DEFAULT, "trace messages") code in every method of both classes, including the initializers and Start implementations, and the log entries never seem to show up in Console, so I presume that means the OS never tried to load the driver. Unless I'm looking in the wrong place? Because I don't think the driver code is the current issue, I won't go into it unless it becomes necessary. As I mentioned above, I think this is a code signing / entitlements issue, but I don't know how to resolve it. In our Apple Developer account, the Driver's matching identifier has the following capabilities requested: DriverKit (development) DriverKit Allow Any UserClient (development) DriverKit Family HID Device (development) -- NOTE: this is planned for future use, but not yet implemented by my driver code. Could that be part of the problem? DriverKit Transport HID (development) DriverKit USB Transport (development) DriverKit USB Transport - VendorID -- submitted, no response from Apple yet HID Virtual Device -- submitted, no response from Apple. yet. This is vestigial from an early plan to build the bridge via shared memory funneling to a virtual HID device. I think I've found a way to do it with one Service, but... not sure yet. Still, that's a problem for tomorrow. Apparently I've gone over the 7000 character maximum so I will add my entitlements and info.plist contents in a reply.

Hi everyone, I am seeking clarification regarding the communication capabilities between an ESP32 microcontroller and Apple's latest devices, specifically the iPhone 16 Pro Max and iPad Pro, both equipped with USB-C ports. Background: MFi Certification: Historically, establishing communication between external devices and iOS devices required MFi (Made for iPhone/iPad) certification. But I remember this being necessary in the Lightning Cable to USB era. With the introduction of USB-C ports in recent iPhone and iPad models, there is an indication that MFi certification may no longer be necessary for certain peripherals. Perhaps I'm not confident on the terminology here: https://mfi.apple.com/en/who-should-join Project Requirements: I am working on a sensor research project that necessitates the collection of low-latency time-series data from an ESP32 microcontroller, which features a USB-C port. The data needs to be transmitted to an iPhone 16 Pro Max or iPad Pro. Bluetooth communication has proven insufficient due to its limited data transfer rates (~1.2 Mbps with L2CAP). While NEHotspot could be an alternative, it restricts the iPad's internet connectivity. Therefore, establishing a direct USB-C connection between the ESP32 and the iOS device appears to be the most viable solution. Questions: MFi Certification Necessity: Is MFi certification still required for an ESP32 microcontroller to communicate with iPhone 16 Pro Max or iPad Pro via USB-C? USB-C Communication Support: Do the iPhone 16 Pro Max and iPad Pro natively support serial communication over USB-C with microcontrollers like the ESP32? If not, are there recommended protocols or interfaces to facilitate this communication? App Development Considerations: Would developing a custom iOS application be necessary to handle data transmission from the ESP32 over USB-C? If so, are there specific APIs or frameworks provided by Apple to support this functionality? Data Transfer Rates: Considering the need for high-speed data transfer, are there any limitations or considerations regarding the data transfer rates achievable through a USB-C connection between the ESP32 and iOS devices? Thank you!

I'm trying to build the DriverKit template driver target in an Xcode project which contains an app targeting iPadOS 17. I've made no modifications to the DriverKit template. When building, I get this link error ld: file cannot be open()ed, errno=2 path=/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a in '/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a' anyone know how to fix this? My search turned up something about building llvm from sources, which seems like overkill to put a DriverKit driver into an iPad app.

I have a product that currently communicates to a piece of proprietary Medical hardware via USB. We have a driver created with USBDriverKit that is a hard requirement for this product to function. Currently, we are delivering an iPadOS application that utilizes the driver. Our next step is to create an SDK that includes all of the Frameworks and the driver utilized by the application. Since the driver is a system extension that lives in the application, how do we bundle it with our SDK and make it available for use by third-parties?

I have a workspace containing a DriverKit USB driver and the containing application that utilizes the driver. These are in separate projects. How do I configure the application project or the workspace so that, when I build the app, the driver is automatically built and copied into the application package as required for delivery? Currently I have to manually select the driver target, build, and then select the app target and build. In order to get the driver into the app, I have included it as a build-phase dependency but I had to hardcode the driver project output path and it doesn't build it automatically. Additionally, because I hard-coded the debug path, when I try and create an Archive to deliver the app, the app includes the debug version of the driver instead of the release version. I'm obviously doing this wrong because it is as clunky as can be.

I'm investigating supporting a touchscreen digitizer on macOS. I'd like to receive multi-touch reports from the device, and have them intercepted by my app. I also want to suppress the default absolute positioning 'mouse' behavior of the touch screen. The device exposes three HID interface: #0 - multi-touch (PrimaryUsagePage 0xD, PrimaryUsage 4) #1 - vendor-specific #2 - single-touch (PrimaryUsagePage 1, PrimaryUsage 2) I've only been able to achieve half of my goal using a HIDDriverKit dext - I can outmatch the OS for the single-touch HID interface and ignore its 7-byte single-touch reports. However, although I can match to the multi-touch interface, I never see any reports at all there, as if the OS never polls the interrupt endpoint. On Windows, the device "just works" - I've traced its behavior in Wireshark. The OS doesn't do any special setup, it sends no SET_FEATURE commands, it just reads from the multi-touch interrupt endpoint, where it receives 54-byte reports. Windows doesn't even get any 7-byte single-touch reports. On macOS, I managed to use Wireshark on an old Intel Mac, where I can still use XHC20 for logging. Here, macOS tries to read from all the interrupt endpoints for all the HID interfaces, and the digitizer only responds on the single-touch interface. MSDN's documentation for multi-touch support is quite unhelpful here, because it just says "use the OS driver", but doesn't detail how a digitizer switches between multi-touch and single-touch mode. If I were making a digitizer, I'd send reports on both interfaces, expecting the OS to read the single- or multi-touch interface as required. Although unlikely, it seems that this digitizer changes its behavior based on how it is accessed. I can outmatch the USB interface for the single-touch reports, so that the OS HID driver doesn't even see it. That doesn't change the device behavior. The HIDDriverKit APIs I use imply setting up an interrupt read. I call Open on the interface, and implement a ReportAvailable callback. This works for the single-touch interface, but I get no reports on the multi-touch interface. All the calls with return values return kIOReturnSuccess. Does anyone know how multi-touch digitizers switch between single- and multi-touch mode (if indeed they have a mode at all), or why macOS apparently doesn't even read the multi-touch interrupt end point? Does anyone know how I can ensure that my HID driver actually reads the interrupt endpoint on the HID interface it is matched to? Does macOS deliberately prevent access to multi-touch HID interfaces?

On the Certificates, Identifiers and Profiles section of the Account section of developer.apple.com, if you manually configure the Capabilities of an App Identifier, there are icons with no tooltips. Does anyone know what they mean? (I'm particularly interested in the two different icons shown in my screenshot, with the same name)

I'm working on hardware that communicates wireless and wired with mobile systems. Anything non-i[Pad]OS we can connect via USB and achieve great bandwidth, in situations where this is necessary. Since i[pad]OS does not support FTDI class compliant devices through USB (and also omits the IOUSB framework), I wonder whether we have a way to "work around" this, e.g. how about (ab)using another protocol that i[pad]OS allows? Concretely, would you think it's possible to tunnel our serial data stream via USBHID?

Hello everyone, We're working on an iOS app that needs to connect to a non-Apple pre-operating system using USB for serial communication. Our goal is to send and receive data between an iPhone and a UEFI-based system directly over USB. We've created a proof of concept using the USBMux protocol, which let us exchange basic messages. However, we're running into problems with the USB endpoint setup. In some cases, the USB communication doesn't start or stay connected. Since this is for a pre-boot environment, it might not fit into the usual iOS USB communication frameworks. We're looking for help with the following: Any guidance or documentation on setting up USB serial communication between an iPhone and a non-Apple pre-boot system Information on system APIs, frameworks, or protocols that iOS supports for direct USB communication in this scenario Access to official USBMux documentation or specs to understand its limitations and capabilities better Whether this communication requires MFi certification or if there are other Apple-supported interfaces we can use Thank you!

Hi, We’re developing a DriverKit extension for iPadOS. In local Debug and Release builds, everything works as expected, but the same build uploaded to TestFlight fails at IOServiceOpen with the following errors: -536870212 (0xE00002EC) kIOReturnUnsupported -536870201 (0xE00002F7) kIOReturnNotPermitted What we’ve verified so far App entitlements We checked our main app entitlements file, and it has the correct capabilities for the driverkit communication &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;com.apple.developer.driverkit.communicates-with-drivers&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.driverkit.userclient-access&lt;/key&gt; &lt;array&gt; &lt;string&gt;abc.def.ABCDriver&lt;/string&gt; &lt;/array&gt; &lt;key&gt;com.apple.developer.system-extension.install&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.device.usb&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.files.user-selected.read-write&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; &lt;/plist&gt; we also checked the Provisioning profile (as shown on the portal) and the “Enabled Capabilities” seems to have the correct DriverKit Capabilities enabled. Enabled Capabilities Access Wi-Fi Information, DriverKit, DriverKit (development), DriverKit Communicates with Drivers, DriverKit USB Transport (development), DriverKit USB Transport - VendorID, DriverKit UserClient Access, iCloud, In-App Purchase, Sign In with Apple, System Extension When we download and inspect the provisioning profile as plain text, we notice that some expected DriverKit entitlements appear to be missing from the section. &lt;key&gt;Entitlements&lt;/key&gt; &lt;dict&gt; &lt;key&gt;beta-reports-active&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.networking.wifi-info&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.driverkit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.driverkit.communicates-with-drivers&lt;/key&gt; &lt;true/&gt; &lt;key&gt;application-identifier&lt;/key&gt; &lt;string&gt;ABC123456.abc.def&lt;/string&gt; &lt;key&gt;keychain-access-groups&lt;/key&gt; &lt;array&gt; &lt;string&gt;ABC123456.*&lt;/string&gt; &lt;string&gt;com.apple.token&lt;/string&gt; &lt;/array&gt; &lt;key&gt;get-task-allow&lt;/key&gt; &lt;false/&gt; &lt;key&gt;com.apple.developer.team-identifier&lt;/key&gt; &lt;string&gt;ABC123456&lt;/string&gt; &lt;key&gt;com.apple.developer.ubiquity-kvstore-identifier&lt;/key&gt; &lt;string&gt;ABC123456.*&lt;/string&gt; &lt;key&gt;com.apple.developer.icloud-services&lt;/key&gt; &lt;string&gt;*&lt;/string&gt; &lt;key&gt;com.apple.developer.icloud-container-identifiers&lt;/key&gt; &lt;array&gt;&lt;/array&gt; &lt;key&gt;com.apple.developer.icloud-container-development-container-identifiers&lt;/key&gt; &lt;array&gt;&lt;/array&gt; &lt;key&gt;com.apple.developer.ubiquity-container-identifiers&lt;/key&gt; &lt;array&gt;&lt;/array&gt; &lt;key&gt;com.apple.developer.driverkit.transport.usb&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;idVendor&lt;/key&gt; &lt;integer&gt;1234&lt;/integer&gt; &lt;/dict&gt; &lt;/array&gt; &lt;key&gt;com.apple.developer.applesignin&lt;/key&gt; &lt;array&gt; &lt;string&gt;Default&lt;/string&gt; &lt;/array&gt; &lt;/dict&gt; We have a couple of questions: Could the missing com.apple.developer.driverkit.userclient-access entitlement in the provisioning profile alone explain the kIOReturnUnsupported / kIOReturnNotPermitted failures from IOServiceOpen? Why do some DriverKit capabilities appear in the Apple Developer portal UI but vanish from the actual profile we download? Is there an extra step we’re overlooking when regenerating profiles after toggling those capabilities? Thanks

Requested "DriverKit USB Transport - VendorID" for two VendorID, one in main request and one in the description of the request. Then I was approved but found out the provisioning profile only had 1 vendor id. I then sent another request ID 964Y77AHUZ to add the other vendor id but have not heard back for a week now. What is the turn-around time on these requests? Anyway to request this to be expedited? Thank you, --Michael Team ID: MZR5GHAQX4

Hello everyone, I am currently working on an iPadOS application that requires communicating with a custom hardware board based on the Raspberry Pi RP2040 microcontroller via USB. My initial thought was to use the standard CDC-ACM (virtual serial port) profile on the RP2040. However, my understanding is that iPadOS's built-in system drivers will automatically claim any standard CDC-ACM interfaces, preempting my custom USBDriverKit driver from matching and taking control of the device. Is my assumption correct that iPadOS will strictly preempt a standard CDC-ACM device, making a custom DriverKit implementation impossible for that specific class?

I'm hitting a kernel-side rejection on IOServiceOpen from a host app against my DEXT's IOUserService, before any code in my DEXT's NewUserClient runs. DEXT activation and USB matching succeed; only the user-client connection fails. What works DEXT activates and shows as [activated enabled] in systemextensionsctl list. DEXT matches IOUSBHostInterface for the target device and Start() runs to completion. Inside Start(), CopyInterface() returns successfully and CopyPipe() for the expected endpoints all succeed. Host app receives the matching notification for the DEXT's IOUserService and calls IOServiceOpen(service, mach_task_self(), 0, &connect). What fails IOServiceOpen returns kIOReturnError (0xE00002BC). My DEXT's NewUserClient override is never reached — verified by the absence of any breadcrumb log and by stepping through under lldb (no entry on the DEXT side). This reproduces both with: The original com.apple.developer.driverkit.userclient-access entitlement listing the host bundle ID. The dev fallback com.apple.developer.driverkit.allow-any-userclient-access = true on host + DEXT. (Background: the App ID portal has the bundle-ID list for userclient-access stored as a single newline-joined string instead of separate array entries — see Support Thread 822652 — so I've been using allow-any-userclient-access = true for now. The IOServiceOpen failure persists either way.) Diagnostics I can't get I'd like to confirm the kernel-side rejection reason, but DEXT os_log output is suppressed in Console and: sudo log config --process <dext-pid> --mode "level:debug" log: Unable to set mode for pid <dext-pid> I've tried by PID and by subsystem; both refuse. SIP is in its default state. Any pointer to the correct invocation (or a Configuration Profile to enable DriverKit verbose logging) would unblock me. Environment macOS 26.3.1 (build 25D2128) Xcode 26.3 (build 17C529) Host app: AppKit, sandboxed, Mac App Store distribution DEXT: matches IOUSBHostInterface on idVendor: 0x1452 (DNP) and (pending capability approval) 0x1343 (Citizen) Entitlements on host: com.apple.developer.driverkit, com.apple.developer.driverkit.userclient-access (or allow-any-userclient-access = true for dev) Entitlements on DEXT: com.apple.developer.driverkit, com.apple.developer.driverkit.transport.usb, com.apple.developer.driverkit.allow-any-userclient-access for dev Questions Is IOServiceOpen → kIOReturnError before NewUserClient always an entitlement/sandbox check failure, or are there other kernel-side reasons (matching score, IOService class hierarchy mismatch) that produce the same generic code? What's the correct way to enable DEXT os_log capture so I can see the rejection reason? Is there a known interaction between a malformed userclient-access array on the App ID (Forums Thread 822652) and the kernel's user-client authorization path that would persist even after switching to allow-any-userclient-access = true? Sample profiles, codesign output, and the exact matching dictionary available on request. Thanks.

I am developing a USB MTP device for use with macOS. When the device is connected while Preview is running, I observe the host send OpenSession, then GetDeviceInfo, and then no further MTP commands. I do not see a later CloseSession. Problem is that once this happens, exclusive access to the USB interface is retained, so another application cannot connect to the device. From the device side, there is no obvious way to recover except forcing a USB disconnect/reset or shutting down the USB interface. My questions are: Is this expected behavior for Preview, or for a Preview-related macOS helper? Is it expected on macOS that a client may open an MTP session and then leave it idle without sending CloseSession? I am mainly trying to understand whether this is expected macOS behavior, or whether this should be considered a bug.