We've developed a PCIDriverKit driver for the capture card on macOS and have identified an issue: CreateMemoryDescriptorFromClient can only read data from the user space to the driver, but cannot write data back to the user. typedef struct _MWCAP_EDID_DATA { uint64_t size; uint64_t uaddr; } MWCAP_EDID_DATA; // App size_t xxx::GetEdid(void *buff, size_t size) { MWCAP_EDID_DATA edid; edid.size = size; edid.uaddr = (uint64_t)buff; kr = IOConnectCallStructMethod( connect, kUserGetEdid, &edid, sizeof(MWCAP_EDID_DATA), NULL, NULL ); // kr is 0. But However, the data in the buffer remains unchanged; // it does not reflect the EDID copied from the DEXT. return size; } // Driver MWCAP_EDID_DATA *edid = (MWCAP_EDID_DATA *)input; IOMemoryDescriptor *user_buf_mem = NULL; IOAddressSegment segment; segment.address = edid->uaddr; segment.length = edid->size; // We have verified that the values in edid->uaddr and edid->size are consistent with what was set by the application. ret = CreateMemoryDescriptorFromClient(kIOMemoryDirectionOutIn, 1, &segment, &user_buf_mem); if (ret != kIOReturnSuccess) { os_log(OS_LOG_DEFAULT, "Failed to create memdesc with error: 0x%08x", ret); break; } IOMemoryMap* user_buf_map = nullptr; ret = user_buf_mem->CreateMapping(0, 0, 0, 0, 0, &user_buf_map); if (ret != kIOReturnSuccess) { os_log(OS_LOG_DEFAULT, "Failed to create mapping with error: 0x%08x", ret); OSSafeReleaseNULL(user_buf_mem); break; } // ... fill the user_buf_map with edid data ... // For example: // memcpy(user_buf_map->GetAddress(), source_edid_data, edid->size); // At this point we have also verified the data in user_buf_map->GetAddress(), which matches our expectations. OSSafeReleaseNULL(user_buf_map); OSSafeReleaseNULL(user_buf_mem); Please help take a look, thank you!

I want to create a DriverKit driver and send vendor-specific commands to the storage device. Since UserClient is required to access the DriverKit driver from the app, I am attempting to implement it by referring to the following sample code. [Communicating between a DriverKit extension and a client app] I want to add com.apple.developer.driverkit.allow-any-userclient-access to the driver's Entitlements, submit a Capability Request on the developer site, and create a Provisioning Profile. However, I don't know how to enable com.apple.developer.driverkit.allow-any-userclient-access. I am entering the following information in the “Request a System Extension or DriverKit Entitlement” form. Which entitlement are you applying for? : DriverKit Entitlement Which DriverKit entitlements do you need? : UserClient Access UserClient Bundle IDs : [Bundle ID of MyDriver] Describe your apps and how they’ll use these entitlements. : testing sample code However, even if this request is accepted, I believe only MyDriver will be permitted. How can I grant access to all UserClients?

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

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.

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?

iPhone16PM Clean DFU, no restore, no tweaks. Started on iOS 26.4.3 and still happening on iOS 26.4. Triggers: ∙ Editing Home Screen widgets ∙ Heavy media in Safari ∙ ProMotion UI transitions Panic log — 0x8badf00d watchdog timeout: userspace watchdog timeout: no successful checkins from SpringBoard in 180 seconds. service: backboardd Drivers: com.apple.driver.AppleAVD + com.apple.iokit.IOSurface Is there a solution for this? Thank you.

