Hello @all I'm develop a DriverKit driver extension and without entitlement checks by OS everything runs fine. But if the entitlements check is enabled in the NVRAM then I get an error due connecting my IOUserClient instance. Which entitlements are really and exactly required for my driver? My driver contains: one IOUserClient instance and multiple IOUserSerial instances The bundle identifier of the driver ist: org.eof.tools.VSPDriver The bundle identifier of the client app org.eof.tools.VSPInstall My entire source code is available on GitHub if any one want to dive deep in :) kernel[0:5107] () [VSPDriver]: NewUserClient called. kernel[0:5107] () [VSPDriver]: CreateUserClient: create VSP user client from Info.plist. kernel[0:5107] () [VSPUserClient]: init called. kernel[0:5107] () [VSPUserClient]: init finished. kernel[0:5107] () [VSPDriver]: CreateUserClient: check VSPUserClient type. kernel[0:5107] () [VSPDriver]: CreateUserClient: success. kernel[0:5107] () [VSPDriver]: NewUserClient finished. kernel[0:5107] () [VSPUserClient]: Start: called. kernel[0:5107] () [VSPUserClient]: User client successfully started. kernel[0:389f] DK: VSPUserClient-0x100001127:UC failed userclient-access check, needed bundle ID org.eof.tools.VSPDriver kernel[0:389f] DK: VSPUserClient-0x100001127:UC entitlements check failed kernel[0:5107] () [VSPUserClient]: Stop called. kernel[0:5107] () [VSPUserClient]: User client successfully removed. kernel[0:5107] () [VSPUserClient]: free called. Here my drivers entitlement file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.family.serial</key> <true/> </dict> </plist> Here my drivers Info.plist file <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>NSHumanReadableCopyright</key> <string>Copyright © 2025 by EoF Software Labs</string> <key>OSBundleUsageDescription</key> <string>Provide virtual serial port</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-any-userclient-access</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.system-extension.redistributable</key> <true/> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOSerialFamily</key> <string>1.0</string> </dict> <key>IOKitPersonalities</key> <dict> <key>VSPDriver</key> <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleIdentifierKernel</key> <string>com.apple.kpi.iokit</string> <key>IOMatchCategory</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOProviderClass</key> <string>IOUserResources</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOProbeScore</key> <integer>0</integer> <key>IOClass</key> <string>IOUserService</string> <key>IOUserClass</key> <string>VSPDriver</string> <key>IOUserServerName</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>VSPUserClient</string> </dict> <key>SerialPortProperties</key> <dict> <key>CFBundleIdentifierKernel</key> <string>com.apple.driver.driverkit.serial</string> <key>IOProviderClass</key> <string>IOSerialStreamSync</string> <key>IOClass</key> <string>IOUserSerial</string> <key>IOUserClass</key> <string>VSPSerialPort</string> <key>HiddenPort</key> <false/> <key>IOTTYBaseName</key> <string>vsp</string> <key>IOTTYSuffix</key> <string>0</string> </dict> </dict> </dict> </dict> </plist> Here the entitlements of the client app <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.shared-with-you</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>$(TeamIdentifierPrefix).org.eof.apps</string> </array> </dict> </plist> Here the Info.plist of the client app: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>LSMinimumSystemVersion</key> <string>$(MACOSX_DEPLOYMENT_TARGET)</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.install</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.system-extension.uninstall</key> <true/> <key>com.apple.developer.driverkit.userclient-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.private.driverkit.driver-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.security.temporary-exception.iokit-user-client-class</key> <array> <string>IOUserUserClient</string> </array> </dict> </plist>

