In my app, I want to launch Apple Maps and start turn-by-turn navigation when the user taps a button. I referred to Apple’s documentation and sample projects and implemented the following code: if let url = URL(string: "maps://?t=m&daddr=(addr)") { self.carplayScene?.open(url, options: nil, completionHandler: nil) } This works only if Apple Maps has been launched at least once on the iPhone or in the CarPlay environment. If Apple Maps has never been opened before, it launches the app but does not automatically start navigation. However, once the user has opened Apple Maps at least once — either on the phone or through CarPlay — then navigation starts as expected from that point on. Is this behavior expected? Or is it a bug?

Hello, I have DriverKit SCSI driver (PCI through Thunderbolt). And there is some logic and command which should be send to device in UserAbortTaskRequest method. But I cannot find out a way UserAbortTaskRequest to be called by system, so cannot debug the code inside. In which cases IOUserSCSIParallelInterfaceController/DriverKit framework calls UserAbortTaskRequest ? Is there a way to imitate situation (in driver or in some external tool), so that UserAbortTaskRequest be called to debug such case?

Hi, In Linux we have this driver structure where the handlers are defined as below: static struct file_operations fops = { .owner = THIS_MODULE, .read = etx_read, .write = etx_write, .open = etx_open, .unlocked_ioctl = etx_ioctl, .release = etx_release, }; So when the user app calls open() with the appropriate file/device handle "etx_open" in the driver is acalled, etc. However, the Apple driver structure that is exposed to developers is different and it has changed drastically with the DriverKit architecture. I have some custom requests from the user app where I need to call this ioctl() type requests on my serial port "tty.myusbserial1234". My driver is derived from IOUserUSBSerial and is working fine for all other practical purposes except for such custom requirements. Has anyone encountered such a problem in MacOS DriverKit and what is the solution or an alternative? https://developer.apple.com/documentation/driverkit/communicating-between-a-driverkit-extension-and-a-client-app This gives a different approach, but the serial ports are accessed via open/read/write/close system calls and tcsetattr and other termios functions to set baud-rate and such. So, the above approcah is not suitable for my purpose. Any ideas/help is very much appreciated. Thanks.

Hi, we are listed for the MFI program as a licensed manufacturer. We have now started with the IAP3 sample code and the IAP chips to build up a USB communication between our accessory and an iOS device. We are looking for a sample project for the iOS part. Is there some available? The only official I can find is this: https://developer.apple.com/library/archive/samplecode/EADemo/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010079 This app is somehow outdated and from 2016. Is there something else available as a starting point? And how does this relate to IOKit since it is available for serial communication on iOS16 as well? Kind regards,

