Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

iOS 26 Bluetooth disconnect issues

I have discovered a serious issue with Bluetooth connectivity on iOS 26.

My device use nrf52832 and sdk15.3, it consistently disconnects just a few seconds after a successful connection, then automatically reconnects in a continuous loop.

By using a Bluetooth packet sniffer and printing Bluetooth event logs, I found that iOS 26 sends a command to update connection parameters

" Control Opcode: LL_CONNECTION_UPDATE_IND" to Bluetooth slave devices (especially HID devices) every 120ms.

Moreover, the connection parameters it requests are also quite extreme.

The Bluetooth stack of the slave device cannot handle such a high frequency of update requests, ultimately leading to disconnection. Bluetooth stack shows a disconnection error code of 0x28, which corresponds to "Instant Passed."

I will attach my packet sniffer log images. I even suspect this is a very simple and stupid bug—the apple programmer mistakenly placed the Bluetooth parameter update procedure in the Bluetooth central callback event, causing a dead loop. The correct approach should be to request updates by a timer.

Our users are urging me to update the firmware to be compatible with iOS 26 every day. However, after trying some methods, I found that the problem could not be solved at all. Apple support also did not reply to my messages. Now I have no idea how to deal with this problem. Maybe someone in the community has encountered the same problem and solved it?

Parents Reply Children
  • Hello Edvin,

    Good news — I’ve reproduced the issue. In the SDK 15.3 BLE HID Keyboard example, after manually adding the MIDI service functions, the problem appears. The exact path is:
    nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral\ble_app_hids_keyboard

    I will upload a zipped archive of my project. Just extract it and copy it into the SDK at the specified path to overwrite the source files, then it will run. The setup uses the  nRF52832 DK, PCA10040 and the S132 stack with Keil 5. The S132 stack version is 6.1.1.

    I hope you can successfully reproduce the issue and report it to Apple. As an individual developer, my own feedback has very limited impact. In the music industry, the Bluetooth MIDI service is very common and heavily used, so many people will be affected.

    Best regards,

    Harryble_app_hids_keyboard.rar

  • Also, I tset the latest s132_nrf52_7.2.0_softdevice, the issue still persists.
    In the logs, you can see a large number of BLE_GAP_EVT_CONN_PARAM_UPDATE events.

    When NRF_SDH_BLE_GAP_EVENT_LENGTH is set too high, error 0x28 occurs easily and the connection drops. Only when using NRF_SDH_BLE_GAP_DATA_LENGTH of 27 and setting a very small NRF_SDH_BLE_GAP_EVENT_LENGTH does the connection become less likely to disconnect.

  • Hello Edvin,

    May I ask if there’s any update? Have you been able to successfully reproduce the issue?

    Best regards,

    Harry

  • Hello,

    Sorry for the late reply. I have been out of office for a couple of days.

    I do not see the disconnect issue that you are seeing. 

    Is there a specific phone model that you are seeing this on? What OS version are you currently using? 26.0.1?

    HarryGe said:
    error 0x28 occurs easily

    What function returns 0x28? Where do you see this error?

    Best regards,

    Edvin

  • Hello, please run the program I uploaded and then open the RTT logs. Connect to the Nordic Keyboard in the iPhone's system Bluetooth interface. At this point, a large number of connection parameter update events will appear in the logs. During my testing, I found that on older iPhones running iOS 26 (I used an iPhone 11), the connection parameter update events occur approximately every 120ms, which quickly leads to a 0x28 error and then disconnection. However, when tested on the iPhone 17, this frequency is about once per second, so disconnection is less likely to occur (I specifically bought an iPhone 17 for this test, *** you apple). Nevertheless, the logs still exist. You can use a packet sniffer to verify the situation I described.

Related