Kevin's Guide to DEXT Signing The question of "How do I sign a DEXT" comes up a lot, so this post is my attempt to describe both what the issues are and the best current solutions are. So... The Problems: When DEXTs were originally introduced, the recommended development signing process required disabling SIP and local signing. There is a newer, much simpler process that's built on Xcode's integrated code-signing support; however, that newer process has not yet been integrated into the documentation library. In addition, while the older flow still works, many of the details it describes are no longer correct due to changes to Xcode and the developer portal. DriverKit's use of individually customized entitlements is different than the other entitlements on our platform, and Xcode's support for it is somewhat incomplete and buggy. The situation has improved considerably over time, particularly from Xcode 15 and Xcode 16, but there are still issues that are not fully resolved. To address #1, we introduced "development" entitlement variants of all DriverKit entitlements. These entitlement variants are ONLY available in development-signed builds, but they're available on all paid developer accounts without any special approval. They also allow a DEXT to match against any hardware, greatly simplifying working with development or prototype hardware which may not match the configuration of a final product. Unfortunately, this also means that DEXT developers will always have at least two entitlement variants (the public development variant and the "private" approved entitlement), which is what then causes the problem I mentioned in #2. The Automatic Solution: If you're using Xcode 16 or above, then Xcode's Automatic code sign support will work all DEXT Families, with the exception of distribution signing the PCI and USB Families. For completeness, here is how that Automatic flow should work: Change the code signing configuration to "Automatic". Add the capability using Xcode. (USB & PCI) Edit your Entitlement.plist to include the correct "Development Only" configuration: USB Development Only Configuration: <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <string>*</string> </dict> </array> PCI Development Only Configuration: <key>com.apple.developer.driverkit.transport.pci</key> <array> <dict> <key>IOPCIPrimaryMatch</key> <string>0xFFFFFFFF&amp;0x00000000</string> </dict> </array> If you've been approved for one of these entitlements, the one oddity you'll see is that adding your approved capability will add both the approved AND the development variant, while deleting either will delete both. This is a visual side effect of #2 above; however, aside from the exception described below, it can be ignored. Similarly, you can sign distribution builds by creating a build archive and then exporting the build using the standard Xcode flow. Debugging Automatic Code-signing In a new project, the flow I describe above should just work; however, if you're converting an existing project, you may get code signing errors, generally complaining about how the provisioning profile configuration doesn't match. In most cases, this happens because Xcode is choosing to reuse a previously downloaded profile with an older configuration instead of generating a new configuration which would then include the configuration changes you made. Currently, you can find these profile files in: ~/Library/Developer/Xcode/UserData/Provisioning Profiles ...which can make it easier to find and delete the specific profile (if you choose). However, one recommendation I'd have here is to not treat the contents of that folder as "precious" or special. What automatic code signing actually does is generate provisioning profiles "on demand", so if you delete an automatic profile... Xcode will just generate it again at the next build. Manually generating profiles is more cumbersome, but the solution there is to preserve them as a separate resource, probably as part of your project data, NOT to just "lose" them in the folder here. If they get deleted from Xcode's store, then you can just copy them back in from your own store (or using Xcode, which can manually download profiles as well). The advantage of this approach is that when profiles "pile up" over time (which they tend to do), you can just delete[1] all of them then let Xcode regenerate the ones you're actually trying to investigate. In terms of looking at their contents, TN3125: Inside Code Signing: Provisioning Profiles has the details of how to see exactly what's there. [1] Moving them somewhere else works too, but could indicate a fear of commitment. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: "Making sense of IOKit error codes", which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the "IOKitPersonalities" is called that because it is in fact a fully valid "IOKitPersonalities" dictionary. That is, what the system actually uses that dictionary "for" is: Perform a standard IOKit match and load cycle in the kernel. The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel. So, working through the critical keys in that dictionary: "IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. The IOKit documentation and naming convention uses the term "Nub", but the naming convention is not consistent enough that it applies to all cases. "IOClass"-> This is the in-kernel class that your DEXT attaches to and works through. This is where things can become a bit confused, as some families work by: Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit). Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit). This distinction is described in the documentation, but it's easy to overlook if you don't understand what's going on. However, compare PCIDriverKit: "When the system loads your custom PCI driver, it passes an IOPCIDevice object as the provider to your driver. Use that object to read and write the configuration and memory of your PCI hardware." Versus SCSIPeripheralsDriverKit: Develop your driver by subclassing IOUserSCSIPeripheralDeviceType00 or IOUserSCSIPeripheralDeviceType05, depending on whether your device works with SCSI Block Commands (SBC) or SCSI Multimedia Commands (SMC), respectively. In your subclass, override all methods the framework declares as pure virtual. The reason these differences exist actually comes from the relationship and interactions between the DEXT families. Case in point, PCIDriverKit doesn't require a specific subclass because it wants SCSIControllerDriverKit DEXTs to be able to directly load "above" it. Note that the common mistake many developers make is leaving "IOUserService" in place when they should have specified a family-specific subclass (case 2 above). This is an undocumented implementation detail, but if there is a mismatch between your DEXT driver ("IOUserSCSIPeripheralDeviceType00") and your kernel driver ("IOUserService"), you end up trying to call unimplemented kernel methods. When a method is "missing" like that, the codegen system ends up handling that by returning kIOReturnUnsupported. One special case here is the "IOUserResources" provider. This class is the DEXT equivalent of "IOResources" in the kernel. In both cases, these classes exist as an attachment point for objects which don't otherwise have a provider. It's specifically used by the sample "Communicating between a DriverKit extension and a client app" to allow that sample to load on all hardware but is not something the vast majority of DEXT will use. Following on from that point, most DEXT should NOT include "IOMatchCategory". Quoting IOKit fundamentals: "Important: Any driver that declares IOResources as the value of its IOProviderClass key must also include in its personality the IOMatchCategory key and a private match category value. This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it. It also prevents the driver from having to compete with all other drivers that need to match on IOResources. The value of the IOMatchCategory property should be identical to the value of the driver's IOClass property, which is the driver’s class name in reverse-DNS notation with underbars instead of dots, such as com_MyCompany_driver_MyDriver." The critical point here is that including IOMatchCategory does this: "This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it." The problem here is that this is actually the exceptional case. For a typical DEXT, including IOMatchCategory means that a system driver will load "beside" their DEXT, then open the provider blocking DEXT access and breaking the DEXT. DEXT Launching The key point here is that the entire process above is the standard IOKit loading process used by all KEXT. Once that process finishes, what actually happens next is the DEXT-specific part of this process: IOUserServerName-> This key is the bundle ID of your DEXT, which the system uses to find your DEXT target. IOUserClass-> This is the name of the class the system instantiates after launching your DEXT. Note that this directly mimics how IOKit loading works. Keep in mind that the second, DEXT-specific, half of this process is the first point your actual code becomes relevant. Any issue before that point will ONLY be visible through kernel logging or possibly the IORegistry. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I'm developing custom AudioDriverKit and MIDI DriverKit drivers for a hardware audio-MIDI device on an M-series iPad. I've encountered a reproducible issue where advertising the audio device's correct USB transport type prevents iPadOS from making the device available to audio applications, whereas advertising Thunderbolt allows it to function. I've previously reported this issue through Feedback Assistant but have not received a response: FB25067968. Environment Hardware: BOSS SY-1000 connected to an M-series iPad via Apple USB-C Digital AV Multiport Adapter Audio: 48 kHz, eight inputs and eight outputs, interleaved Float32 DriverKit SDK: 27.0 Xcode: 27.1 Minimum iPadOS: 18.0 AudioDriverKit deployment target: 21.0 Separate AudioDriverKit and MIDI DriverKit extensions using USBDriverKit Proprietary USB isochronous audio transport The SY-1000 is a USB device, not a Thunderbolt device. The physical USB connection and hardware configuration remain unchanged between tests. Audio behavior Configuration A — Transport type: Thunderbolt When the audio device advertises IOUserAudioTransportType::Thunderbolt: The audio driver loads and registers. iPadOS makes the device available to audio applications. StartDevice/StartIO is invoked. Eight-channel audio input and output function. This has been our established working configuration. Configuration B — Transport type: USB Changing the two transport-type assignments to IOUserAudioTransportType::USB results in: Driver initialization succeeds. AddObject succeeds. RegisterService succeeds. HAL successfully establishes its user-client connection. HAL recognizes the 48 kHz, eight-channel Float32 formats. iPadOS audio-route creation fails. The audio device is unavailable to audio applications. StartDevice/StartIO is never invoked. No USB audio transfers occur. MIDI continues working The SY-1000's MIDI functionality remains available even when the audio device disappears. The project uses a separate MIDI DriverKit extension, attached to the SY-1000's MIDI USB interface. Under the failing USB audio-transport configuration: The SY-1000 remains physically connected and enumerated over USB. The separate MIDI driver continues to be detected. MIDI functionality remains available to MIDI-capable applications. Only the AudioDriverKit device fails to become available as an audio interface. This is an important distinction: the SY-1000 has not disappeared from the USB system. The problem appears specific to AudioDriverKit/Core Audio device routing

