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!

I created a custom class that inherits from IOUserSCSIPeripheralDeviceType00 in the DriverKit SCSIPeripheralsDriverKit framework. When I attempted to send a vendor-specific command to a USB storage device using the UserSendCDB function of this class instance, the function returned the error: kIOReturnNotPrivileged (iokit_common_err(0x2c1)) // privilege violation However, when using UserSendCDB in the same way to issue standard SCSI commands such as INQUIRY or Test Unit Ready, no error occurred and the returned sense data was valid. Why is UserSendCDB able to send standard SCSI commands successfully, but vendor-specific commands return kIOReturnNotPrivileged? Is there any required entitlement, DriverKit capability, or implementation detail needed to allow vendor-specific CDBs? Below are the entitlements of my DriverKit extension: <dict> <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <integer>[number of vendorid]</integer> </dict> </array> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-any-userclient-access</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.driverkit.family.scsicontroller</key> <true/> </dict> If there is any additional configuration or requirement to enable vendor-specific SCSI commands, I would appreciate your guidance. Environment: macOS15.6 M2 MacBook Pro

I am developing a macOS virtual audio device using an Audio Server Plug-In (HAL). I want the virtual device to be visible to all applications only when my main app is running, and completely hidden from all apps when the app is closed. The goal is to dynamically control device visibility based on app state without reinstalling the driver.What is the recommended way for the app to notify the HAL plug-in about its running or closed state ? Any guidance on best-practice architecture for this scenario would be appreciated.

在Developer app中现在注册按钮时置灰等,无法点击,我发送的联系邮件也没有得到回应,有什么办法解决吗

Hi! Following this ticket: https://developer.apple.com/forums/thread/808764?page=1#868010022 Is there any way to use the hardware RFID reading capabilities of an iPhone to read ISO15693 RF tags silently, and without a UI pop-up? Perhaps using other native iOS libraries than the NFC library? If not, is there a way for a business to request this feature be allowed in internally used apps only?

Hello everyone, We are in the process of migrating a high-performance storage KEXT to DriverKit. During our initial validation phase, we noticed a performance gap between the DEXT and the KEXT, which prompted us to try and optimize our I/O handling process. Background and Motivation: Our test hardware is a RAID 0 array of two HDDs. According to AJA System Test, our legacy KEXT achieves a write speed of about 645 MB/s on this hardware, whereas the new DEXT reaches about 565 MB/s. We suspect the primary reason for this performance gap might be that the DEXT, by default, uses a serial work-loop to submit I/O commands, which fails to fully leverage the parallelism of the hardware array. Therefore, to eliminate this bottleneck and improve performance, we configured a dedicated parallel dispatch queue (MyParallelIOQueue) for the UserProcessParallelTask method. However, during our implementation attempt, we encountered a critical issue that caused a system-wide crash. The Operation Causing the Panic: We configured MyParallelIOQueue using the following combination of methods: In the .iig file: We appended the QUEUENAME(MyParallelIOQueue) macro after the override keyword of the UserProcessParallelTask method declaration. In the .cpp file: We manually created a queue with the same name by calling the IODispatchQueue::Create() function within our UserInitializeController method. The Result: This results in a macOS kernel panic during the DEXT loading process, forcing the user to perform a hard reboot. After the reboot, checking with the systemextensionsctl list command reveals the DEXT's status as [activated waiting for user], which indicates that it encountered an unrecoverable, fatal error during its initialization. Key Code Snippets to Reproduce the Panic: In .iig file - this was our exact implementation: class DRV_MAIN_CLASS_NAME: public IOUserSCSIParallelInterfaceController { public: virtual kern_return_t UserProcessParallelTask(...) override QUEUENAME(MyParallelIOQueue); }; In .h file: struct DRV_MAIN_CLASS_NAME_IVars { // ... IODispatchQueue* MyParallelIOQueue; }; In UserInitializeController implementation: kern_return_t IMPL(DRV_MAIN_CLASS_NAME, UserInitializeController) { // ... // We also included code to manually create the queue. kern_return_t ret = IODispatchQueue::Create("MyParallelIOQueue", kIODispatchQueueReentrant, 0, &ivars->MyParallelIOQueue); if (ret != kIOReturnSuccess) { // ... error handling ... } // ... return kIOReturnSuccess; } Our Question: What is the officially recommended and most stable method for configuring UserProcessParallelTask_Impl() to use a parallel I/O queue? Clarifying this is crucial for all developers pursuing high-performance storage solutions with DriverKit. Any explanation or guidance would be greatly appreciated. Best Regards, Charles

Hello! We develop a SAS driver and a service application for DAS devices. When users in our application create a RAID array on the device: On the 1st step, our dext driver mounts a new volume. At this step DiskUtil automatically tries to mount it. As there is no file system on the new volume - the MacOS system popup appears "The disk you attached was not readable by the computer" On the 2nd step our application creates the file system on this new volume. So we do not need this MacOS system popup to appear (as it may frustrate our users). We found a way to disable the global auto mount but this solution also impacts on other devices (which is not good). Are there any other possibilities to prevent the popup "The disk you attached was not readable by the computer" from appearing?

1. 环境描述 (Environment) OS: macOS 26.2 Hardware: Apple Silicon (M1/M2/M3) DriverKit SDK: DriverKit 19.0 / 20.0 Arch: Universal (x86_64, arm64, arm64e) SIP Status: Enabled (Works perfectly when Disabled) 2. 问题现象 (Problem Description) 在开启 SIP 的环境下，USB 驱动扩展（Dext）能安装，但插入设备时无法连接设备（驱动的Start方法未被调用）。 驱动状态： MacBook-Pro ~ % systemextensionsctl list 1 extension(s) --- com.apple.system_extension.driver_extension (Go to 'System Settings > General > Login Items & Extensions > Driver Extensions' to modify these system extension(s)) enabled active teamID bundleID (version) name [state] * * JK9U78YRLU com.ronganchina.usbapp.MyUserUSBInterfaceDriver (1.3/4) com.ronganchina.usbapp.MyUserUSBInterfaceDriver [activated enabled] 关键日志证据 (Key Logs) KernelManagerd: Error Domain=NSPOSIXErrorDomain Code=8 "Exec format error" Syspolicyd: failed to fetch ... /_CodeSignature/CodeRequirements-1 error=-10 AppleSystemPolicy: ASP: Security policy would not allow process DriverKit Kernel: DK: MyUserUSBInterfaceDriver user server timeout dext的 embedded.provisionprofile 已包含： com.apple.developer.driverkit com.apple.developer.driverkit.transport.usb (idVendor: 11977)

I am trying to add a few properties to an IOUSBHostDevice but the SetProperties is returning kIOReturnUnsupported. The reason I am trying to modify the IOUSBHostDevice's properties is so we can support a MacBook Air SuperDrive when it is attached to our docking station devices. The MacBook Air SuperDrive needs a high powered port to run and this driver will help the OS realize that our dock can support it. I see that the documentation for SetProperties says: The default implementation of this method returns kIOReturnUnsupported. You can override this method and use it to modify the set of properties and values as needed. The changes you make apply only to the current service. Do I need to override IOUSBHostDevice? This is my current Start implementation (you can also see if in the Xcode project): kern_return_t IMPL(MyUserUSBHostDriver, Start) { kern_return_t ret = kIOReturnSuccess; OSDictionary * prop = NULL; OSDictionary * mergeProperties = NULL; bool success = true; os_log(OS_LOG_DEFAULT, "&gt; %s", __FUNCTION__); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = Start(provider, SUPERDISPATCH); __Require(kIOReturnSuccess == ret, Exit); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ivars-&gt;host = OSDynamicCast(IOUSBHostDevice, provider); __Require_Action(NULL != ivars-&gt;host, Exit, ret = kIOReturnNoDevice); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = ivars-&gt;host-&gt;Open(this, 0, 0); __Require(kIOReturnSuccess == ret, Exit); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = CopyProperties(&amp;prop); __Require(kIOReturnSuccess == ret, Exit); __Require_Action(NULL != prop, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); mergeProperties = OSDynamicCast(OSDictionary, prop-&gt;getObject("IOProviderMergeProperties")); mergeProperties-&gt;retain(); __Require_Action(NULL != mergeProperties, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); OSSafeReleaseNULL(prop); ret = ivars-&gt;host-&gt;CopyProperties(&amp;prop); __Require(kIOReturnSuccess == ret, Exit); __Require_Action(NULL != prop, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); os_log(OS_LOG_DEFAULT, "%s : %s", "USB Product Name", ((OSString *) prop-&gt;getObject("USB Product Name"))-&gt;getCStringNoCopy()); os_log(OS_LOG_DEFAULT, "%s : %s", "USB Vendor Name", ((OSString *) prop-&gt;getObject("USB Vendor Name"))-&gt;getCStringNoCopy()); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); success = prop-&gt;merge(mergeProperties); __Require_Action(success, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = ivars-&gt;host-&gt;SetProperties(prop); // this is no working __Require(kIOReturnSuccess == ret, Exit); Exit: OSSafeReleaseNULL(mergeProperties); OSSafeReleaseNULL(prop); os_log(OS_LOG_DEFAULT, "err ref %d", kIOReturnUnsupported); os_log(OS_LOG_DEFAULT, "&lt; %s %d", __FUNCTION__, ret); return ret; }

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

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 driver loads on top of. 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 a DriverKit USB driver for iPadOS that needs to communicate with a vendor-class USB device (bInterfaceClass = 0xFF) as I need to communicate with a USB device using a custom protocol over IOUSBHostPipe for bulk transfers. Current Configuration: Info.plist: IOProviderClass = IOUSBHostDevice Device: bDeviceClass = 0, bInterfaceClass = 0xFF (vendor-specific) What Works: Driver matches and loads successfully Start_Impl() executes device->Open() succeeds device->SetConfiguration() succeeds The Problem: uintptr_t iterRef = 0; kern_return_t ret = device->CreateInterfaceIterator(&iterRef); Result: ret = kIOReturnSuccess (0x0), but iterRef = 0 (empty iterator) What I've Tried: Matching IOUSBHostInterface directly - Driver is loaded, but extension never executed Current approach (IOUSBHostDevice) - Driver extension loads and starts, but CreateInterfaceIterator returns empty Question: Does iPadOS allow third-party DriverKit extensions to access vendor-class (0xFF) USB devices? That is, iPadOS, is there a way for a third-party DriverKit extension to access IOUSBHostInterface objects for vendor-class (0xFF) USB devices?