Which virtual-HID entitlement path for a gamepad app — CoreHID or DriverKit? (Request H8Q3K9CK7Z stuck 2.5 months)

Question

Created 1w

Replies 1

Boosts 0

Participants 2

I'm building a macOS app that creates a virtual gamepad (Xbox-style HID device) so games can see input coming from a companion mobile app — similar in spirit to Karabiner-DriverKit-VirtualHIDDevice, but for a gamepad rather than keyboard/mouse.

I submitted a Capability Request for "HID Virtual Device" (com.apple.developer.hid.virtual.device) under Capability Requests in Certificates, Identifiers & Profiles:

Request ID: H8Q3K9CK7Z Submitted: June 30, 2026 Status: still shows "Submitted" with no change, ~2.5 months later

Two questions I'd appreciate guidance on:

Is this request queue still actively processed? I haven't received any request for more information, and there's been no status change since submission. Is 2.5 months a normal wait right now, or should I be following up through a different channel? Is the app-level CoreHID entitlement (com.apple.developer.hid.virtual.device) actually sufficient for a gamepad to be detected by GameController.framework (i.e. GCController.controllers()), or does that require wrapping the virtual device in a DriverKit driver extension instead, similar to how Karabiner ships com.apple.developer.driverkit + .transport.hid + .family.hid.device + .family.hid.eventservice alongside this same CoreHID key, rather than relying on the CoreHID entitlement standalone?

Any clarity on the right entitlement combination, and on whether I should expect movement on H8Q3K9CK7Z, would be a big help.

Answer 1

DTS Engineer OP

Apple

1w

Is this request queue still actively processed?

It is, but some requests are taking a while at the moment.

Any clarity on the right entitlement combination?

So, I actually wrote the "HID Entitlement Configuration Guide" to specifically answer this question. I'll specifically note that several 3rd party products are built with entitlement configurations they don't actually need, so you shouldn't assume that a product actually "needs" all the entitlements it's signed with.

I'd recommend reviewing the entire document, but commenting on a specific point:

Is the app-level CoreHID entitlement (com.apple.developer.hid.virtual.device) actually sufficient for a gamepad to be detected by GameController.framework (i.e. GCController.controllers())?

I think so. More specifically, there are actually two different parts to this question:

(1) Is there any difference between using CoreHID's virtual accessory support and creating a DEXT?

Absolutely. DEXTs are much harder to write and debug.

However, if you're asking about technical benefits, then the answer is no, not really? There are technical differences in the details (for example, how they're enabled), but architecturally they both work in EXACTLY the same way. CoreHID is just using a kernel extension we wrote instead of the DEXT you'd have to write.

(2) Will GameController framework recognize my controller?

This is the only point that’s a little uncertain. GameController.framework matches against specific (undocumented) hardware details, which you'd then have to match. That's not an issue for the DEXT because, by definition, you have full control of everything the framework can see. I think CoreHID will work fine, but it's possible there's some detail I've overlooked that would interfere with GameController matching.

or does that require wrapping the virtual device in a DriverKit driver extension instead, similar to how Karabiner ships com.apple.developer.driverkit + .transport.hid + .family.hid.device + .family.hid.eventservice alongside this same CoreHID key, rather than relying on the CoreHID entitlement standalone?

Quoting myself:

"...note that several 3rd party products are built with entitlement configurations they don't actually need..."

and:

"com.apple.developer.hid.virtual.device -> This entitlement controls access to the CoreHID virtual device API. This is NOT a DEXT entitlement and should never be included in a DEXT."

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware