Hello, I have crated a DriverKit driver for macOS and iPad M-series if I ever get the mac driver working. I have the correct entittlements, and matching provisioning profile downloaded manually. The driver loads (no errors!), and is visible in ioreg below the usb device (when plugged). The issue is that I never get any log from the driver, have reduced to minimal working code (below). When I debug with lldb, I load the symbols for my driver and break on init and Start - but lldb never triggers == never calls start or init. This is also why no logs. When I unplug the device, the driver process (ps aux) keeps running, causes a hard crash of the Mac with dext remove/or kill driver.dext process. I have asked Claude - but its just running in circles: check Info.plist=ok, check entitlements=ok, check code (minimal)=ok, check iig=ok, check provisioning profile=ok, check build settings=ok, check ioreg=ok, check code signature=ok, start over I don't get any log from my driver, which is consistent with init() not being called. All logs from kernel & friends (AMFI) do show the driver loading - no errors. Any tips appreciated! // USBDriver.iig #ifndef USBDriver_h #define USBDriver_h #include <USBDriverKit/IOUSBHostInterface.iig> class USBDriver: public IOService { public: virtual bool init() override; virtual void free() override; virtual kern_return_t Start(IOService * provider) override; virtual kern_return_t Stop(IOService * provider) override; }; // USBDriver.cpp #include <os/log.h> #include <DriverKit/DriverKit.h> #include "USBDriver.h" bool USBDriver::init() { if (!super::init()) return false; os_log(OS_LOG_DEFAULT, "terminal.driver: init()"); return true; } kern_return_t IMPL(USBDriver, Start) { os_log(OS_LOG_DEFAULT, "terminal.driver: Start()"); kern_return_t ret = super::Start(provider); if (ret != kIOReturnSuccess) { os_log(OS_LOG_DEFAULT, "terminal.driver: super::Start failed: 0x%08x", ret); return ret; } os_log(OS_LOG_DEFAULT, "terminal.driver: Start() success"); return super::Start(provider); } kern_return_t IMPL(USBDriver, Stop) { os_log(OS_LOG_DEFAULT, "terminal.driver: Stop()"); return super::Stop(provider); } void USBDriver::free() { os_log(OS_LOG_DEFAULT, "terminal.driver: free()"); super::free(); }

Hello! I have app (macos and iPadOS platforms) with empbedded DEXT. The DEXT executable runs fine on both platforms (ver 26.2). Trying to execute from iPad App code: let sysExtWs = OSSystemExtensionsWorkspace.shared let sysExts = try sysExtWs.systemExtensions(forApplicationWithBundleID: appBudleId) but always getting OSSystemExtensionError.Code.missingEntitlement error. Which entitlement am I missing? Thank You!

We are trying to determine whether a third-party DriverKit HID dext can seize or intercept raw HID input reports from an external mouse through any top case–related path in the HID stack. Our dext is based on IOUserHIDEventDriver, and the goal is to receive raw input reports before they are translated into higher-level pointer events. Apple’s public HIDDriverKit documentation describes IOUserHIDEventDriver as the driver object responsible for dispatching pointer, digitizer, scrolling, and related HID-originated events, but it is not clear to us whether any “top case” path is actually exposed or supported for third-party matching in DriverKit. What we want to clarify is specifically about external mouse devices, not the built-in trackpad itself. Questions: Is there any officially supported way for a third-party DriverKit HID dext to bind through a top case–related path and receive raw HID input reports from an external mouse? Is “top case” something that third-party DriverKit drivers can meaningfully target for matching/attachment, or is it only an internal Apple implementation detail? If such a path exists, can it be used to seize raw reports before they are converted into higher-level pointer events? If not, what is the officially supported boundary for third-party DriverKit access to raw reports from external mouse-class HID devices? To be clear, we are not asking about synthesizing pointer events. We are asking whether a third-party DriverKit dext can directly observe or seize the original HID input reports from an external mouse by attaching through any top case–related portion of the HID stack. If “top case” is not a public DriverKit concept that third parties can target, confirmation of that would also be very helpful.