Hi, I’m looking for clarification from folks familiar with CoreHID rather than App Review, as the guys there have not responded to my post (https://developer.apple.com/forums/thread/820676) We have a sandboxed macOS app that creates a virtual HID device (HIDVirtualDevice) as described in Creating virtual devices https://developer.apple.com/documentation/corehid/creatingvirtualdevices To work at all, the app requires the entitlement: com.apple.developer.hid.virtual.device With this entitlement present, macOS shows the system prompt requesting Accessibility permission App would like to control this computer using accessibility features. Grant access to this application in Security and Privacy preferences located in System Preferences. when HIDVirtualDevice(properties:) is called. There is no mention of Accessibility in the HIDVirtualDevice documentation, but the behavior is reproducible and seems unavoidable. My question is therefore: Is creating a virtual HID device from userspace via HIDVirtualDevice considered inherently incompatible with Mac App Store distribution? In other words: Is the Accessibility prompt an expected side‑effect of this API? And if so, does that mean using HIDVirtualDevice is only practical for direct (non–App Store) distribution unless the app is explicitly an accessibility tool? I’m not asking about review policy details—just whether, from a technical/system point of view, HIDVirtualDevice is actually intended to be usable by App Store apps. For context, there seem to be public, non‑accessibility uses of Apple’s virtual HID infrastructure, like this recent post: https://developer.apple.com/forums/thread/820708 and corresponding Github repo this project. I don't know if these intend to use the App Store, but they might end up in the same situation. Any insights from people who’ve worked with CoreHID would be greatly appreciated. Thanks, Magnus

1) The circumstances: iPADOS~>18, USB still-imaging-gadget, 1-3 gadgets might connect simultaneously via USB-hub, proprietary DExt, UserClient App in developers' iPADs or in TestFlight. = 1 variation A) UserClientApp has attribute [Background modes][Enable external communications]. = 1 variation B) "active USB-hub" vs "passive". = 1 variation C) "ConsoleApp logs iPAD" vs "ConsoleApp is not started". = 1 the term "zombie" below assume issue: == after plug-in ConsoleApp logs "IOUsbUserInterface::init", "::start"; == UserClient never receives respective callback from IOServiceAddMatchingNotification == further IOKit APIs "teardown", "restart" and "re-enumeration of connected gadgets" doesn't reveal the zombie (while it sees another simultaneous gadget); == unplug of the gadget logs "IOUsbUserInterface::stop". =2) The situation when UserClient is in foreground: ~ everything is fine. Note in MAC OS everything (same DExt and UserClient-code) works fine in background and in foreground. =3) The situation when UserClient is in background (beneath ~"Files" or "Safari"): =3A) "1A=true" phys plugin causes zombie in ~1/20 cases (satisfactory) =3B) "1A=false" phys plugin causes zombie in ~1/4 cases (non-satisfactory) =3C) "1 variation B" and "1 variation C" reduce zombies by ~>30%. =3D) ConsoleApp logs with filter "IOAccessory" (~about USB-energy) always look similar by my eyes. =4) From Apple-store: "The app declares support for external-accessory in the UIBackgroundModes"..."The external accessory background mode is intended for apps that communicate with hardware accessories through the External Accessory framework."..."Additionally, the app must be authorized by MFi," =5) My wish/ask: =5 option A) A clue to resolve the "zombie-plugin-issue in background" in a technical manner. = E.g. find a straightforward solution that ~elevates UserClient's "privileges" in background like [Enable external communication]... E.g. what ConsoleApp-logs to add/watch to reveal my potential bugs in DExt or in UserClient? =5 option B) A way to pursue Apple-store to accept (without MFI) an UserClientApp with [Enable external communication].

Hello I'm testing an 'age range sharing' feature using the AgeRangeService API in an app we service. I approved 'Age Sharing' during testing. (For your information, my account is an adult account.) For repeat testing, I would like to delete the our app from 'Apps that requested user age information' or cancel the sharing status. However, there doesn't seem to be such a feature. Is there a way I can't find, or is this a feature that Apple doesn't offer?

Dear Apple CS, I’m working with NFC ISO15693 tags using NFCTagReaderSession / NFCISO15693Tag, and I’d like to read these tags in the background if possible. Is there any way to read this tag type without triggering the system NFC popup that iOS normally shows? Please note it will not be a public app, the app is meant for internal use for our employees only. is there an option to submit a special request for this use case? Thank you in advance!

