Maybe the "Database Hash" and "Service Changed" characteristics can prevent this data from being cached by the OS

Only the main queue is guarenteed to run on a specific thread (and therefore a specific runloop). You need to create an NSThread, start it and use its runloop.

I think that the CBCharacteristic object is no longer valid after the disconnection. Check what is value after step 4. I believe that the value would still be isNotifying == YES.

The picker views only unpaired MFi devices.The EAAcessory framework does not provide an API to connect to a device.The MFi device can initiate connection to the iPhone - so if your device can supports GATT you can use CoreBluetooth to connect to the device and ask it to connect over iAP.Another options is the "bridging" feature mentioned in the last WWDC session about CoreBluetooth - with this feature the iPhone connects to the classic bluetooth device when it discover this device over BLE.

Try State Preservation and Restorationhttps://developer.apple.com/library/archive/qa/qa1962/_index.html

You can add your own UUID in the "manufacturer data"

The relevant frameworks are:ExternalAccessory for MFI accessorties.CoreBluetooth for BLE devices and for BR/EDR devices that supports GATT.Check if the HID bluetooth profile can fit your need. In that case. If I am not mistaken you will not need to use any framework

You can even use multiple CBCentralManager instaces in order to communicate with the same peripheral

What OS and device do you use? Multiple CBCentralManagers works for me on iOS, watchOS and macOS.

Adding the bluetooth-central UIBackgroundMode solved this issue for us in debug mode. The problem is that we fail to upload the app since there because of missing com.apple.developer.bluetooth-central-background entitlement. The problem is that we didn't find a way to add this entitlement in the portal or in Xcode. I opened a DTS and waiting for a reply.