iOS 26 Bluetooth disconnect issues

[HarryGe]

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?

[Edvin]

Hello,

Can you please upload the application you used in this sniffer trace? Will I be able to reproduce the issue if I build your application, flash it to an nRF52832 DK, and connect to it using an iPhone running iOS26 and nRF Connect for iOS?

Best regards,

Edvin

[HarryGe]

Please wait a moment, I will try to make a DEMO version for you. Some people in the community also have the same problem: devzone.nordicsemi.com/.../repeated-connection-interval-updates-on-ios-26

[Edvin]

Yes. And if this is in fact a bug in iOS. there is not much we can do about it. But I guess the first step is to reproduce the issue, and start investigating.

Best regards,

Edvin

[HarryGe]

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

[HarryGe]

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.

[HarryGe]

Hello Edvin,

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

Best regards,

Harry

[Edvin]

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

[HarryGe]

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.

[Edvin]

I understand. I tested with an iPhone 13, and I saw the frequent updates, but no disconnection. I did however, not see the same packet loss as I saw in your sniffer trace (iOS26.pcapng):

Where the peripheral only replies to evey 5-6 packets. There is no connection latency, so it shouldn't behave like this. However, I was not able to reproduce this behavior. I suspect that this is the reason for your disconnect.

Were you able to see this behavior on a DK as well with the application you uploaded? I am not talking about the frequent LL_CONNECTION_UPDATE_IND, but the lack of replies. Ideally, every second packet should be from the peripheral to the central. 

The fact that the mobile sends LL_CONNECTION_UPDATE_IND very frequently indicates that it is a bug in the iOS, but it is not strictly illegal. My guess is that the iOS has one preferred set of connection parameters for a HID keyboard, and another set for a MIDI over HID connection, and hence, it starts jumping between the two. 

You should report this to Apple, and attach your sniffer trace. 

Best regards,

Edvin

[HarryGe]

Yes, that's exactly the issue. Please disregard my sniffer file for now. Ever since I updated Python, my sniffer software often displays this duplicate packet problem. It only shows correctly if I keep closing and reopening the software, and I haven't fixed this issue yet. I might have uploaded an incorrect sniffer file - in reality, the device's Bluetooth operates without problems.

Moreover, our keyboard demo program runs with default settings: MTU 23, data length 27, and a very small gap event length. However, when I apply the configuration from my current project (MTU 247, data length 251, gap event length 10), it easily triggers the 0x28 error. You can try reproducing this with these settings.I think the larger gap event length results in insufficient time for the Bluetooth stack to update the connect parameter.

Additionally, I have already submitted a bug report to Apple but haven't received any response. It would be greatly appreciated if Nordic official could also file a bug report with them, as that might draw more attention to this issue. Thank you for your support.

[Edvin]

I understand. I have reported it internally, and we will send something over. 

Thank you for reporting this!

Best regards,

Edvin

[HarryGe]

Thanks a lot for looking into this so quickly and for reporting it internally. I really appreciate your willingness to reproduce the issue and escalate it. This problem affects many BLE MIDI/HID use cases in our industry, so your help is invaluable.