macOS CoreBluetooth peripheral: duplicate Device Information services and iOS gamepad recognition

Question

Created 1d

Replies 1

Boosts 0

Participants 2

I’m developing a macOS app that reads a wired controller and publishes a generic BLE HID gamepad for an iPhone. BLE communication works, but iOS does not expose the device through GameController.

I’m looking for guidance on supported device-identity publication and controller-admission requirements.

Environment

Apple Silicon MacBookPro17,1: macOS 27.0, build 26A428
iPhone 15 Pro Max: iOS 27.0, build 24A437
Xcode 27
Peripheral implemented using CBPeripheralManager

What works

The iPhone can connect, perform dynamic characteristic reads, and read encryption-required characteristics using the retained pairing.

It discovers the application’s HID service and reads its Report Map, HID Information, Report Reference, and Input Report.

The descriptor in the iPhone’s system HID record matches the application’s remotely read report map byte-for-byte. The peripheral also receives an input subscription, although I cannot independently identify the subscribing consumer.

What fails

An independent GCController.controllers() observer remains empty.

During the recorded HID initialization, the iPhone logs:

Un-authenticated game controller device attached
Start failed: 0xe00002bc
IOHIDEventDriver start failed.

For the same registry device, gamecontrollerd records:

vendorID = 0
productID = 0
version = 0
manufacturer = 'Apple Inc.'
product = '[Mac device name]'
transport = 'BluetoothLowEnergy'

I am not assuming that “Un-authenticated” identifies a specific authentication requirement. I would like to understand which supported admission requirement is unmet.

Device Information observations

The iPhone’s CoreBluetooth discovery exposes two distinct Device Information service instances:

System service
- Observed UUID: 180A
- Manufacturer: Apple Inc.
- Model: MacBookPro17,1
- No PnP characteristic exposed by successful all-characteristic discovery
Application service
- Observed UUID: 0000180A-0000-1000-8000-00805F9B34FB
- Manufacturer: PS3 Bridge
- Model: BLE Gamepad Prototype
- PnP bytes: 02 00 00 01 00 00 01

The application publishes expanded Bluetooth-base UUIDs. I understand these represent the same assigned UUIDs; I am preserving the observed representations because I have not established whether every host component handles them identically.

The application PnP value represents vendor-ID source 2, vendor 0, product 1, and version 0x0100. The system HID record therefore does not simply reflect that value unchanged.

The duplicate-DIS layout also appears inconsistent with the unique primary DIS expected by HOGP. I have not established that this causes the driver rejection.

Questions

Is there a supported macOS API or architecture for publishing a coherent BLE HID device identity when macOS already exposes its own Device Information service?
How does iOS select DIS/PnP information when constructing a system HID device in this arrangement?
Is a generic BLE HID gamepad published through macOS CoreBluetooth a supported path to iOS GameController recognition? If so, what additional profile, identity, or authentication requirements apply?
What supported diagnostics would distinguish an identity-selection problem from a separate controller-admission requirement?

Available evidence

I have diagnostic source, corrected per-service-instance inventories, and redacted phone logs available.

I also have a small standalone CoreBluetooth publication reproducer. It is reduced and has not been validated as independently reproducing the full bridge’s controller rejection.

A later connection-only observation reused an existing shared Bluetooth link and still showed zero controllers. I am not treating that as a fresh HID initialization or admission attempt.

I’m seeking a supported implementation path without private APIs, Bluetooth daemon modifications, or changes to system security.

Answer 1

DTS Engineer OP

Apple

5h

I’m developing a macOS app that reads a wired controller and publishes a generic BLE HID gamepad for an iPhone. BLE communication works, but iOS does not expose the device through GameController. … An independent GCController.controllers() observer remains empty.

I'm not sure this is actually possible, at least not in a straightforward way. The problem here is that GCController works by identifying and matching against specific accessory configurations. Unfortunately, that means:

The accessory you present to the system needs to match the behavior of whatever accessory you decide to emulate.
The identification information you present to the system needs to match whichever accessory you choose to emulate in #1.

...and we haven't really documented ANY details about either. It's certainly worth filing a bug asking us to document this area, but until we do, I'm limited in how much help I can provide.

Covering a few details:

I am not assuming that “Un-authenticated” identifies a specific authentication requirement.

I believe this means that the accessory failed MFi authentication. That doesn't necessarily mean the accessory won't work (we support many non-MFi controllers), but I'm not sure how the initialization would have proceeded from here. FYI, one thing I'd personally do is collecting registry snapshots and system logs from multiple accessories we do support so you can better understand what "working" looks like.

How does iOS select DIS/PnP information when constructing a system HID device in this arrangement?

As bluetoothd discovers HID services, it creates IOHIDDevice which are then "injected" back into the kernel's HID system. I'm not sure of the full details, but if I had to guess, there's some issue with your accessory characteristics which is causing it to fall back on the underlying device.

Is there a supported macOS API or architecture for publishing a coherent BLE HID device identity when macOS already exposes its own Device Information service?

I think this will work correctly if you've properly configured your CBPeripheral with its own information service; however, I haven't looked closely enough at the full implementation to be entirely sure of that.

Is a generic BLE HID gamepad published through macOS CoreBluetooth a supported path to iOS GameController recognition?

No, not in any formal sense. If you properly replicate the controller configuration of a controller the GameController framework supports, then that controller will work; however, the details of the controller configuration and implementation aren't documented.

What supported diagnostics would distinguish an identity-selection problem from a separate controller-admission requirement?

The place I'd personally start here is by looking at the I/O Registry to see what’s actually being published, particularly when compared with a working controller. You can view that by collecting a sysdiagnose from an iOS and then looking at the file "<sysdiagnose>/ioreg/IOService.txt". However, I'd actually start by using a Mac (two Macs total) as the controller, not iOS. That gives you real-time access to the I/O Registry, greatly speeding up your testing cycle.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware