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

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.

Since upgrading to macOS 27 Golden Gate, my Mac Studio (M4) recognises my Logitech MX Brio 4K webcam, but no video feed is displayed. The camera appears to be detected by the system, but the video signal does not show up in: FaceTime Photo Booth Logitech Options+ I've spent quite a bit of time troubleshooting the issue, including following diagnostic steps suggested by Siri and Copilot, but everything points to a potential macOS-related problem rather than a hardware or configuration issue. Has anyone else experienced this with the MX Brio or other webcams on macOS 27 Golden Gate? I reported the issue to Apple through the Feedback app when Beta 1 was released, but so far I haven't received a response or found a workaround. Any insights or suggestions would be greatly appreciated. Thanks!

Im trying to enrol on apple developer program for last couple of years and its always failing with first click and saying cannot be created at this time i. i tried to open many cases with apple and no feedback . any solution .

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.

I have not seen a clear answer about this: https://developer.apple.com/forums/thread/776657 https://developer.apple.com/forums/thread/743639?answerId=775701022#775701022 Thus, I would like to pose: Is there any way to install a DriverKit extension locally for development and testing using a free developer account, or is development of DriverKit extensions gated behind a paid developer account? Thank you!

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.

Hello Apple Developer Support, We have submitted a DriverKit entitlement request for our iPadOS photo booth application, which uses a USB DriverKit extension to communicate with professional dye-sublimation photo printers over USB-C. Our request covers one USB Transport configuration with the following Vendor IDs: 0x1343 (4931) — DNP / Citizen 0x1452 (5202) — DNP 0x0D16 (3350) — HiTi The DriverKit extension is used exclusively by our own iPadOS application, and we do not require UserClient Access. Our entitlement request is currently pending. We would appreciate any guidance from the DriverKit team regarding the review of our request. Request ID: 2DN73H7DCY Thank you.

I have trouble with reading a file from an App Group with my System Network Extension. The app group container is found successfully. However the file read returns empty. In the app itself the same code runs fine and returns a string array of items found in the file. Code: func readFile() - [String] {         var jsonResult: [String] = []         guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: AppConstants.groupID) else {             fatalError()         }         let fileURL = containerURL.appendingPathComponent("file.json")         if let data = try? NSData(contentsOfFile: fileURL.path, options: .mappedIfSafe) as Data {             if let json = try? JSONSerialization.jsonObject(with: data, options: .fragmentsAllowed) {                 jsonResult = json as! [String]             }         }         os_log("jsonResult: %{public}@", jsonResult)         return jsonResult     } Log: default 09:42:19.486793+0200 app-network-extension container_create_or_lookup_app_group_path_by_app_group_ identifier: success default 09:42:20.105792+0200 app-network-extension jsonResult: ( ) Edit, after more digging: fileURL is different! App: file:///Users/me/Library/Group%20Containers/ SysExt: file:///private/var/root/Library/Group%20Containers/

I am developing a dext that is running into issues pertaining to IOConnectMapMemory (at least I think so). There are 3 parts of code that are involved, the dext (which allocates the memory in the first place), a user client library which is involved in connecting to the dext and releasing when the hardware is removed, and finally some processing code (at the user level) which executes on this shared block of memory from the dext. The shared memory is allocated using an IOBufferMemoryDescriptor: IOBufferMemoryDescriptor::Create(kIOMemoryDirectionNone, sizeof(sharedMemoryBlock), IOVMPageSize, &(ivars->mSharedMemoryBlockMemDesc)); The User Client Library acquires a mapped pointer to this memory by calling IOConnectMapMemory: IOConnectMapMemory(mConnect, kMemoryType_SharedMemoryBlock, mach_task_self(), (mach_vm_address_t*)&mUserClientSharedBlockPtr, (mach_vm_size_t*)&mSizeOfUserClientSharedBlock, kIOMapAnywhere); …which triggers the dext’s IOUserClient subclass' “CopyClientMemoryForType_Impl”. That code adds a retain and returns a pointer to the IOBufferMemoryDescriptor: case kMemoryType_SharedMemoryBlock: // error checks first (make sure it’s allocated and initialized, etc) ivars->mSharedMemoryBlockMemDesc->retain(); *memory = ivars->mSharedMemoryBlockMemDesc; break; IOConnectMapMemory returns the “mapped pointer” (in mUserClientSharedBlockPtr) to the User Client Library, which in turn provides it to the processing code. The processing code checks the pointer validity, and if valid, runs its processing. This worked fine with a kext implementation. This fails with dext implementation, because during the processing call (after validity check but during usage) the mapped pointer can become NULL, which seems to be against the design pattern, and causes the application to crash due to an access violation (dereferencing NULL). I assume I am doing something incorrect here, but I’m not seeing what it is. The memory was retained, so it should not be deleted until the User Client Library has released it, but the only release available would be IOConnectUnmapMemory, and that fails with “invalid argument” (0xE00002C2) after the device is hot-unplugged. I am not finding IOConnectMapMemory examples on developer.apple.com. I have verified via the forums that IOConnectMapMemory is still a recommended practice with DriverKit development: https://developer.apple.com/forums/thread/803947?answerId=862249022#862249022 . What’s the trick here for stability? The device is a peripheral which can be unplugged or turned off at any time, which would result in the dext and user client library code tearing down the structures and memory, but it should be able to do so safely without causing access violations. (Note, this has been simplified for the purpose of focusing the question, in reality there are 4 separate memory blocks which are shared in this fashion: two ring buffers, main engine status, and client status. They each use their own memory_type definition, but a general solution is needed and can be applied to all 4, and there can be multiple clients at any point in time).

