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

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?