I'm developing an iPadOS USB audio-MIDI driver for a hardware device. The audio side uses AudioDriverKit and USBDriverKit (DriverKit SDK 27.0, AudioDriverKit deployment target 21.0, iPadOS 18.0 minimum). I need clarification about the ordering between IOUserAudioDriver::Stop, StopDevice/StopIO, and in-flight IOOperationHandler callbacks. According to Apple's DriverKit documentation, IOService::Stop must quiesce outstanding operations before invoking its superclass implementation. AudioDriverKit documents host-controlled audio I/O and the StopDevice → device StopIO sequence. However, I cannot find an explicit guarantee that the framework has stopped and drained all BeginRead/WriteEnd callbacks before invoking the driver's service Stop. Relevant implementation (simplified): // Audio driver service termination kern_return_t result = StopUSBTransport(); if (result != kIOReturnSuccess) { return result; } // Release resources and close provider interfaces. return Stop(in_provider, SUPERDISPATCH); The transport retirement path currently refuses to release resources while framework I/O is marked active: if (__atomic_load_n(&ivars->m_adk_running, __ATOMIC_ACQUIRE)) { // Retain ownership; resources cannot be released safely. return kIOReturnBusy; } The local running state is cleared following successful device superclass StopIO, but this does not independently establish that already-entered framework audio callbacks have returned. The USB teardown separately prevents new submissions, aborts outstanding transfers, waits for cancellation acknowledgements and native callback completion, and retains resources if ownership cannot be proven safe. An offline regression exercising service termination while framework I/O is marked active reproduces the Busy result. We have not established that AudioDriverKit delivers this ordering on physical hardware. Questions: Before invoking IOUserAudioDriver::Stop, does AudioDriverKit guarantee that StopDevice/StopIO has completed and that all outstanding IOOperationHandler invocations have returned? If not, what supported mechanism can a driver invoke during service Stop to prevent new BeginRead/WriteEnd callbacks and wait for already-entered callbacks to finish? Does calling superclass IOUserAudioDriver::Stop establish this callback-drain boundary? If so, how should hardware and USB resources be shut down when provider access is no longer permitted afterward? If termination cannot safely complete, is returning kIOReturnBusy a supported way to defer service termination? Is a subsequent retry guaranteed? I'm looking for the documented lifecycle and synchronization contract, rather than a workaround based on assumed callback ordering. Any clarification from Apple's DriverKit or Core Audio engineering team would be appreciated.