I found some nice code that implements a NUT client, and now I want to take the next step -- I would like to get it to show up as a UPS for macOS. But I've never done anything with IOKit... and there don't seem to be a lot of examples of, maybe, IOPowerSources?

I'm building a virtual pen digitizer with HIDVirtualDevice (CoreHID, macOS 26.2, com.apple.developer.hid.virtual.device entitlement granted, Developer ID signed with the provisioning profile embedding the entitlement). The device is created and activated fine and shows up as expected: hidutil list: 0xface 0xbeef UsagePage 13 Usage 2 Transport Virtual "Hej Stylus Virtual Pen" AppleUserHIDEventService / AppleUserHIDEventDriver Report descriptor (Digitizer/Pen application collection, Stylus physical collection, 7-byte input report): 05 0D Usage Page (Digitizer) 09 02 Usage (Pen) A1 01 Collection (Application) 09 20 Usage (Stylus) A1 00 Collection (Physical) 09 42 Usage (Tip Switch) 09 32 Usage (In Range) 15 00 25 01 75 01 95 02 81 02 ; 2 bits 95 06 81 03 ; 6 bits padding (Const) 05 01 09 30 09 31 ; Generic Desktop X, Y 16 00 00 26 FF 7F 75 10 95 02 81 02 ; 0..32767, 16 bit each 05 0D 09 30 ; Digitizer / Tip Pressure 16 00 00 26 FF 1F 75 10 95 01 81 02 ; 0..8191, 16 bit C0 C0 I feed it a synthetic stream at 60 Hz (X sweep, Y fixed, tip switch down, in range, pressure ramping 0→8191) via dispatchInputReport(data:timestamp:) and observe the results with a global NSEvent monitor (.tabletProximity, .tabletPoint, .leftMouseDown/Up/Dragged, .mouseMoved) plus the raw CGEvent fields. What works tabletProximity: isEnteringProximity=1, pointingDeviceType=.pen, vendorID=0xFACE, tabletID=0xBEEF, systemTabletID assigned. All movement arrives as tabletPoint / mouseMoved with subtype == .tabletPoint; positions are exact. Tip switch maps to leftMouseDown / leftMouseUp correctly (verified by toggling the tip bit with pressure held at max). capabilityMask on the proximity event is 0x407 = NX_TABLET_CAPABILITY_DEVICEIDMASK | ABSXMASK | ABSYMASK | PRESSUREMASK — so the system declares pressure capability for this device. What doesn't NSEvent.pressure, kCGTabletEventPointPressure and kCGMouseEventPressure are always 0.000, on every event type, including with a constant maximum pressure value (8191). NSEvent.buttonMask is 1 (pen tip) and kCGTabletEventPointButtons is 1, so the report is being parsed — the pressure field just never makes it into the tablet event data. Things I've established / tried The pressure value is parsed and does influence touch/click: with tip switch held down and pressure held at 0, no mouse down is ever generated. With pressure ramping, the click happens at exactly 75 % of the logical range. Reading the open-source IOHIDEventDriver::parseDigitizerTransducerElement explains this: Tip Pressure is read with kIOHIDValueScaleTypeCalibrated, but only X/Y/Z elements get a calibration, and an uncalibrated element scales to −1…+1 — so raw 0…8191 becomes −1…+1 and the touch threshold (+0.5) sits at 75 %. Changing Logical Minimum to −8191 (so raw 0…8191 maps to 0…1) moves the click to exactly 50 % — confirming the model. Pressure in the event data is still 0. Adding Physical Minimum/Maximum and a Unit to the pressure element: no change. hidutil monitor no longer exists on macOS 26, so I can't inspect the IOHIDEvent digitizer fields directly. This looks like the same behaviour reported for kext-based digitizers since macOS 10.12 (developer.apple.com/forums thread "IOHIPointing dispatchAbsolutePointerEvent not works" and its sibling: "the pressure information is there from the transducer, the OS doesn't respond to it on 10.12+"). The tablet-pressure dispatch in the open-source IOHIDEventService::dispatchDigitizerEventWithOrientation is commented out, and the userspace IOHIDEventTranslation isn't open source, so I can't tell where the value is dropped. Questions Is pen pressure from a HIDVirtualDevice (or any generic HID digitizer handled by AppleUserHIDEventDriver) expected to reach NSEvent.pressure / kCGTabletEventPointPressure at all on current macOS? Or is that path reserved for vendor drivers posting tablet events themselves? If it is supported: which descriptor properties does the digitizer→tablet translation require for pressure — specific usages (Transducer Index, Barrel Switch, Tilt, Twist), Report ID, Physical range/Unit on the pressure element, a Feature report, or a particular device property (e.g. something in HIDVirtualDevice.Properties / kIOHIDDigitizer* keys)? Is there a documented way to set element calibration for a virtual device so Tip Pressure scales 0…1 instead of −1…+1 without abusing Logical Minimum? Is there a supported diagnostic on macOS 26 to see the IOHIDEvent digitizer fields (pressure, touch, event mask) that the event system builds from my reports, now that hidutil monitor is gone? Happy to file a Feedback with the full project and a sysdiagnose if that helps.