We are trying to intercept raw reports from the built-in MacBook haptic trackpad using a DriverKit IOUserHIDEventDriver dext. Our dext installs and activates successfully: OSSystemExtensionRequest finishes with result 0 systemextensionsctl list shows the dext as activated enabled the dext is embedded correctly in the app bundle However, it never attaches to the built-in trackpad IOHIDInterface. ioreg shows the built-in trackpad interface still matched only by Apple’s HID dext. We also observed that Apple’s own HID dext appears to use com.apple.developer.driverkit.builtin, while that entitlement is not available in our provisioning profile. Our dext specifically relies on: IOUserHIDEventDriver::handleReport(...) SetProperties() with kIOHIDEventDriverHandlesReport Questions: Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface? Is that entitlement public/requestable, or Apple-internal only? At what stage is it enforced: activation, personality matching, provider attach, or before Start()? If builtin is not available to third parties, is there any officially supported way to receive raw reports from the built-in MacBook trackpad in DriverKit? Our conclusion so far is that activation succeeds, but provider binding to the built-in trackpad fails due to built-in-only authorization/matching.

I'm in the process of writing a DriverKit USBHostInterface driver, and while I'm finally starting to get there, I've run into a bit of a frustration with logging. Naturally I have a liberal amount of os_log calls that I'm using to troubleshoot my driver. However I've noticed that they don't show up until after the first time my driver has loaded. Meaning, for example, suppose I make a new build of my driver and it's bundled user-mode app, install the bundle to /Applications, run the installer, verify it took with systemextensionsctl list, fire up Console and start streaming log entries, then plug in my device. I can see the log entries that show that my driver is loaded, etc., then a bunch of kernel -> log entries, but none of my Start method log entries. If I unplug my device and plug it in again, my log entries show up as expected. Why is this and, more importantly, how can I fix it? I'd like to see those log entries the first time the driver loads, if I could.

Trying to use IOLog to print out a message from a dext. When I try to use IOLog, I get , though I did not or thought I did not tag it as private. I have tried to update the info.plist file for the dext according to https://developer.apple.com/forums/thread/705810, but that has not helped, or perhaps I am not defining it correctly since it's a dext. Anyone else had this issue, and how did you fix it?

Hi Everyone, We are currently migrating a mature legacy KEXT to DriverKit for our PCIe SCSI storage controller (connected via Thunderbolt 3). During the DEXT load sequence, we have observed that the system automatically triggers a power state transition from State 0 (Off) to State 2 (On). However, this process results in a Kernel Panic due to a timeout after approximately 21 seconds. We have verified that our implementation of Start_Impl, UserInitializeController_Impl, and SetPowerState_Impl executes extremely fast, with a total execution time of less than one second. Specifically, SetPowerState_Impl returns kIOReturnSuccess immediately upon being called. Furthermore, our current Info.plist does not contain any IOPowerManagement dictionary or related keys. Despite the fast execution and the absence of explicit power management declarations in the plist, the kernel power management state machine (IOServicePM) still generates a 21-second timeout, leading to the following panic: Panic Log: panic(cpu 7 caller 0xfffffe0020be8fec): MySCSIDriver::setPowerState(0xfffffe2fb1a65c00 : 0xfffffe0020bfed88, 0 -> 2) timed out after 21257 ms @IOServicePM.cpp:5609 com.example.driver.dext: ( id: com.example.driver.dext; path: /Library/SystemExtensions/[UUID]/com.example.driver.dext; state: loaded ) Note on Previous Discussion: I would like to express my gratitude to Kevin from Apple DTS for the helpful discussion regarding the implementation of BundleParallelTask on the forums. Since then, we have shifted our development focus toward completing the overall management ecosystem, delivering a comprehensive operational interface for users, and handling specific user environments and behaviors. Our current priority is ensuring system stability—specifically resolving these Thunderbolt-related power management issues (sleep/wake)—to prepare the product for upcoming testing. I remain very grateful for the guidance provided on batch task optimization and intend to resume those optimizations once this critical stability baseline is secured. Technical Guidance Needed for PM Migration In our legacy KEXT, we utilized PMinit(), registerPowerDriver(), and joinPMtree() to precisely control the timing of power management registration. In transitioning to the DriverKit SDK, we have not found clear guidance on several key points: Standardized Migration Path: What is the recommended way to implement equivalent power management initialization (formerly PMinit) within a DriverKit subclass? In DriverKit, how should we replicate the behavior of manually calling registerPowerDriver and joinPMtree to ensure the driver is only monitored once the hardware is ready? Implicit Power Registration: Why does the system enforce a setPowerState(0 -> 2) transition on a subclass of IOUserSCSIParallelInterfaceController even when no IOPowerManagement dictionary is defined in the Info.plist? Is this a default behavior of the SCSI or PCI transport framework? Thunderbolt Specifics: Are there specific power proxying requirements or configurations for PCIe devices over Thunderbolt to avoid conflicts with the default IOPCIFamily power policies? Best Regards, Charles

