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

Please can someone bump my support request which has been pending for 1 month. It is for DriverKit access. Thanks

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

We have a complete iPadOS DriverKit USB extension for a Stripe Reader M2 (USB-C, M-series iPad). Development builds sign and run. We cannot ship Ad Hoc, App Store, or Enterprise builds because the distribution DriverKit entitlements are either not granted or not present in the provisioning profile Apple generates. Stripe’s iOS USB instructions say to request the entitlement at developer.apple.com/system-extensions: select HID and USB Transport, and enter USB vendor ID 11369. Platform is iPadOS. The extension also needs com.apple.developer.driverkit. The host app uses com.apple.developer.driverkit.communicates-with-drivers. We have two teams. The driver bundle ID is prefixed with the host app bundle ID and signed with the same team. Inc — Team ID HPL6Q4V5TF (Development, Ad Hoc, App Store) Host app Driver extension com.atxinnovation.union.development com.atxinnovation.union.development.usbDriver com.atxinnovation.union.qa com.atxinnovation.union.qa.usbDriver com.atxinnovation.union.production com.atxinnovation.union.production.usbDriver These are not granted. Latest submission is system-extensions request 39WL64S3LR (September 3, 2026). That form has no status page, and we have received no email. LLC — Team ID 3MAPQA4NZ6 (Enterprise in-house) Host app Driver extension com.atxinnovation.union.enterprise com.atxinnovation.union.enterprise.usbDriver Capability request ACL9VQ3BA4. The portal shows DriverKit and DriverKit USB Transport – VendorID granted and enabled on com.atxinnovation.union.enterprise.usbDriver. The Universal Distribution profile POS Prod USB Driver (platform iOS, active, expires 2027/01/22, UUID a3627c1e-451d-4d62-b871-1cb6fe21431e, created 2026-09-02 16:05:20 UTC) lists those capabilities as enabled on the Review Provisioning Profile page. The downloaded profile does not contain them. Decoding it yields only: application-identifier com.apple.developer.team-identifier get-task-allow keychain-access-groups The string driverkit does not appear in the profile. We regenerated it five times, including deleting and recreating the profile, with the same result. DriverKit development profiles for the corresponding development App ID do contain com.apple.developer.driverkit and com.apple.developer.driverkit.transport.usb. Xcode then fails the archive: Provisioning profile "POS Prod USB Driver" doesn't include the com.apple.developer.driverkit entitlement. We also do not know which idVendor values the VendorID grant assigned. The extension must match them exactly. We need 11369. What we already tried July 30: Account Holder submitted DriverKit and DriverKit USB Transport for both teams through the system-extension Contact Us form. No confirmation email. That form does not collect bundle IDs. Those July requests later showed up on the host App ID com.atxinnovation.union.enterprise, not on the usbDriver App IDs. August 12: Resubmitted on each usbDriver App ID under Certificates, Identifiers & Profiles → Capability Requests. Enterprise request ACL9VQ3BA4. August 27: Developer Support case 20000149322724. The reply pointed us back at the capability status page. September 2: Enterprise grant appeared. Enabling it on the App ID and regenerating the distribution profile still produced a profile with no DriverKit entitlements. Developer Support case 102951939894. No resolution. September 3: Resubmitted the Inc team via the system-extensions form (39WL64S3LR). The form would not accept another LLC submission because that App ID is already granted. No status since. What we are Requesting Grant DriverKit, HID, and USB Transport (vendor ID 11369) for iPadOS — Development, Ad Hoc, and App Store — on the three Inc driver App IDs above. Assistance debugging the issue of failing to embed the already-granted DriverKit entitlements in the LLC Enterprise distribution profile for com.atxinnovation.union.enterprise.usbDriver, and confirmation of the assigned idVendor values.

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.

