Unable to physically disconnect from the peripheral at the application level

Question

Created Aug ’25

Replies 3

Boosts 0

Participants 2

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?

Boost

Answer 1

Engineer OP

Apple

Aug ’25

Accepted Answer

There really isn't an API to force a disconnection from the application level, as the CoreBluetooth API is quite abstracted from the controller level, so the the solution suggested in the other post (sending a command to the accessory for it to close the connection) is all I have in my box of tricks (as it was also I, who suggested that in the other post).

The retrieveConnectedPeripherals trick could work, but I believe it will suffer from the lag between the framework and the HCI, which is what I think you were referring to about the longer wait.

As for detecting the result of the pairing request, there also isn't a way to detect how that went. But you would know if the pairing was completed if you tried to read from a encrypted characteristic and was successful.

If you tried to access the encrypted characteristic right after connection, if the device are not paired, that will trigger the pairing procedure. If the pairing is successful, you will be able to access the characteristic. Otherwise, it will fail.

And that tells you the result of the pairing.

Argun Tekant /  DTS Engineer / Core Technologies

1

Answer 2

michalpastwa OP

Sep ’25

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?

0

Answer 3

michalpastwa OP

12h

@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...

0