Hello! I'm working on a mobile app that communicates with a peripheral via Bluetooth with security level 2 in a customised way, as there are also other communication protocols used. We use a bluetooth service with a specific UUID that has a write characteristic for sending data to the device and a notify characteristic for receiving data from the device. After connecting for the first time, a pairing prompt appears after successful connection and subscribing to notifications. When all is set, that is notifications are enabled, a handshake is performed and a communication session is established. There can be only one session for a bluetooth connection. So I have two questions: Regarding the pairing, is there any way that I can know the result of the pairing, so that I could start the handshake after it is accepted? What could be the best approach here? Asking because I noticed some instability on first connection (peripheral ignoring handshake). After disconnecting using Core Bluetooth, the system maintains the connection for some time before actually disconnecting. When opening the app shortly after killing the previous instance, it gets connected very quickly as it reuses the existing connection. The problem is, however, that the device wouldn't accept the new handshake and it is pretty much impossible to reuse previous session. In our use case we need a new BLE connection for each session. Is there any way I could forcibly disconnect from the device or enforce a new connection (not a reused one)? What might be the best approach here? The way I handle it now is by using retrieveConnectedPeripherals and if the device is found to be connected, I use scanning. If the device is advertising then we know it's not connected. Other than that we could also poll retrieveConnectedPeripherals and wait. But obviously it is not optimal, as the user has to wait longer than ususal. Other than that retrievePeripherals is used for getting the peripheral, if the app once found it during scanning. I saw this post describing similar issue, is it the only solution to implement API for disconnecting on the peripheral side?

Hello, I'm working on adding a URLSessionWebSocketTask based web socket connection to have live data in a single view. When the user navigates to it, the connection is established and live data is received. The task is being cancelled when this view disappears: task.cancel(with: .goingAway, reason: nil) After calling resume() on the task, I ping the server to see if the connection works before sending any messages. I opt to use async API instead of closure based wherever possible. Foundation provides both APIs for most URLSessionWebSocketTask's methods, but for some reason it misses async version of sendPing. Such method, however, is available in swift-corelibs-foundation project here. So I've added a similar code locally: extension URLSessionWebSocketTask { func sendPing() async throws { let _: Void = try await withCheckedThrowingContinuation { continuation in sendPing { error in if let error { continuation.resume(throwing: error) } else { continuation.resume() } } } } } The issue that I have is that if the user navigates from the view after sendPing was called, but before pong is received, pongReceiveHandler is called twice with error: Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={NSDescription=Software caused connection abort} This results in an exception: Fatal error: SWIFT TASK CONTINUATION MISUSE: sendPing() tried to resume its continuation more than once, throwing Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={NSDescription=Software caused connection abort}! There are no issues when the task is cancelled after successful ping. The documentation does not state that pongReceiveHandler is always called only once, but by looking at the code in swift-corelibs-foundation I think that it should be the case. Am I misusing sendPing, or is it a bug in the Foundation? Perhaps there is no func sendPing() async throws for some reason? I use Xcode 15.3 with Swift 5.10. Great thanks for any help. Best Regards, Michal Pastwa