We have a macOS USBDriverKit DEXT for our own USB hardware and are currently blocked from production distribution while waiting for the required DriverKit managed capabilities. Team ID: 2H6U9GHYLR Correct request: Request ID: U577A4MPBB Submitted: July 10, 2026 Vendor ID: 0x39D3 (this is our official USB VID) Product IDs: 0x0011, 0x0012, 0x0101 Capabilities: DriverKit USB Transport - VendorID and DriverKit UserClient Access The request has now been pending for 10 weeks and 3 days. There is an unusual complication: we originally submitted request GTL6N6D8K9 on June 24, this request should have been disregarded, but Apple has approved it anyways, 10 weeks after submission. The corrected request (U577A4MPBB) is still not approved. Our implementation is complete and works in development. The production entitlement is now the only blocker preventing us from signing and distributing the driver. Is there any way to have someone check whether U577A4MPBB is correctly in the DriverKit entitlement review queue, or whether additional information is required from us? We can provide documentation confirming ownership of USB VID 0x39D3 if needed. Thank you Simon

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.

IOUSBHostDevice(ioService:options:queue:interestHandler:) with .deviceCapture succeeds — the device is mine, its mass-storage driver terminated. setConfiguration(1, matchInterfaces:) succeeds. The failure is the very next call: IOUSBHostInterface(ioService:options:queue:interestHandler:) on interface 0 returns IOUSBHostErrorDomain -536870199 (kIOReturnInternalError, 0xe00002c9). Exactly one interface node is published under the device, IOServiceGetBusyState reports it idle, and it is refused identically on every retry over several seconds and across repeated re-captures — so this is not a publication race or a stale node. With Full Disk Access granted to the app, the same call claims it on the first attempt, every time. So I'm stuck. I have no choice but to use FDA which I absolutely do NOT want to do. To anyone from DTS reading this, is this a valid reason for granting me com.apple.vm.device-access? It looks like using DriverKit might not work either because the Driverkit entitlements are also restricted. What is the solution here?

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

Hey, We are developing a dext that would like to match with all USB devices, no matter the vendor. We use VendorID = * in the plist of the Dext to help achieve this when running it locally without entitlements. I know that the transport.usb entitlement requires a list of Vendor id's, but is it possible to receive an entitlement which is suitable for all VID's? Kind of like this: <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <string>*</string> </dict> </array> Thanks

