We need one iOS app supporting iOS 17 and later to set up a BLE HID accessory entirely from within the app. The accessory also advertises a custom GATT service. Our iOS 18.4+ flow uses AccessorySetupKit with bluetoothHID and should remain unchanged. We need a supported public setup path for iOS 18.0–18.3, including new installations without an existing Bluetooth grant or working HID bond. Requiring pairing in Settings or a firmware change would not meet this requirement.
The specific question is: what public API/configuration can establish system HID input on those older systems while the same installed app retains its AccessorySetupKit Bluetooth declarations?
What we have verified on an iPhone 15 Pro Max running iOS 18.3.1 (22D72):
-
With AccessorySetupKit Bluetooth support declared in Info.plist and no authorized accessory, our ordinary CBCentralManager stayed poweredOff. In a controlled diagnostic build with the same diagnostic app identity and code but the two ASK support declarations removed, it became poweredOn, discovered the accessory, connected, and reached custom GATT communication. This test did NOT establish first-time HID input success for the non-ASK variant.
-
With ASK enabled, we describe the accessory using its custom advertised service, set descriptor.supportedOptions to bluetoothPairingLE, and use a display item with confirmAuthorization. During app authorization we perform the accessory security setup and then finishAuthorization. Device logs show successful pairing, encryption, saved keys, and an authorized/paired accessory. Custom GATT communication works. Actual HID input still does not work: the system receives an HID-service value but discards it because the parent characteristic has not been discovered and there is no subscribing session.
-
Pairing the same hardware through Settings previously produced working mouse/gesture input. We did not retain a simultaneous system trace of that successful path. This confirms the hardware/system combination can provide HID input, but does not establish an app-initiated solution.
We understand that Apple's ASAccessorySession documentation introduces ASK BLE HID setup in iOS 18.4 and requires bluetoothHID plus a custom advertising service. We are not treating successful bonding or ordinary GATT communication as proof of system HID readiness.
Could Apple clarify which supported approach applies?
- Can one installed app select ordinary global Bluetooth authorization on iOS 18.0–18.3 while retaining ASK Bluetooth declarations and ASK setup on iOS 18.4+? We have not found a documented per-OS Info.plist selector or runtime opt-out, and an availability check around ASAccessorySession alone leaves the installed declarations intact.
- If that authorization split is not supported, is there a public app-initiated way to establish system HID discovery/subscription after ASK authorization and bonding succeed on iOS 18.0–18.3?
- Does using service 1812 as the ASK discovery match have any documented HID setup effect on 18.0–18.3, or is it only an advertising filter? We have not tested that variant and are not assuming it activates a profile.
We are specifically trying to cover new users. Preserved authorization from an older non-ASK app version, an existing working bond, or authorization from a companion Watch app would not cover that case. We would appreciate an exact public API/configuration or clarification of the supported boundary before changing our production flow.
References:
https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession
https://developer.apple.com/videos/play/wwdc2024/10203/
https://developer.apple.com/documentation/bundleresources/information-property-list/nsaccessorysetupkitsupports
No full device logs, device identifiers, proprietary source, or user data are attached.