Device: iPhone 17 Pro 256GB Affected builds: • iOS 27 RC — 24A435 • iOS 27 public release — 24A437 Known working version: • iOS 26.7 DESCRIPTION I am seeing a reproducible total loss of touchscreen input on this specific iPhone 17 Pro when running iOS 27. Before today's test, the device was running iOS 26.7 and the touchscreen was working normally. On September 14, I updated through the official OTA Software Update to iOS 27.0 public release, build 24A437. Beta Updates were disabled. After the update completed, the iPhone booted normally and reached the Hello screen. The display renders normally. Physical buttons respond normally. However, all touchscreen input is completely unavailable. No taps or swipes are recognized anywhere on the display, so it is not possible to proceed past the Hello screen. REPRODUCIBLE ON IOS 27 RC The exact same behavior previously occurred on iOS 27 RC build 24A435. To eliminate backup corruption, user data, apps and settings as possible variables, I performed a complete clean restore of 24A435 using Apple Configurator. No backup was restored. No apps were installed. No user data was restored. No previous settings were restored. Immediately after the clean restore, at the initial Hello screen, touchscreen input was still completely unavailable. Restoring the same device back to iOS 26 immediately restored touchscreen functionality. REPRODUCTION HISTORY iOS 26.7 → Touchscreen works normally iOS 27 RC 24A435 → Touchscreen completely unresponsive after boot Clean restore of 24A435 → Touchscreen still completely unresponsive at the initial Hello screen Restore back to iOS 26 → Touchscreen functionality returns iOS 27 public 24A437 → Touchscreen completely unresponsive again after boot DIAGNOSTICS Apple has already performed: • Remote diagnostics — passed • MRI — passed • Multi-Touch diagnostic — passed None of these diagnostics detected a hardware failure. The issue was reported through Feedback Assistant before the public release: Feedback ID: FB24728805 I also have an active Apple Support case, and the device is being evaluated by an Apple Authorized Service Provider. QUESTION / TECHNICAL OBSERVATION The particularly unusual aspect is the repeatability across OS versions on the same physical device: iOS 26 → touch works iOS 27 → touch does not work iOS 26 → touch works again iOS 27 → touch does not work again I am not assuming that the root cause is purely software or purely hardware. I am interested in whether this could involve touchscreen/HID initialization, digitizer-related firmware, or an interaction between iOS 27 and a particular hardware/display/controller revision. Has anyone observed a similar condition where: • the display continues rendering normally; • physical buttons continue working; • all touchscreen input is lost immediately after booting iOS 27; • a clean restore of iOS 27 does not resolve it; and • restoring the same device to iOS 26 restores touchscreen functionality? If anyone has reproduced this on another iPhone 17 Pro or 17 Pro Max, the exact model and iOS build would be particularly useful. RELATED PUBLIC DISCUSSIONS Apple Support Community: https://discussions.apple.com/thread/256356702 MacRumors: https://forums.macrumors.com/threads/iphone-17-pro-touchscreen-completely-dead-on-ios-27-public-24a437-same-issue-on-rc-24a435.2489323/