I am currently developing a kiosk system that incorporates an iPad along with a custom peripheral device. The two components are intended to communicate via USB serial. I have encountered a critical issue while working with the official DriverKit sample code provided at the following link: https://developer.apple.com/documentation/driverkit/communicating-between-a-driverkit-extension-and-a-client-app Model info : iPad Pro 12.9-inch (5th generation / M1 chipset) iPadOS 18.4.1 App Stops Functioning After Repeated Builds When I first build and run the sample code without any modifications, it works as expected. However, after making changes and running the app repeatedly on the iPad, it eventually reaches a state where the app stops functioning completely — no logs are printed, and device communication fails. Reinstalling the app or rebooting the iPad does not resolve the issue. Even when I revert to the original, unmodified sample code, the problem persists. Surprisingly, if I generate a new Bundle Identifier, the app functions normally again. I would like to ask: What could be causing this behavior? Have similar cases been reported before? For your reference, I’ve attached a video demonstrating the issue and the source code used during the recording: Source Code: https://drive.google.com/file/d/14whvWwuhrmS5VoR3sSKyNT-GpTPC_c_8/view?usp=sharing Video: https://drive.google.com/file/d/1SfqIkEphSDrvg-CKS6KBcJ1VBP3cPqCC/view?usp=sharing Request for USB Serial Communication Reference Currently, due to the issue above, I am unable to obtain a device instance at all. Even assuming this is resolved, I noticed that the sample code does not include any implementation or reference material for USB serial communication itself. Is there any official sample code or documentation available that demonstrates USB serial communication between an iPad and an external device using DriverKit? Difficulty Debugging Due to Missing os_log Output Another challenge I'm facing is the inability to view os_log output while connecting the USB device to the iPad. This significantly hinders the debugging process during DriverKit development. Are there any recommended or supported methods for accessing logs and debugging effectively in this environment?

