<edit: there also seems to be a bug in this form, it's eating my spacing and punctuation> Have you had any insight on this? I too, have been struggling with this, but in my case, I would just see a silent failure (non response) from subsequent calls to connect, with the only way to recover being to power-cycle the bluetooth radio in the Settings app (not disabling in control center, but actually powering off BT in Settings). This would seem to randomly come up with normal app usage - perhaps related to disconnection when releasing CoreBluetooth resources when backgrounding, with the result being that you would get stuck in a cycle where normal connection flows: restorable CBPeripherhal instances, peripheral records retrieved via a stored UUID, baseline flow of scan + connect. These flows would all silently fail, when attempting connection, there would be no response from a connection attempt in didConnect, didFail, disconnect, etc. The only stable connection flow that we found was to only attempt connection to devices that were already reported as connected by the system. This forced the awkward flow of having to force the user to first connect in the Settings app. I know that I'm not crazy though, as I have used other BLE-only apps that forced the flow through Settings, even though there was no audio / classic function to the device.