My application will create a virtual touchpad. The problem I encountered is: click on the Product menu, select Archives, then select the Distribute App, then click on Drill Distribution, then click on Distribute, and then a prompt appears: Provisioning profile "Mac Team direct Provisioning Profile:"com.xxx.xxx"doesn't match the entitlements file's valuefor the com.apple.developer.driverkit.userclient-access entitlement. But My Identifiers Selected the:DriverKit Allow Any UserClient (development) Do I need toRequest a System Extension or DriverKit Entitlement Select "Virtual HID" in here? https://developer.apple.com/contact/request/system-extension/

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

While I welcome the arrival of a userspace implementation of drivers, DriverKit as it stands has some notable flaws. My main concern is the ability of open-source projects like HoRNDIS being able to access paid developer accounts and the limited entitlement scope (plus the waiting period) for what is essentially a hobbyist free project. Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed. Three concrete requests: A class-level or wildcard VID/PID entitlement for open source projects with a verifiable public repository A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers Published approval criteria and timelines so projects can plan accordingly Depreciating kexts without providing an accessible successor for community projects isn't security, it is gatekeeping access to hardware that is critically needed. Is this use case on the roadmap at all? Developers deserve a clear answer.

Hello, I'm trying to develop a driver that uses PCIe through the mac's thunderbold ports. I requested a PCI entitlement, and it's just an empty array in the entitlements file by default. I was wondering if the vendor ID submitted with my entitlement request is supposed to populate this dictionary? I'm currently getting an entitlement check failed from kernel: DK: IOUserServer and was unsure if the PCI entitlement configuration was incorrect. Default entitlement: <key>com.apple.developer.driverkit.transport.pci</key> <array> </array> I'd be happy to provide more information as needed, but any guidance would be much appreciated. Thanks in advance.

I'm struggling to build a driver for iPadOS in a particular project configuration. If I put the driver code and dext target into the same Xcode project which contains the iPad app, all is well. This is the way the Xcode driver template does it. However, I'd like to build and debug the dext on macOS, while eventually deploying on iPadOS. So I put the dext into a different project, which has a macOS target, a minimal iPadOS target and a DriverKit target. I made a workspace which contains both projects. I dragged the macOS project into the iPadOS project so that I can refer to the products of the macOS project (specifically, its driver target) as a dependency of the iPadOS target. Note that the main iPad app target depends on the driver target. So the workspace organization looks like this: Workspace iPad project main iPad app target (depends on driver) test project reference test project test macOS/iPad app target DriverKit dext target When I build the iPadOS target, it builds the dependent driver target in the macOS project, but it fails to link because Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a is not found. If I just build the driver target directly in Xcode, there is no such complaint. I looked closely at the build logs, and I see for the failed link, there are these two linker flags set which are not set in the successful case -debug_variant -fprofile-instr-generate I can't seem to control the generation of this flag. I tried turning off the Profile switch in the Scheme editor for the driver, but is makes no difference. When I directly build the driver target, no -fprofile-instr-generate is set and it compiles and links. When i build the driver as a dependency of another target, -fprofile-instr-generate is passed to the linker, which fails. The obvious workaround is to put the driver source code into a separate driver target in the iPadOS project, but I'd rather have just one DriverKit driver for both platforms, with a few settings (such as bundle ID) controlled by a configuration file. Has anyone else encountered this problem, and know of a workaround?