Hi, Any idea about the timeline for approval? It's been sitting at submit for 8+ weeks. Email support will not help. Claiming no ETA and it's a separate team that reviews that. I've requested a few as initially had some mistake on submission. Here's one of it: Request ID: R7P34F4338 Team ID: H2SLQH5546 If this forum post can help escalate, that would be appreciated.

Hello, I’m developing a macOS iSCSI initiator intended for Mac App Store distribution. The host app handles iSCSI networking, while an embedded DriverKit extension subclasses IOUserSCSIParallelInterfaceController to expose remote iSCSI LUNs as macOS block devices. This is a virtual network-backed controller, without USB or PCI hardware. Development signing and builds succeed, but Mac App Store export fails because the driver’s distribution provisioning profile does not include: com.apple.developer.driverkit.family.scsicontroller Developer Support confirmed that our team’s approved entitlements include DriverKit UserClient Access, but do not include SCSIControllerDriverKit. They referred us to the forums for guidance. Could an Apple engineer clarify: Is this entitlement available for Mac App Store distribution of a virtual iSCSI controller? Does it require separate approval, and what is the correct application channel? I submitted a System Extension entitlement request selecting “SCSI Controller.” Is that the correct process? submitted request: XNX9Q7TFZ3 Developer Support case: 102995412617 Thank you.

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

Hello, We submitted DriverKit entitlement request B5DLZTL8UM on 26 September 2026, and it still shows "Submitted". App: Cekrekin, an iPad photobooth app on the App Store Driver extension: com.cekrekin.photobooth.ios.PrinterDriver Requested: DriverKit and DriverKit USB Transport for vendor ID 4931 (0x1343), for the DNP DS-RX1 / DS-RX1HS dye-sublimation photo printer (product 0x0005). Only our own app opens the dext; other apps do not need user-client access. The driver works with development signing. On an iPad Air (M1) running iPadOS 27.0.1, it connects to the printer, reads its status, and prints. DNP provides no iPadOS driver, so our customers (photobooth operators) need this to print from an iPad over USB. We are also filing a Code-level Support request with a focused test project. Is there anything else we should provide to move the request forward? Thank you.

