Does it matter whether the peripheral hosts the service or the iPhone?

Judging from the non-existent response to feedback reports about EA, it doesn't look like anyone is still working on EA. Then again, the debug output has changed in iOS 17, so that would suggest otherwise… Together with the iPhone moving to USB-C connectors, the future seems pretty uncertain.

I have a similar problem. We're building hardware to interface with cars and trucks. While this works ok using wireless technologies, having a wired connection would be of tremendous help with regards to stability and speed. With the iPhone moving to a USB-C, I wonder about the future of the ExternalAccessory framework and the mfi program. What are the chances that Apple includes an FTDI driver in iOS?

This started to happen with me w/ Xcode 15. Cleaning build folders (or even derived data) does not fix it. Any other idea?

Happens, if you have DerivedData set to a non-standard location. See https://stackoverflow.com/a/74857590/415982

Please open an enhancement feedback request with Apple. The glaring omission of IOUSBHost and/or USBDriverKit is a huge gap for a lot of cool solutions w/ custom USB hardware.

Please open an enhancement feedback request with Apple. The glaring omission of IOUSBHost and/or USBDriverKit is a huge gap for a lot of cool solutions w/ custom USB hardware.

The CoreBluetooth L2CAP API refers to BLE, not classic BT. With Apple device as central, you will not get good performance, since the channel parameters (L2CAP COC SDU + MPS) and connection parameters can't be set. There's just no API for that (opened FB13742028 for that). I was able to get 36KB/sec for that scenario. With Apple device as peripheral, you should be able to get up to 100 KB/sec. I have been able to achieve that using an ESP32S3. Note that you make sure to use BLE4.2 DLE (which might not be enabled as default on your system) and a sufficiently high SDU. Apple devices seem to support up to 2048 as SDU.

I'd applaud a proper mapping table in the documentation…

6 years later, CoreBluetooth still does not provide a proper API for setting the connection parameters and the L2CAP COC parameters when being a central. I'm sorry, but I don't buy that the SDK chooses the "best" parameters for the current situation. When the Apple device is the peripheral, I can get up to 100KB/sec, when the Apple device is the central, I get up to 36KB/sec, which is sub-par.

For iOS 17, I can't seem to negotiate a connection interval below 30ms. It pretty much ignores the interval parameters of the connection update request.

FWIW, I recently managed to get a 15ms connection interval negotiated (initiated by the peripheral), so 60KB/sec is now possible with an Apple device as the central.

FWIW, I recently managed to get a 15ms connection interval negotiated (initiated by the peripheral), so 60KB/sec is now possible with an Apple device as the central.

Nothing new, I reckon? Given that we're 8 years in with that feature request, I don't hold my breath. Still I duped the radar and am crossing fingers.

As expected, it's still broken in Xcode 18 beta 1.