I'm building a macOS app that creates a virtual gamepad (Xbox-style HID device) so games can see input coming from a companion mobile app — similar in spirit to Karabiner-DriverKit-VirtualHIDDevice, but for a gamepad rather than keyboard/mouse. I submitted a Capability Request for "HID Virtual Device" (com.apple.developer.hid.virtual.device) under Capability Requests in Certificates, Identifiers & Profiles: Request ID: H8Q3K9CK7Z Submitted: June 30, 2026 Status: still shows "Submitted" with no change, ~2.5 months later Two questions I'd appreciate guidance on: Is this request queue still actively processed? I haven't received any request for more information, and there's been no status change since submission. Is 2.5 months a normal wait right now, or should I be following up through a different channel? Is the app-level CoreHID entitlement (com.apple.developer.hid.virtual.device) actually sufficient for a gamepad to be detected by GameController.framework (i.e. GCController.controllers()), or does that require wrapping the virtual device in a DriverKit driver extension instead, similar to how Karabiner ships com.apple.developer.driverkit + .transport.hid + .family.hid.device + .family.hid.eventservice alongside this same CoreHID key, rather than relying on the CoreHID entitlement standalone? Any clarity on the right entitlement combination, and on whether I should expect movement on H8Q3K9CK7Z, would be a big help.

I've just shipped a signed NetworkingDriverKit driver for the Realtek RTL8127 10GbE PCIe NICs on Apple Silicon, source at https://github.com/stefb69/RTL812xLucy (directory RTL8127Dext). It runs at line rate (9.4 Gbit/s each way at MTU 1500, 9.9 with jumbo frames) with TSO, checksum offload and four TX queues by service class. Since there are very few public NetworkingDriverKit drivers to learn from, here is what cost me the most time, in case it saves someone else a week. Three of these are filed as feedback. TX packets from native Skywalk flows have a 2-byte data offset (FBxxxxxxxx). getDataVirtualAddress() / getDataIOVirtualAddress() return the buffer base; the frame starts at getDataOff(). BSD-path packets (ping, curl, ssh, DHCP) have offset 0, Network.framework flows (Safari, URLSession, App Store, codesign --timestamp) have offset 2. If you DMA from the base, everything "works" except every modern client, which sits in SYN_SENT. The headers don't mention it. getMaxTransferUnit() is the maximum MTU, not the current one (FBxxxxxxxx). It is read once at registerEthernetInterface() and becomes the hard ceiling for ifconfig mtu; return your current 1500 and jumbo frames fail with EINVAL before your dext is called. Don't call bpfAttach() on macOS 26.6 (FBxxxxxxxx). It worked once, then panicked the kernel inside IOSkywalkFamily when the dext was replaced while tcpdump was attached. Without it, tcpdump on your interface only sees host-path frames, not native flows, so debugging point 1 is done from the peer side. Smaller ones: the personality needs IOClass = IOUserNetworkEthernet and CFBundleIdentifierKernel = com.apple.iokit.IOSkywalkFamily, not IOUserService, or super::Start fails with 0xe00002bc. All queues are created disabled: setEnable(true) in setInterfaceEnable(), plus requestDequeue() on the TX queues when the link comes up. setMulticastAddresses() must be implemented or no multicast group is ever joined (mDNS and IPv6 solicited-node are silently dead). Release dispatch sources from the Cancel() completion block, not right after Cancel(), or the dext crashes at every upgrade. The dext bundle must be named .dext or the host app reports "Extension not found in App bundle". Dext os_log lines show up as kernel: messages with the .dext bundle as sender; use %{public}s. Performance question for Apple engineers: with eight or more parallel TCP senders at MTU 1500 the stack emits ~3 KB TSO packets at ~160k packets/s and the dext saturates one core around 4.5 Gbit/s (fine at MTU 9000, fine with one to four streams). Is IOUserNetworkPacketPoller the intended answer for per-packet cost in a NIC dext, and is there any guidance on batch sizes for IOUserNetworkTxSubmissionQueue dequeues?

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