Hello, we're building a DriverKit USB driver for iPadOS (M-series iPads) that lets our photo booth app BoothDock Studio print directly to DNP dye-sublimation photo printers over USB-C. These printers have no AirPrint, and the manufacturer offers no iPadOS driver. With development signing everything already works end to end on an iPad Pro (M2) with a DNP QW410: the driver matches, the app talks to it through a user client, and prints come out. For App Store distribution, the App Store provisioning profile for the driver (eu.boothdock.studio.printerdriver) doesn't contain any DriverKit entitlements, so the export fails. We submitted entitlement requests on September 28 (8BRDTKT583) and October 16 (J33U28AA4D, USB Transport for vendor IDs 5202/4931/3350 plus UserClient Access). Both are still in status "Submitted". We also opened developer support case 102998974118. Is there anything else we should provide, or a way to get these requests reviewed? Any hint is appreciated. Thanks!

I have created a USB filter using Mac DriverKit, but the filter is unable to retrieve configuration information during startup. After the USB filter has started and registered the service, my app can send the configuration information to the filter. Therefore, I would like to know if there is a way to exit the USB filter and allow the system to take control of the USB device once the filter has exited. I have tried calling Terminate(0), but it did not work as even after the USB filter exited, the Finder still couldn't display the USB device.

I have requested two entitlements for my driver: "DriverKit USB Transport - VendorID" and "DriverKit UserClient Access" I have submitted them in Sep 20, and got no response or ETA on it. It's the only thing blocking the release of my driver. Request ID: C9ULM24X2U Team: F34U2UUGXX Status: Submitted What can I do to expedite this?

Hello, I have requested entitlements for my DriverKit-based driver, but the status has been "Submitted" since May 24, 2026. Below are the details of my request. Is there any way to expedite the process, as these entitlements are necessary for distributing the app? Also, what is the preferable way to follow up in such cases? Entitlements: DriverKit USB Transport - VendorID (0x0BDA), DriverKit UserClient Access Team: K89F9CL4ZU Request Id: 7W5RQ3D2X6 Requested At: May 24, 2026 Type: Team Status: Submitted Many thanks

I have developed a Driverkit extension which matches for iPadOS which is bundled within my app. My driver contains two different personalities - one with provider as USBDriverKit (USB3) and the other as PCIDriverKit (USB4). When enabled, the driver matches/loads, initiates the class with the right personality based on whether the device it matches is operating in USB3/USB4 and works as intended. Recently, we have come across an issue when operating in USB4 and below are the steps to reproduce. Platform: iPadOS 17 (Issue not observed following the same steps in iPadOS 18 and higher, though cannot be full sure as I have tested only in some versions of 18, 26 and 27). Tested in iPad having a USB-4 compatible port. Steps to reproduce: Install the app. This provides an option to enable the driver which comes with it from the app's system settings. Enable the driver from settings. Connect a device which is compatible with the driver in USB4 so that the specific personality can be loaded. Verify the same. With the driver still loaded, uninstall the application. On uninstallation, ideally, Apple's inbox IONVMeController should match on the re-enumeration and get loaded without a re-plug being required. However, this is not the case as the port becomes unresponsive. Even after a re-plug of the device, it still does not get detected by the iPad itself. This is specifically when I try to connect the device in USB 4 as this specific driver personality matches only in this case. If I try the same steps as above or try to connect the same device in USB3 after this issue has occured, the device gets detected and works as intended. To make the port to be usable again in USB4, a restart of the iPad has to be performed. Has this been observed before with PCIDriverKit or DriverKit in general? Is this some kind of a known limitation in iPadOS 17 in particular or does this have something to do with the iPad model too? Is there any workaround that can be followed to prevent this from happening?

