Since macOS 26.4 Beta 1, virtual HID devices created via DriverKit can no longer intercept key events from the built-in MacBook keyboard. External keyboards still work. This is confirmed and tracked here: https://github.com/pqrs-org/Karabiner-Elements/issues/4402 One possible lead (from LLM-assisted analysis of Apple's open-source IOHIDFamily code and cross-referencing community reports): macOS 26.4 Beta may have introduced or modified a security policy referred to as com.apple.iohid.protectedDeviceAccess, which could block IOHIDDeviceOpen for the Apple Internal Keyboard connected via SPI transport (AppleHIDTransportHIDDevice). This appears related to a "GamePolicy" check in IOHIDDeviceClass.m that gates whether processes can open HID devices. This has not been independently verified and may or may not be the root cause. This has far-reaching consequences. Karabiner-Elements alone has over 21,000 GitHub stars and is used by hundreds of thousands of macOS users for keyboard customization, accessibility workflows, ergonomic setups, and multilingual input. This change completely breaks its core functionality on any MacBook. Beyond Karabiner, this affects every developer building keyboard remapping, input customization, or accessibility tooling via DriverKit virtual HID devices — including commercial applications currently in development. I'd argue that the power and flexibility of keyboard customization on macOS is a genuine competitive advantage for the platform. Developers and power users choose Macs partly because tools like this exist. Restricting this capability would be detrimental to the ecosystem and to Apple's appeal among professional users. I'd like to understand: is this an intentional security change or a regression? If intentional, is there a migration path?

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?

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

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.

Hi everyone, I observed a behavior with AirPrint from an iPhone and wanted to confirm if this is expected behavior from iOS. Scenario tested: File type: Photo Print-quality selected by the user: Normal Observation (from packet capture): When checking the PCAP for the request sent from the iPhone, the print-quality attribute is always sent as high, even though the user selected Normal in the UI. Question: Is this an expected behavior in iOS/AirPrint where photos are always sent with print-quality=high regardless of the user-selected print quality? Or could this be a bug?

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