Have a 2019 Ford Edge w/ Sync 3.4, wired carplay. Worked fine w/ iPhone 16 Pro on iOS 18. Upgraded to iPhone 17 Pro, came w/ iOS 26, carplay hasn't worked since. I've kept trying throughout new iOS 26 releases, lately with iOS 26.3 Public Beta 1, still not working. Have a long running issue with updates and system diagnostics as I've tried over the last few months: FB20739050 There is also a Apple support community thread with issues like this (and a ton of others) - my first post there was https://discussions.apple.com/thread/256138283?answerId=261613103022&sortBy=oldest_first#261613103022 I'm hoping here in the developer forums someone can maybe take a look at the feedback item and various system diagnostics to pin-point the issue. I'm a little concerned it's still not fixed this far into the follow-up point releases of iOS 26. Appreciate any help, thanks! --Chuck

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

I’m 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.

I have an iPhone 14 Pro. I downloaded the iOS 26 beta and had a SERIOUS error, rendering the phone unusable. I charged it to 60% and kept it plugged in while updating. While updating, I restarted several times at the Apple logo, then at the Welcome screen, and it had quite a few bugs with low battery warnings. When I turned it on, I noticed I had 1% (I thought it was strange). When it was plugged in, it wouldn't charge; it only had 1% left, and it also restarted every 2 minutes. Off-plugged, it did exactly the same thing. In the end, I had to go back to iOS 18.5; I had no problems with this version.

Just wanted to check here to see if anyone else is running into the issue of CarPlay not working at all on iOS 26 Beta 1, even with the update on Friday. I plug my phone in (wired) and CarPlay never shows up. I've seen a Reddit thread where other folks are seeing the same thing.

We're seeing a consistent issue where iPads with the A16 chip fail to connect to our BLE device, which uses a Silicon Labs chip running Gecko SDK 3.x. All other Apple devices — including older iPads and iPhones — connect without any problems. According to Silicon Labs, the issue stems from the iPad A16 sending an LL_CHANNEL_REPORTING_IND message (opcode 0x28) during connection establishment: Per Silicon Labs: "Currently the iPad 16 will send a message for LL_CHANNEL_REPORTING_IND (opcode 0x28). This is a feature that is not supported in Gecko SDK 3.x. Shortly after, the BLE module responds with an 'Unknown Response' (opcode 0x07), indicating that it does not support opcode 0x28 After this exchange the iPad stops sending meaningful transactions to the BLE module and eventually closes the connection. The BLE Module is responding to this unknown request as specified in the BT Core Spec Volume 6 Part B." Unfortunately, the firmware on these BLE modules cannot be updated remotely, and we've already shipped several thousand units to customers. Given how widely Silicon Labs' BLE modules are deployed, we suspect this issue could be affecting many other developers and products as well. We’re hoping Apple might offer a workaround or allow us access — even internally or unofficially — to suppress or bypass this feature in CoreBluetooth for this specific scenario. For example, is there a way to disable LL_CHANNEL_REPORTING_IND or instruct the stack to ignore the unknown response from the peripheral? We’re open to any workaround via CoreBluetooth (even private APIs or entitlements, if necessary) that would allow us to preserve compatibility without a mass recall. If there's an Apple engineer monitoring this, we'd be extremely grateful for guidance or escalation. Thank you!

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

While developing our driver, we've noticed that the *.ips report that contains the stacktrace of the crash is not always generated. I'm wondering why this report may not get generated, or if there's anything specific to do to guarantee it gets generated.

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 am trying to localize the CFBundleDisplayName and OSBundleUsageDescription of a driver that is part of an app. I am able to use InfoPlist.strings files to localize the Bundle display name for the app, but when I try to use the same file as part of the driver, the name displayed in settings for the app does not change correctly. In fact, it seems to follow the default language set in the xcode project. If the default language is not included in the suite of InfoPlist.strings files, it seems to take the string from the info.plist file. sometimes it just seems to take the English version regardless of the default language or tablet language. Has anyone had success with this?