Hi, I would like to update that we have a kext that has IOStorageFamily in OSBundleLibraries. I would like to know whether we can create DriverKit that support this family and embed in SystemExtension for deployment? and we have another kext that has combination of IOStorageFamily and IOUSBFamily in OSBundleLibraries. Please let me know whether such type of Kext can be converted into DriverKit. I am new to DriverKit development. Please let us know if there is any sample that has these bundles in DriverKit so that I can check. Please let us know if such are supported with DriverKit then what are the capabilities that we need to add in entitlement request so that it can get approved. Thanks & Regards, Mohmad Vasim

When a PCI DriverKit extension terminates abnormally while it has its IOPCIDevice open, IOPCIFamily's child crash recovery can panic the whole host. This happens on devices whose nub publishes an Expansion ROM entry in IODeviceMemory, which is typical of GPUs and common on other PCIe cards. What happens IOPCIBridge::childClientCrashRecoveryGated walks the nub's IODeviceMemory array to restore BARs. For each descriptor it computes barIndex from the register number. For the ROM (config offset 0x30) that index is 8, kIOPCIRangeExpansionROM. The function then reads child->reserved->configEntry->ranges[barIndex]->start without checking for NULL. In our case ranges[8] is NULL, and the kernel takes a data abort at FAR 0. In IOPCIFamily-726.0.5 (IOPCIBridge.cpp, around lines 7055–7085), the barIndex == kIOPCIRangeExpansionROM check comes after the dereference: uint8_t barIndex = (addressSpace.s.registerNum - kIOPCIConfigBaseAddress0) >> 2; // 0x30 -> 8 IOPCIRange *range = child->reserved->configEntry->ranges[barIndex]; // NULL here uint32_t bar = child->configRead32(addressSpace.s.registerNum) & ~0xF; if (bar != (range->start & 0xFFFFFFFF)) // faults ... if (barIndex == kIOPCIRangeExpansionROM || !(kIOPCIRangeFlagBar64 & range->flags)) // too late Environment Mac Studio (M4 Max), macOS 26.7.1 (25G241), IOPCIFamily 2.9 PCIe GPU in a Thunderbolt 5 eGPU enclosure, third-party PCI DEXT (development-signed) The nub's IODeviceMemory has four entries, the last a 128 KB Expansion ROM Panic signature Two panics, both with the same signature. The panicked task is the DEXT, and IOPCIFamily is the only kext in the backtrace. Kernel data abort, ESR 0x96000006, FAR 0x0, pc = IOPCIFamily + 0x19b5c x2 = 0x30 (ROM config offset), x23 = 0x8 (barIndex), x27 = 0x0 (range) faulting instruction: ldr w2, [x27] Questions Has anyone else seen host panics in crash recovery after a PCI DEXT died? Other projects document "don't kill the driver process, or crash recovery may panic the machine," and this may be the same root cause. Is there a supported way for a DEXT to avoid this? For example, can a driver keep the ROM descriptor out of the recovery path, or is avoiding DEXT crashes the only mitigation until a fix ships? We filed this as FB25117710. If you hit the same panic, please reference that number in your own Feedback so the reports can be linked.

Hi everyone, I'm building rewindDV, a macOS app for preserving recordings from older FireWire tape cameras and decks. Capture works on our development hardware, and I'm trying to get the PCI transport entitlement needed to move forward with Developer ID signing and notarization so testers can use it with SIP enabled. Our two original requests have been pending since August 1. Developer Support confirmed that DriverKit and UserClient Access are present, but PCI transport approval is still missing. They suggested resubmitting, so I sent a consolidated request today and added the new number to the existing support case. Here are the references: Original requests: 265MP3ZN42 and 49L9RB632H — August 1, 2026; both still showed Submitted today. New request: 5728BY853G — October 3, 2026. Developer Support case: 102964703572. We're requesting DriverKit PCI (PrimaryMatch) for Developer ID distribution, specifically com.apple.developer.driverkit.transport.pci with IOPCIPrimaryMatch = 0x590111C1. That's PCI vendor 0x11C1 (4545 decimal), device 0x5901 (22785 decimal): the Agere/LSI FireWire OHCI host controller, not the downstream camera or deck. We develop the software, not the controller, and are requesting only that exact pair. PCI development access is already assigned. Could someone familiar with the DriverKit review process check whether the new request is in the right queue and whether we're missing anything? I'd also appreciate guidance on which request to keep active, since I haven't cancelled either original. I understand there's no guaranteed turnaround time. After nine weeks, I'd just like to make sure nothing is waiting on us. Happy to provide more technical details if helpful. Thanks for your help!

