We're seeing a consistent issue where iPads with the A16 chip fail to connect to our BLE device, which uses a Silicon Labs chip running Gecko SDK 3.x. All other Apple devices — including older iPads and iPhones — connect without any problems.
According to Silicon Labs, the issue stems from the iPad A16 sending an LL_CHANNEL_REPORTING_IND message (opcode 0x28) during connection establishment:
Per Silicon Labs:
"Currently the iPad 16 will send a message for LL_CHANNEL_REPORTING_IND (opcode 0x28). This is a feature that is not supported in Gecko SDK 3.x.
Shortly after, the BLE module responds with an 'Unknown Response' (opcode 0x07), indicating that it does not support opcode 0x28
After this exchange the iPad stops sending meaningful transactions to the BLE module and eventually closes the connection.
The BLE Module is responding to this unknown request as specified in the BT Core Spec Volume 6 Part B."
Unfortunately, the firmware on these BLE modules cannot be updated remotely, and we've already shipped several thousand units to customers. Given how widely Silicon Labs' BLE modules are deployed, we suspect this issue could be affecting many other developers and products as well.
We’re hoping Apple might offer a workaround or allow us access — even internally or unofficially — to suppress or bypass this feature in CoreBluetooth for this specific scenario. For example, is there a way to disable LL_CHANNEL_REPORTING_IND or instruct the stack to ignore the unknown response from the peripheral?
We’re open to any workaround via CoreBluetooth (even private APIs or entitlements, if necessary) that would allow us to preserve compatibility without a mass recall. If there's an Apple engineer monitoring this, we'd be extremely grateful for guidance or escalation.
Thank you!
