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 issue 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. 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. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I'm working on a DriverKit driver. I have it running on macOS, including a very simple client app written in SwiftUI. Everything is working fine there. I've added iPadOS as a destination for the app as demonstrated in the WWDC video on DriverKit for iPadOS. The app builds and runs on my iPad, as expected (after a little work to conditionalize out my use of SystemExtensions.framework for installation on macOS). However, after installing and running the app on an iPad, the driver does not show up in Settings->General, nor in the app-specific settings pane triggered by the inclusion of a settings bundle in the app. I've confirmed that the dext is indeed being included in the app bundle when built for iPadOS (in MyApp.app/SystemExtensions/com.me.MyApp.MyDriver.dext). I also can see in the build log that there's a validation step for the dext, and that seems to be succeeding. I don't know why the app isn't being discovered -- or in any case surfaced to the user -- when the app is installed on the iPad. Has anyone faced this problem and solved it? Are there ways to troubleshoot installation/discovery of an embedded DriverKit extensions on iOS? Unlike on macOS, I don't really see any relevant console messages.

I have an app that captures USB storage device and sends some commands to it. The app has a privilege helper tool which captures the USB device. Everything was working fine upto macOS 15.2 but it 15.3 update broke the functionality. When the helper tool tries to capture the USB device, it is able to capture IOUSBHostDevice but fails to capture IOUSBHostInterface. The error is Code: 3758097097; Domain: IOUSBHostErrorDomain; Description: Failed to create IOUSBHostInterface.; Reason: Failed [super init] I have verified the UID, EUID, GID, EGID = 0 for the helper process. So by IOUSBHost documentation it should have worked. The code that cause the error inside the helper tool is func captureUSBInterface(interface: io_service_t) -> IOUSBHostInterface? { let queue = DispatchQueue(label: "com.example.usbdevice.queue2") var capturedInterface: IOUSBHostInterface? do { capturedInterface = try IOUSBHostInterface(__ioService: interface, options: .deviceCapture, queue: queue, interestHandler: nil) } catch { NSLog("Failed to capture USB interface: \(error)") return nil } return capturedInterface } The app has sandbox=False and is distributed outside of the App Store. Please advise (long-term, short-term solutions) on how to make this work.

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!

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!

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.

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?