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.