Hi, This is the code snippet in my driver for an usb uart device. I am trying to call standard cdc-acm command to set the Line Coding in the device, but fails with this error: "USBSendSetLineCoding - Failed : 0xe0005000, bytes transferred: 0" I guess the USB device is returning this error due to incorrect buffer or format. There is no proper documentation on how to use IOMemoryDescriptor when the data has to be passed down in a buffer to the usb stack. (IOUSBHostInterface->DeviceRequest()) Can anyone please point out what is wrong with this code and suggest a right method? void MyDriver::USBSendSetLineCoding(uint32_t BaudRate, uint8_t StopBits, uint8_t TX_Parity, uint8_t CharLength) { kern_return_t ret = kIOReturnSuccess; LineCoding *lineParms; uint16_t lcLen = sizeof(LineCoding)-1; lineParms = (LineCoding *)IOMalloc(lcLen); if (!lineParms) { MyDebugLog("USBSendSetLineCoding - allocate lineParms failed"); return; } bzero(lineParms, lcLen); lineParms->bCharFormat = StopBits - 2; lineParms->bParityType = TX_Parity - 1; lineParms->bDataBits = CharLength; OSSwapBigToHostInt32(BaudRate); lineParms->dwDTERate = BaudRate; IOBufferMemoryDescriptor* bufferDescriptor = nullptr; _controlInterface->CreateIOBuffer(kIOMemoryDirectionOut, lcLen, &bufferDescriptor); IOMemoryMap *map = nullptr; bufferDescriptor->CreateMapping(kIOMemoryMapReadOnly, 0, 0, 0, 0, &map); if(map == nullptr) { MyDebugLog("USBSendSetLineCoding - Failed to map memory in CreateMapping\n"); IOFree(lineParms, lcLen); bufferDescriptor->release(); return; } uint64_t ptr = map->GetAddress(); if(!ptr) { MyDebugLog("USBSendSetLineCoding - Failed to get Memory Address\n"); IOFree(lineParms, lcLen); bufferDescriptor->release(); map->release(); return; } memcpy(&ptr, lineParms, lcLen); uint8_t bmRequestType = kIOUSBDeviceRequestDirectionOut | kIOUSBDeviceRequestTypeClass | kIOUSBDeviceRequestRecipientInterface; uint16_t wValue = 0; uint16_t wIndex = _bControlInterfaceNumber; uint16_t bytesTransferred = 0; ret = _controlInterface->DeviceRequest(bmRequestType, kUSBSET_LINE_CODING, wValue, wIndex, lcLen, bufferDescriptor, &bytesTransferred, 1000); IOFree(lineParms, lcLen); map->release(); bufferDescriptor->release(); if (ret != kIOReturnSuccess) { MyDebugLog("USBSendSetLineCoding - Failed : 0x%x, bytes transferred: %d\n", ret, bytesTransferred); return; } return; } I am able to call DeviceRequest() successfully on the same interface for any other setting that requires no data buffer, such as, "ret = _controlInterface->DeviceRequest(bmRequestType, kUSBSEND_BREAK, wValue, wIndex, 0, NULL, &bytesTransferred, 1000);" So I think the "bufferDescriptor" is not properly created or the data is not copied correctly in this function for the failure. "ret = _controlInterface->DeviceRequest(bmRequestType, kUSBSET_LINE_CODING, wValue, wIndex, lcLen, bufferDescriptor, &bytesTransferred, 1000);" Any help is very much appreciated. Thanks in advance.

Starting with iOS 26, we've noticed that the accessoryImage in CPListItem is not working as expected in CarPlay. Previously, accessoryImage would appear in place of the accessoryType, but now it appears awkwardly next to the detailText, and the image itself is not rendering properly. We have submitted feedback to Apple multiple times, but the issue still persists in the latest beta releases. In general, there seem to be several CarPlay UI problems introduced in iOS 26. For example: In CPPointOfInterestTemplate, the pinImage is displayed at an excessively large size. Scroll positions in lists behave unexpectedly. CPInformationTemplate allows infinite scrolling, which seems unintended. Please take a look into these issues. Thank you.

