Turns out the issue was that characteristics on the peripheral side were not configured to require encryption. They were set with "READ", "NOTIFY" and "WRITE_WITHOUT_RESPONSE" flags, which indicate that no pairing is required to use them. To ensure that first time connection works fine between peripheral and iOS and that pairing is successful before reading from or writing to Bluetooth characteristics, ensure that they are set to require encryption: "ENCRYPT-READ", "ENCRYPT-NOTIFY" or "ENCRYPT-WRITE" (might be with a response). This is the only way that makes iOS wait for pairing before using characteristics. After read or write from characteristics that requires encryption, Core Bluetooth waits for pairing completion before it calls its delegate methods. If pairing is cancelled, the connection is terminated. If timeout is reached (the user does not take any action on the prompt), you should receive an error: Error Domain=CBATTErrorDomain Code=15 "Encryption is insufficient." UserInfo={NSLocalizedDescription=Encryption is insufficient.}

No, it is closed and rerun between steps 4 and 5. So it occurs also after reinitializing CBCentralManager. Worth mentioning that restarting the peripheral fixes it because BlueZ stores keys in a volatile memory, so during reboot they are removed (which should not be the case). If this is fixed, pairing is broken permanently. Sure, I will create a bug report so it can be investigated further.

@Engineer Looks like the app is able to read data from characteristic without any action performed. After connecting it discovers the service, then it discovers characteristics. Two characteristics are found: one supports reading & notifying, the other is for writing. After discovering the "read" characteristic readValue is called and I do get data from it. In the meantime, the pairing prompt is shown and no action is needed before receiving data. Enabling notifications also work without any pairing. Sometimes it gets stuck at discovering services. discoverServices is called on the peripheral and I don't get any response. I don't have this issue when devices are paired. At this point I am unable to know the pairing status and I can't make the connection mechanism stable until getting paired. Is there anything else we can do or are we blocked? Are there any timing issues I should take care of? After hitting pair I am able to communicate with the peripheral shortly before it disconnects from the iOS device. During the next connection pairing prompt pops up again and the peripheral is not listed in "MY DEVICES" in Bluetooth settings, as if the pairing failed, but it worked for a while. Is it something that might be on the peripheral's side? When pairing in System Settings, all goes fine. But this is not a good UX to ask the user to do it manually there, especially that we use custom naming that changes each day...

Thank you for quick and valuable response Argun! By longer wait I meant by simply waiting for the system to disconnect from the device so that the app can make a new connection (not reused). We can do it either by scanning (the device advertises when no longer connected) or polling retrieveConnectedPeripherals to check if the device is still on the list - if not, then we can connect again. Could you share what is the time between calling disconnect on a peripheral and dropping the connection by the system, if no other app is using the connection? If it's varying, what does it depend on? Does disabling notifications for a read characteristic impact this time? Does it make a difference if the app disconnects on entering background mode? Is it the same as if the app is terminated by swiping upwards?

Thank you for your quick response! I wasn't aware of this technote before I choosed URLSessionWebSocketTask. I have now changed Web Socket implementation to use the NWConnection and looks good so far :). However, NWProtocolWebSocket.Metadata's pong handler seems to have exactly the same issue, so this is where it came from. In a situation when the connection is being cancelled right after "ping" is sent, handler is called twice with POSIXErrorCode(rawValue: 53): Software caused connection abort error. This is fairly easy to overcome, but still it complicates things a little as it has to be assumed that the handler can be called more than once, especially when using withCheckedThrowingContinuation. BR, Michal Pastwa