I am seeking clarification on whether the various driverkit entitlement families (com.apple.developer.driverkit.family.*) are available for development on my local Mac without requesting entitlements from Apple. My experience is inconsistent with public statements made by Apple, and I am wondering if there have been changes to development entitlements as of 2026. I am hoping there is something obvious that I have missed. At WWDC2022 Apple stated that "In MacOS... In fact, all DriverKit family entitlements are now available to use for development." On these very forums, Eskimo himself also suggested this was the case in 2024. However, my own experience has been that in my provisioning profile on my paid developer account, I am not able to obtain com.apple.developer.driverkit.family.networking for the purpose of developing a driver for unsupported hardware. As you can see, I do not have the networking entitlement: { .. "Entitlements" => { ... "com.apple.developer.driverkit" => true "com.apple.developer.driverkit.transport.usb" => [ 0 => { "idVendor" => "*" } ] And there appears to be no mechanism to add these entitlement:

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

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

I am writing a DriverKit driver for the first that uses the USBSerialDriverKit. The driver its purpose is to expose the device as serial interface (/dev/cu.tetra-pei0 or something like this). My problem: I don't see any logs from that driver in the console and I tried like 40 different approaches and checked everything. The last message I see is that the driver get successfully added to the system it is in the list of active and enabled system driver extensions but when I plug the device in none of my logs appear and it doesn't show up in ioreg. So without my driver the target device looks like this: +-o TETRA PEI interface@02120000 <class IOUSBHostDevice, id 0x10000297d, registered, matched, active, busy 0 (13 ms), retain 30> | { | "sessionID" = 268696051410 | "USBSpeed" = 3 | "UsbLinkSpeed" = 480000000 | "idProduct" = 36886 | "iManufacturer" = 1 | "bDeviceClass" = 0 | "IOPowerManagement" = {"PowerOverrideOn"=Yes,"DevicePowerState"=2,"CurrentPowerState"=2,"CapabilityFlags"=32768,"MaxPowerState"=2,"DriverPowerState"=0} | "bcdDevice" = 9238 | "bMaxPacketSize0" = 64 | "iProduct" = 2 | "iSerialNumber" = 0 | "bNumConfigurations" = 1 | "UsbDeviceSignature" = <ad0c16901624000000ff0000> | "USB Product Name" = "TETRA PEI interface" | "locationID" = 34734080 | "bDeviceSubClass" = 0 | "bcdUSB" = 512 | "USB Address" = 6 | "kUSBCurrentConfiguration" = 1 | "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} | "UsbPowerSinkAllocation" = 500 | "bDeviceProtocol" = 0 | "USBPortType" = 0 | "IOServiceDEXTEntitlements" = (("com.apple.developer.driverkit.transport.usb")) | "USB Vendor Name" = "Motorola Solutions, Inc." | "Device Speed" = 2 | "idVendor" = 3245 | "kUSBProductString" = "TETRA PEI interface" | "kUSBAddress" = 6 | "kUSBVendorString" = "Motorola Solutions, Inc." | } | +-o AppleUSBHostCompositeDevice <class AppleUSBHostCompositeDevice, id 0x100002982, !registered, !matched, active, busy 0, retain 5> | { | "IOProbeScore" = 50000 | "CFBundleIdentifier" = "com.apple.driver.usb.AppleUSBHostCompositeDevice" | "IOProviderClass" = "IOUSBHostDevice" | "IOClass" = "AppleUSBHostCompositeDevice" | "IOPersonalityPublisher" = "com.apple.driver.usb.AppleUSBHostCompositeDevice" | "bDeviceSubClass" = 0 | "CFBundleIdentifierKernel" = "com.apple.driver.usb.AppleUSBHostCompositeDevice" | "IOMatchedAtBoot" = Yes | "IOMatchCategory" = "IODefaultMatchCategory" | "IOPrimaryDriverTerminateOptions" = Yes | "bDeviceClass" = 0 | } | +-o lghub_agent <class AppleUSBHostDeviceUserClient, id 0x100002983, !registered, !matched, active, busy 0, retain 7> | { | "IOUserClientCreator" = "pid 1438, lghub_agent" | "IOUserClientDefaultLocking" = Yes | } | +-o IOUSBHostInterface@0 <class IOUSBHostInterface, id 0x100002986, registered, matched, active, busy 0 (5 ms), retain 9> | | { | | "USBPortType" = 0 | | "IOCFPlugInTypes" = {"2d9786c6-9ef3-11d4-ad51-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} | | "USB Vendor Name" = "Motorola Solutions, Inc." | | "bcdDevice" = 9238 | | "USBSpeed" = 3 | | "idProduct" = 36886 | | "IOServiceDEXTEntitlements" = (("com.apple.developer.driverkit.transport.usb")) | | "bInterfaceSubClass" = 0 | | "bConfigurationValue" = 1 | | "locationID" = 34734080 | | "USB Product Name" = "TETRA PEI interface" | | "bInterfaceProtocol" = 0 | | "iInterface" = 0 | | "bAlternateSetting" = 0 | | "idVendor" = 3245 | | "bInterfaceNumber" = 0 | | "bInterfaceClass" = 255 | | "bNumEndpoints" = 2 | | } | | | +-o lghub_agent <class AppleUSBHostInterfaceUserClient, id 0x100002988, !registered, !matched, active, busy 0, retain 6> | { | "UsbUserClientBufferStatistics" = {"IOMemoryDescriptor"=0,"IOBufferMemoryDescriptor"=0,"IOSubMemoryDescriptor"=0} | "IOUserClientCreator" = "pid 1438, lghub_agent" | "UsbUserClientBufferAllocations" = {"Bytes"=0,"Descriptors"=0} | "IOUserClientDefaultLocking" = Yes | } | +-o IOUSBHostInterface@1 <class IOUSBHostInterface, id 0x100002987, registered, matched, active, busy 0 (5 ms), retain 9> | { | "USBPortType" = 0 | "IOCFPlugInTypes" = {"2d9786c6-9ef3-11d4-ad51-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"} | "USB Vendor Name" = "Motorola Solutions, Inc." | "bcdDevice" = 9238 | "USBSpeed" = 3 | "idProduct" = 36886 | "IOServiceDEXTEntitlements" = (("com.apple.developer.driverkit.transport.usb")) | "bInterfaceSubClass" = 0 | "bConfigurationValue" = 1 | "locationID" = 34734080 | "USB Product Name" = "TETRA PEI interface" | "bInterfaceProtocol" = 0 | "iInterface" = 0 | "bAlternateSetting" = 0 | "idVendor" = 3245 | "bInterfaceNumber" = 1 | "bInterfaceClass" = 255 | "bNumEndpoints" = 2 | } | +-o lghub_agent <class AppleUSBHostInterfaceUserClient, id 0x10000298a, !registered, !matched, active, busy 0, retain 6> { "UsbUserClientBufferStatistics" = {"IOMemoryDescriptor"=0,"IOBufferMemoryDescriptor"=0,"IOSubMemoryDescriptor"=0} "IOUserClientCreator" = "pid 1438, lghub_agent" "UsbUserClientBufferAllocations" = {"Bytes"=0,"Descriptors"=0} "IOUserClientDefaultLocking" = Yes } more details in my comment.

I have a driver extending IOUserUSBSerial and I want the device to show up as /dev/tty.mycustombasename-123 and /dev/cu. respectively. How can I achieve that?

In the Developer portal, I'm attempting to add the "DriverKit UserClient Access" to an App ID that is assigned to a DEXT that we are developing. Once I have filled out the form and clicked "Submit" the screen goes bank and stays blank even after a long delay. The original Capability Request tab's entry for "DriverKit UserClient Access" never changes from "No Requests". I have tried this on two successive days, with the same result.

My application installs a system extension. When I try to remove the app from the Applications folder (cmd + backspace) I get an error message: "The operation can’t be completed right now because another operation is in progress, such as moving or copying an item or emptying the Bin." According to systemextensionsctl the extension state is "terminating for uninstall but still running". I can see an error in the console logs: kernelmanagerd Failed to terminate dext com.my.driver-dk, error: Kernel request failed: (os/kern) invalid address (1) sysextd a category delegate declined to terminate extension with identifier: com.my.driver-dk sysextd failed to terminate extension with identifier: com.my.driver-dk: Optional(Error Domain=kernelmanagerd.KMError Code=38 "(null)") Issue occurs with macOS 13 - works fine with macOS 12 and macOS 11 What is the problem here? Have there been any changes in macOS in that regard?