I've made a dext and a user client that overrides IOUserSCSIPeripheralDeviceType00, with the object of writing device firmware to the driver. I can gain and relinquish exclusive access to the device, I can call UserReportMediumBlockSize and get back a sensible answer (512). I can build command parameters with the INQUIRY macro from IOUserSCSIPeripheralDeviceHelper.h and send that command successfully using UserSendCB, and I receive sensible-looking Inquiry data from the device. However, what I really want to do is send a WriteBuffer command (opcode 0x3B), and that doesn't work. I have yet to put a bus analyzer on it, but I don't think the command goes out on the bus - there's no valid sense data, and the error returned is 0xe00002bc, or kIOReturnError, which isn't helpful. This is the code I have which doesn't work. kern_return_t driver::writeChunk(const char * buf, size_t atOffset, size_t length, bool lastOne) { DebugMsg("writeChunk %p at %ld for %ld", buf, atOffset, length); SCSIType00OutParameters outParameters; SCSIType00InParameters response; memset(&outParameters, 0, sizeof(outParameters)); memset(&response, 0, sizeof(response)); SetCommandCDB(&outParameters.fCommandDescriptorBlock, 0x3B, // byte 0, opcode WriteBuffer command lastOne ? 0x0E : 0x0F, // byte 1 mode: E=save deferred, F = download and defer save 0, // byte 2 bufferID (atOffset >> 16), // byte 3 (atOffset >> 8), // byte 4 atOffset, // byte 5 (length >> 16), // byte 6 (length >> 8), // byte 7 length, // byte 8 0, // control, byte 9 0, 0, 0, 0, 0, 0); // bytes 10..15 outParameters.fLogicalUnitNumber = 0; outParameters.fBufferDirection = kIOMemoryDirectionOut; outParameters.fDataTransferDirection = kSCSIDataTransfer_FromInitiatorToTarget; outParameters.fTimeoutDuration = 1000; // milliseconds outParameters.fRequestedByteCountOfTransfer = length; outParameters.fDataBufferAddr = reinterpret_cast<uint64_t>(buf); uint8_t senseBuffer[255] = {0}; outParameters.fSenseBufferAddr = reinterpret_cast<uint64_t>(senseBuffer); outParameters.fSenseLengthRequested = sizeof(senseBuffer); kern_return_t retVal = UserSendCDB(outParameters, &response); return retVal; }

We have an IOUserSCSIPeripheralDeviceType00 class DEXT supporting USB attached devices. With some high-capacity drives, the default setPowerState can exceed 20s to complete. This triggers a kernel panic, although this drive behavior is not unexpected. With a kernel extension implementing similar functionality we see no such problem as it appears from reading of Apple open source the timeout was 100s. What changes will allow setPowerState to complete without the kernel panic? kernel panic report excerpt attached. panic-full-2025-09-04-063127.0003.txt

Hello everyone, I've encountered a very strange and persistent logging issue with my DriverKit DEXT and would appreciate any insights from the community. [Problem Summary] My DriverKit DEXT, along with its companion Swift app, is functionally working perfectly. I can repeatedly call methods in the DEXT from the app (e.g., a Ping-Pong test and a StaticProcessInbandTask call) and receive the correct response every time. However, the os_log messages within my IOUserClient subclass are only successfully recorded for the very first set of interactions. After that, all subsequent logs are completely missing. What's even stranger is that all successfully recorded logs are attributed to the kernel: process, even for purely user-space methods like ExternalMethod. [Development Environment] macOS: 15.7.1 Xcode: 16.4 Hardware: MacBook Pro M1 DEXT Logging Macro (Log.h): #include <os/log.h> #define Log(fmt, ...) \ do { \ os_log(OS_LOG_DEFAULT, "[%{public}s] " fmt, __FUNCTION__, ##__VA_ARGS__); \ } while (0) [Steps to Reproduce & Observed Behavior] The DEXT is successfully loaded via the companion app. I click the "Ping-Pong" button, then the "Process InBand" button in the app. The app's UI log correctly shows that the request was sent and a successful response was received from the DEXT. I repeat step 2 multiple times. Each interaction works flawlessly from the app's perspective. I then use the log show command to export the logs from this period, for example: log show --last 5m | grep "com.accusys.Acxxx.driver" > dext_logs.txt Observed Result (Log Content): In the dext_logs.txt file, I can only see the logs from the very first Ping-Pong and the very first Process InBand call. All subsequent, successful operations leave no trace in the logs. kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // { --- kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // --- } kernel: (com.accusys.Acxxx.driver.dext) [StaticPingPong] // { --- kernel: (com.accusys.Acxxx.driver.dext) [StaticPingPong] // --- } kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // { --- kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // --- } kernel: (com.accusys.Acxxx.driver.dext) [StaticProcessInbandTask] // { --- kernel: (com.accusys.Acxxx.driver.dext) [StaticProcessInbandTask] // --- } <--- END OF FILE (No new logs appear after this point) ---> [Core Questions] Why are logs in IOUserClient subclass only recorded once? Given the DEXT is clearly still running and processing requests, why would os_log calls only succeed in writing to the system log database on the first interaction? Why are all logs attributed to the kernel? Why would logs from 100% user-space code like ExternalMethod and StaticPingPong be attributed to the kernel process? [Solutions Attempted That Did Not Work] I have verified with ps aux that the DEXT process (com.accusys.Acxxx.driver) is running continuously in the background and has not crashed. Attempted to force-restart the logging service with sudo killall logd, but the issue persists. Performed the most thorough reset possible using systemextensionsctl reset followed by a full reboot, then reinstalled the DEXT. The issue remains exactly the same. Thank you for any possible help or suggestions Best, Charles

Hi, On macOS 11 and earlier versions, we provided users with the following script to uninstall our kext driver: sudo pkgutil --only-files --files com.magewell.ProCapture | tr '\n' '\0' | xargs -n 1 -0 sudo rm -vf sudo pkgutil --only-dirs --files com.magewell.ProCapture | grep ProCapture[^/]*$ | tr '\n' '\0' | xargs -n 1 -0 sudo rm -rvf sudo pkgutil --forget com.magewell.ProCapture sudo kextcache -system-caches However, this script no longer works on macOS 13 and returns the following error: It looks like you're trying to update the system caches. As of macOS 11, the personality cache is no longer in use for keeping kext matching information up-to-date. For more information, see `man kmutil`. This indicates we can no longer use kextcache -system-caches to clear our driver cache. This creates an issue where even after installing the new dext driver, the dext driver cannot run due to the presence of the old kext driver. We've tried various methods but haven't been able to completely uninstall the old kext driver - after every new system update, the old kext reappears. The specific process is as follows: This is the sequence I followed in my latest test - Device is running macOS 13 Ventura w/ 4247 Pro Capture kext driver installed kmutil inspect | grep -i magewell - this returns references to the kext files in /Library/Extensions, which is expected because I have not yet removed the 4247 kext driver - then I ran the following combination of your removal script and my removal steps: cd / sudo rm -r /Library/Extensions/ProCaptureDriver.kext sudo rm -r /Library/Extensions/ProCaptureEvent.kext sudo rm /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache.auxkc* sudo pkgutil --only-files --files com.magewell.ProCapture | tr '\n' '\0' | xargs -n 1 -0 sudo rm -vf sudo pkgutil --only-dirs --files com.magewell.ProCapture | grep ProCapture[^/]*$ | tr '\n' '\0' | xargs -n 1 -0 sudo rm -rvf sudo pkgutil --forget com.magewell.ProCapture sudo kextcache --clear-staging sudo kcditto sudo kmutil install --update-preboot sudo shutdown -r now - After this I ran 'kmutil inspect | grep -i magewell' and got no results, which seems good but... - then I ran the upgrade to macOS 15.7 Sequoia - Afterwards I ran 'kmutil inspect | grep -i magewell' and it returned references to the old /Library/Extensions kexts again, although the files no longer exist in /Library/Extensions - I then ran my cleanup process again (slightly different for Sequoia-available commands): sudo rm /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache.auxkc* sudo kextcache --clear-staging sudo kmutil rebuild sudo kcditto sudo kmutil install --update-preboot sudo shutdown -r now - Then I ran 'kmutil inspect | grep -i magewell' and got no results again - As a next test I ran a minor update to macOS 15.7.1, then ran 'kmutil inspect | grep -i magewell' and the references to the old kexts came back again We have indeed identified a solution to address this issue: kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName> However, this method requires booting into Recovery Mode, which is unacceptable for many of our customers. Especially for those who need bulk remote management, having personnel physically operate each machine one by one is simply not feasible. Therefore, is there a method to completely uninstall the kext driver while in normal mode? Thank you!

Hello everyone, We are migrating a KEXT storage driver to DriverKit. In our KEXT, we use a "one LUN = one Target" model and successfully create multiple targets in a loop during initialization. We are now trying to replicate this architecture in our DEXT. The issue is that only Target 0 is fully probed and mounted. For Target 1, the lifecycle silently stops after the first TEST UNIT READY command is successfully acknowledged. The macOS SCSI layer never sends any subsequent probe commands (like INQUIRY) to this target. The failure sequence for Target 1, observed from our logs (regardless of whether Target 0 is created), is as follows: AsyncCreateTargetForID(1) -> UserInitializeTargetForID(1) (Succeeds) UserProcessParallelTask(Target: 1, Opcode: TUR) (Succeeds) The DEXT correctly acknowledges the TUR command for Target 1 by returning kSCSITaskStatus_CHECK_CONDITION with UNIT ATTENTION in the Sense Data (Succeeds) <-- Breakpoint --> UserProcessParallelTask(Target: 1, Opcode: INQUIRY) (Never happens) Through log comparison, we have confirmed that the DEXT's response to the TUR command for Target 1 is identical to the successful KEXT's response. We have tried creating only Target 1 (skipping Target 0 entirely), but the behavior is exactly the same -> the probe still stalls after the TUR. We initially suspected a race condition caused by consecutive calls to AsyncCreateTargetForID(). We attempted several methods to ensure that targets are created sequentially, such as trying to build a "creation chain" using OSAction completion handlers. However, these attempts were unsuccessful due to various compilation errors and API misunderstandings. In any case, this "race condition" theory was ultimately disproven by our experiment where creating only Target 1 still resulted in failure. We would like to ask two questions: Is our inability to have a Target ID greater than 0 fully probed by macOS a bug in our own code, or could there be another reason we are unaware of? If we do indeed need a "one-after-another" creation mechanism for AsyncCreateTargetForID, what is the correct way to implement a "chained creation" using OSAction completion handlers in DriverKit? Thank you for any help or guidance. Best Regards, Charles

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

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

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?

When printing image/photo files via AirPrint, selected finishing options (e.g., Punch) are not applied unless a preset is chosen. reproduction steps: Select an image on iOS Tap Print → choose printer/server Set Finishing Options → Punch Print Observed: Finishing options not applied IPP trace shows no finisher attributes in the request working scenario: Select any Preset (e.g., Color) before printing Finishing options are then included in IPP and applied Note: Issue does not occur when printing PDFs from iOS; finisher attributes are sent correctly. Is this expected AirPrint behavior for image jobs, or could this be a bug in how iOS constructs the IPP request for photos?

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

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.

I’m prototyping a personal-use system that lets an iPhone with a physically attached controller act as an input device for a Mac. End goal: Use the iPhone as the transport and sensor host Use the attached physical controller for buttons/sticks Map the iPhone gyroscope to the controller’s right stick to get gyro aim in Mac games / cloud-streamed games such as GeForce NOW that don't support the gyro. What I’m trying to understand is whether Apple supports any path for this on macOS that does NOT require restricted entitlements or paid-program-only capabilities. What I’ve already found: CoreHID virtual HID device creation appears to require com.apple.developer.hid.virtual.device HIDDriverKit / system extensions appear to require Apple-granted entitlements as well GCVirtualController does not seem to solve the problem because I need a controller-visible device that other apps can see, not just controls inside my own app So my concrete question is: Is there any supported, entitlement-free way for a personal macOS app to expose a game-controller-like input device that other apps can consume system-wide? If not, is the official answer that this class of solution necessarily requires one of: CoreHID with restricted entitlement HIDDriverKit/system extension entitlement some other Apple-approved framework or program I’m missing I’m not asking about App Store distribution. This is primarily for local/personal use during development. I’m trying to understand the supported platform boundary before investing further. Any guidance on the recommended architecture for this use case would be appreciated.

We are looking for a solution (API, Frameworks) that would allow us to block any type of external device, including storage devices, HIDs, network adapters, and Bluetooth devices according with dynamic rules that comes from management server . This feature is important for endpoint security solutions vendors, and it can be implemented on other platforms and older versions of macOS using the IOKit framework and kexts. I have found one solution that can control the usage only of "storage" devices with the EndpointSecurity framework in conjunction with the DiskArbitration framework. This involves monitoring the MOUNT and OPEN events for /dev/disk files, checking for devices as they appear, and ejecting them if they need to be blocked.. Also, I have found the ES_EVENT_TYPE_AUTH_IOKIT_OPEN event in EndpointSecurity.framework, but it doesn't seem to be useful, at least not for my purposes, because ES doesn't provide AUTH events for some system daemons, such as configd (it only provides NOTIFY events). Furthermore, there are other ways to communicate with devices and their drivers apart from IOKit. DriverKit.framework does not provide the necessary functionality either, as it requires specific entitlements that are only available to certain vendors and devices. Therefore, it cannot be used to create universal drivers for all devices, which should be blocked. Any advice would be greatly appreciated!