Entitlements requested: com.apple.developer.driverkit.userclient-access com.apple.developer.driverkit.transport.usb com.apple.developer.driverkit.transport.hid com.apple.developer.driverkit.family.hid.eventservice com.apple.developer.driverkit.family.serial com.apple.developer.driverkit.family.scsicontroller com.apple.developer.driverkit.family.networking com.apple.developer.driverkit.family.hid.device , and the base com.apple.developer.driverkit entitlement Hi all, We recently received a decline on the DriverKit entitlement set listed above. The response noted: "Technical details within DriverKit mean that it is not a viable solution for security block or broad-scale system modifications." I'd like to get some clarity on how to bring our request in line with what's approvable, and I'm hoping the forum (or a Code-Level Support engineer) can point us in the right direction. Context on what we're building: We develop a Data Loss Prevention (DLP) product for macOS. We already hold the Endpoint Security entitlement (com.apple.developer.endpoint-security.client) and use it in production today for our core monitoring and policy-enforcement functionality. Why we're requesting DriverKit specifically: ESF gives us visibility and the ability to authorize/deny many file and process events, but it does not give us the control we need over removable/peripheral hardware. Two concrete gaps in our DLP policy enforcement that we're trying to close: Blocking data exfiltration via USB-connected Android devices — when an Android phone is plugged in, it mounts as a USB mass-storage/MTP-style device, and our policy needs to be able to prevent it from mounting or being written to, on a per-policy basis (e.g., disable an endpoint's ability to copy files to a connected Android device). Camera blocking — disabling the built-in/USB camera device at the hardware transport level as part of a DLP policy, rather than a userspace toggle that a privileged process could bypass. Our understanding was that "com.apple.developer.driverkit.transport.usb" combined with the HID/USB family entitlements would let us implement a DriverKit-based USB filtering driver to enforce this. Given the decline language about "security block or broad-scale system modifications," it sounds like Apple's position is that DriverKit is not intended to be used to build a general device-blocking layer this way. What I'm hoping to learn: Is per-policy USB mass-storage/MTP mounting control (blocking a specific class of device, e.g., Android phones, from mounting or transferring files) something DriverKit is intended to support at all for third-party DLP vendors, or is this fundamentally out of scope regardless of how the request is written up? If it is in scope, what should we change in the entitlement request write-up (use case description, scoping of which entitlements we actually need vs. what we requested) to make it approvable? We may have over-requested — for example, do we need family.networking and family.serial at all for USB mass-storage/camera blocking, or should we narrow the request to just the USB transport + HID/SCSI entitlements? Is there a preferred way to demonstrate that our use case is a scoped, policy-driven enterprise DLP control (with IT/MDM deployment, not a consumer app) rather than "broad-scale system modification," or does the entitlement review not distinguish on that basis? Any pointers — either on scoping this request correctly, or on whether this is simply not achievable via DriverKit and we should be looking at a different API — would be much appreciated. Happy to provide more detail on our exact enforcement flow if that's useful for a Code-Level Support ticket. Thanks in advance

We ship an iPadOS app with an embedded USBDriverKit extension that drives Citizen/DNP dye-sub photo printers. It works: on a development-provisioned iPad the dext registers, matches, opens its user client and prints, verified on two units in hand (DNP DS-RX1 0x1343:0x0005, DNP QW410 0x1452:0x9201). The extension declares twelve IOKitPersonalities, each pinned to one exact idVendor/idProduct pair plus bConfigurationValue and bInterfaceNumber. Those twelve span two vendor IDs — 4931 (0x1343, Citizen Systems) and 5202 (0x1452, Dai Nippon Printing) — because the same printer families ship Citizen-badged on one and DNP-badged on the other. We have one USB Transport – VendorID request per vendor ID, both currently Submitted. Thread 842748 already answered the scope question for us, so I'm not asking that one: at twelve devices we read vendor-level as the right ask rather than twelve VendorID+ProductID requests, and we've kept the personalities narrow so the entitlement is a ceiling rather than what actually matches. Please correct me if that's the wrong reading for two vendor IDs rather than one. My actual question is about a mistake in one of the submissions. The older request also asked for UserClient Access, which we now understand is macOS-only (com.apple.developer.driverkit.userclient-access lists DRIVER_KIT and MAC_OS, not IOS). We don't need it — on iPadOS the app opens the dext's user client with com.apple.developer.driverkit.communicates-with-drivers, which needs no approval. Does an inapplicable entitlement on a submitted request need to be formally withdrawn, or is it simply ignored during review? I'd rather not leave a macOS-only entitlement sitting on an iPadOS request if that's something a reviewer has to resolve. If it does need correcting, what's the mechanism? Re-filing would create a third request, and I'd rather not muddy the queue. (Developer Support told me request handling is outside their scope, which is what brings me here.) Is there any way to indicate that two requests belong to one driver extension and are only useful together? Happy to post the Info.plist personalities or the dext's entitlements if useful. Thank you.

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.

Hi everyone, I am seeking clarification regarding the communication capabilities between an ESP32 microcontroller and Apple's latest devices, specifically the iPhone 16 Pro Max and iPad Pro, both equipped with USB-C ports. Background: MFi Certification: Historically, establishing communication between external devices and iOS devices required MFi (Made for iPhone/iPad) certification. But I remember this being necessary in the Lightning Cable to USB era. With the introduction of USB-C ports in recent iPhone and iPad models, there is an indication that MFi certification may no longer be necessary for certain peripherals. Perhaps I'm not confident on the terminology here: https://mfi.apple.com/en/who-should-join Project Requirements: I am working on a sensor research project that necessitates the collection of low-latency time-series data from an ESP32 microcontroller, which features a USB-C port. The data needs to be transmitted to an iPhone 16 Pro Max or iPad Pro. Bluetooth communication has proven insufficient due to its limited data transfer rates (~1.2 Mbps with L2CAP). While NEHotspot could be an alternative, it restricts the iPad's internet connectivity. Therefore, establishing a direct USB-C connection between the ESP32 and the iOS device appears to be the most viable solution. Questions: MFi Certification Necessity: Is MFi certification still required for an ESP32 microcontroller to communicate with iPhone 16 Pro Max or iPad Pro via USB-C? USB-C Communication Support: Do the iPhone 16 Pro Max and iPad Pro natively support serial communication over USB-C with microcontrollers like the ESP32? If not, are there recommended protocols or interfaces to facilitate this communication? App Development Considerations: Would developing a custom iOS application be necessary to handle data transmission from the ESP32 over USB-C? If so, are there specific APIs or frameworks provided by Apple to support this functionality? Data Transfer Rates: Considering the need for high-speed data transfer, are there any limitations or considerations regarding the data transfer rates achievable through a USB-C connection between the ESP32 and iOS devices? Thank you!

I'm trying to build the DriverKit template driver target in an Xcode project which contains an app targeting iPadOS 17. I've made no modifications to the DriverKit template. When building, I get this link error ld: file cannot be open()ed, errno=2 path=/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a in '/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a' anyone know how to fix this? My search turned up something about building llvm from sources, which seems like overkill to put a DriverKit driver into an iPad app.

I have a product that currently communicates to a piece of proprietary Medical hardware via USB. We have a driver created with USBDriverKit that is a hard requirement for this product to function. Currently, we are delivering an iPadOS application that utilizes the driver. Our next step is to create an SDK that includes all of the Frameworks and the driver utilized by the application. Since the driver is a system extension that lives in the application, how do we bundle it with our SDK and make it available for use by third-parties?

I have a workspace containing a DriverKit USB driver and the containing application that utilizes the driver. These are in separate projects. How do I configure the application project or the workspace so that, when I build the app, the driver is automatically built and copied into the application package as required for delivery? Currently I have to manually select the driver target, build, and then select the app target and build. In order to get the driver into the app, I have included it as a build-phase dependency but I had to hardcode the driver project output path and it doesn't build it automatically. Additionally, because I hard-coded the debug path, when I try and create an Archive to deliver the app, the app includes the debug version of the driver instead of the release version. I'm obviously doing this wrong because it is as clunky as can be.

I'm investigating supporting a touchscreen digitizer on macOS. I'd like to receive multi-touch reports from the device, and have them intercepted by my app. I also want to suppress the default absolute positioning 'mouse' behavior of the touch screen. The device exposes three HID interface: #0 - multi-touch (PrimaryUsagePage 0xD, PrimaryUsage 4) #1 - vendor-specific #2 - single-touch (PrimaryUsagePage 1, PrimaryUsage 2) I've only been able to achieve half of my goal using a HIDDriverKit dext - I can outmatch the OS for the single-touch HID interface and ignore its 7-byte single-touch reports. However, although I can match to the multi-touch interface, I never see any reports at all there, as if the OS never polls the interrupt endpoint. On Windows, the device "just works" - I've traced its behavior in Wireshark. The OS doesn't do any special setup, it sends no SET_FEATURE commands, it just reads from the multi-touch interrupt endpoint, where it receives 54-byte reports. Windows doesn't even get any 7-byte single-touch reports. On macOS, I managed to use Wireshark on an old Intel Mac, where I can still use XHC20 for logging. Here, macOS tries to read from all the interrupt endpoints for all the HID interfaces, and the digitizer only responds on the single-touch interface. MSDN's documentation for multi-touch support is quite unhelpful here, because it just says "use the OS driver", but doesn't detail how a digitizer switches between multi-touch and single-touch mode. If I were making a digitizer, I'd send reports on both interfaces, expecting the OS to read the single- or multi-touch interface as required. Although unlikely, it seems that this digitizer changes its behavior based on how it is accessed. I can outmatch the USB interface for the single-touch reports, so that the OS HID driver doesn't even see it. That doesn't change the device behavior. The HIDDriverKit APIs I use imply setting up an interrupt read. I call Open on the interface, and implement a ReportAvailable callback. This works for the single-touch interface, but I get no reports on the multi-touch interface. All the calls with return values return kIOReturnSuccess. Does anyone know how multi-touch digitizers switch between single- and multi-touch mode (if indeed they have a mode at all), or why macOS apparently doesn't even read the multi-touch interrupt end point? Does anyone know how I can ensure that my HID driver actually reads the interrupt endpoint on the HID interface it is matched to? Does macOS deliberately prevent access to multi-touch HID interfaces?

On the Certificates, Identifiers and Profiles section of the Account section of developer.apple.com, if you manually configure the Capabilities of an App Identifier, there are icons with no tooltips. Does anyone know what they mean? (I'm particularly interested in the two different icons shown in my screenshot, with the same name)