Hello Argun, thank you for your response. Bluetooth chip that is on the peripheral is manufactured by Nordic Semiconductors, and is capable of multiple writes per interval, as it works on other platforms (and was working with iOS in the past, more on that bellow). By using the LE sniffer, I have verified that we get what we ask for - package length is 251 (it's using EDL), connection interval is 15ms and PHY is 2. All writes are performed without response. As our connection interval min and max times are both 15ms, iOS tries to renegotiate it to 30, but we refuse, and it settles at 15ms. Besides it working on Android and Windows, with stable throughput of 1000-1200 kbps, I found out that it used to work on iOS. The same app, that we are using now to test the throughput was working as expected, with measured throughput of 1000-1200 kbps, on an iPhone 13. As for the version of iOS I can’t know the exact version, but I know it is pre iOS 16, as the video we have has been recorded in the august of 2022. I have tested the same app on multiple devices running iOS 18, iPhone 16, 16PM, 13Mini and 14, and we were consistently getting around 400-600. I’ve also tested it on an iPhone 11 with an iOS 16.6, and got the same 400-600 range. I’ve also ran it on my MacBook, as it’s the M3 one, and again, got the same speeds. I couldn’t reproduce higher throughput with the app, as I couldn’t manage to obtain a device with iOS 15 on it. I can send you the videos if necessary, as I can’t attach them here.

 When testing for throughput, we’ve made sure that we are not connected to any other Bluetooth device, BLE or Classic, and we had wifi completely turned off, as we’ve seen it tanking the throughput on Android phones. We’ve also tried Airplane mode with Bluetooth only, but it made no difference. As of now, L2CAP channels are not something that would work for us. If in the future, we decide to go that route, if we come across any issues, I will open a new thread. Let me know if you need any additional details, and I’ll be happy to provide them. Thanks again for your help.

When connecting to our peripheral (I will use peripheral for the physical device we are connecting to and it's firmware, sorry for the previously confusing language), during negotiations the only parameters that the firmware will accept are MTU=244 and ConnectionInterval=15ms. Only thing that is negotiable is PHY, either 1 or 2, but 2 is requested by default. On the peripheral, due to vast differences in bluetooth APIs on various platforms, we have added characteristic that notifies us whenever connection parameters change. As of now, iOS hasn't succeeded (or tried) to change them. We had a similar issue on Android, where OS would change the PHY from 2 to 1, thus drastically reducing our throughput. Whenever this had happened, we were immediately notified by our peripheral. As I've said, we have not (yet) observed this on iOS. When our peripheral send data to the phone, it is always writing without response, and we rely on notifications to get and parse the bytes. When sending data from the phone to the peripheral, we are also writing without response, though these are usually a couple of bytes to configure the device and get it to start the data stream. Is it possible that the iOS changes connection parameters in a way that is one sided? From my understanding, for all changes to the connection parameters, devices need to handshake and we would be notified like we are on the other platforms? Best throughput we've observed is around 400-600 kbps, but it's quite unstable and a bit opinionated. Is it possible that the iOS is throttling the throughput without affecting the connection parameters? Also one important piece of information is that we are sending larger amounts of data than it's common for BLE devices. Is it possible that we are throttled by a number of packages it is possible to send to the iOS device during one connection interval? When sampling every 4ms, everything works great, as there are only 3-4 packages sent every connection interval. When sampling every 2 or 1ms, that's when we start to observe the problems, as it can be required to send up to 15 packages during one connection interval? I read somewhere (though on a quite old forum post) that the iOS limits the number of packages it will accept during one connection interval, and I don't know if this is still a case. Thanks a lot for the fast response, and sorry for the information-bomb!