Hello, On July 30, 2026 we submitted a DriverKit USB Transport - VendorID capability request for our iPadOS driver extension. The request ID is 83H9997N3G, team ID W33S637JJQ. Eight weeks later it still shows "Submitted". Developer Support (case 20000135736763) told us a separate team handles these requests and will contact us. We have not heard from that team yet. The driver works with development signing. Without the distribution entitlement we cannot upload a build to TestFlight. Is there anything else we should provide, or a way to find out where the request is in the queue? Thanks, Stepan

Environment: macOS 26.6.2 (25G83), Apple silicon Xcode 26.6 (17F113) DriverKit SDK 25.5 I am implementing a DriverKit IOService with an IOUserClient. This is a lifecycle and object-ownership question independent of the device protocol. The intended design admits at most one user client during a provider lifetime. Lifecycle methods run on the provider’s default queue, while IOUserClient ExternalMethod requests run on a separate serial IODispatchQueue. At most one device request may be in flight. The shutdown invariant we need is: Stop accepting new requests. Allow every accepted request to complete exactly once, or cancel it. Observe completion of the operation queue’s cancellation handler. Call the inherited Stop implementation last. Perform no provider access afterward. The relevant public documentation is: IOService::Stop: https://developer.apple.com/documentation/driverkit/ioservice/stop IODispatchQueue::Cancel: https://developer.apple.com/documentation/driverkit/iodispatchqueue/cancel IOService::SetDispatchQueue: https://developer.apple.com/documentation/driverkit/ioservice/setdispatchqueue For the normal path, the proposed sequence is conceptually: Stop(provider): close request admission operationQueue->Cancel(cancellationHandler) wait for the cancellation handler from the separate queue super::Stop(provider) I need clarification of the complete supported public API contract: If IODispatchQueue::Cancel returns a non-success result, is its cancellation handler still guaranteed to execute? If it is not, what supported action lets Stop keep the provider and user client valid until previously accepted work is no longer capable of accessing them? Is it supported for the provider and its one user client to share the provider-owned serial operation queue? If the IOUserClient stops independently, must it own and cancel a separate queue, or is there a supported per-client drain mechanism that does not cancel provider-owned work? Is the driver’s public IOService::Stop override guaranteed to run on every termination path where accepted user-client work must be drained, including when the provider is already inactive or the DriverKit server has slept? If not, which public lifecycle callback supplies that drain point? Is blocking the provider’s default queue inside Stop while awaiting the cancellation handler from a separate operation queue the supported interpretation of “wait for your cancellation handlers”? If not, what public continuation mechanism should be used before calling inherited Stop? We also observed one power-management panic after sleep/wake: HiMDScsiDriver::setPowerState(..., 0 -> 4) timed out after 20342 ms The DEXT does not currently override SetPowerState. This panic motivates the lifecycle review, but I am not treating it as proof that the Stop/drain design caused the timeout. I am looking specifically for a supported public DriverKit sequence. I do not want to rely on private framework entry points or infer object-lifetime guarantees from a successful build or experiment.

I am new to macOS development and presently tearing my hair out trying to get a driverkit extension to build. I have tried following the instructions here: https://developer.apple.com/documentation/driverkit/communicating_between_a_driverkit_extension_and_a_client_app namely, disabling SIP, but I am still unable to get my extension to build. The instructions say to set the code signing identity to "Sign to Run Locally" for all three targets, but this is not listed as an option for the driver extension.