We had this same problem and reported it as a bug in iOS 6. Apparently it’s the intended behaviour according to the response I received (still not sure why).
To work around this, we made it so when we want to disconnect on the iOS side, we unsubscribe from notifications on the service characteristics. When the peripheral sees the unsubscribe requests we close the connection from the peripheral side which does
completely close the connection. This has cleaned up a lot of the issues we were seeing.
Cheers,
--Mike
From: bluetooth-dev-bounces+michael.mallinson=email@hidden [mailto:bluetooth-dev-bounces+michael.mallinson=email@hidden]
On Behalf Of Anders Grunnet-Jepsen
Sent: Monday, September 24, 2012 7:45 PM
To: email@hidden
Subject: iOS6 not disconnecting for 30-60seconds after cancelPeripheralConnection
I am seeing some very strange behavior on iOS6 (and Xcode 4.5) that pertains to opening and closing connections to the Peripheral.
When I issue the cancelPeripheralConnection, I receive a callback immediately to the didDisconnectPeripheral (as expected), but the iPhone does not cancel the RF connection for 30-60seconds.
If anyone or anything (including the same app, a different app, or another user on another iPhone) tries to scan for the Peripheral during this dead period of time, the Peripheral is not available.
In iOS5.1 when you issued a cancelPeripheralConnection, the connection would close immediately and the Peripheral would now be free to communicate to any other iPhone or app.
1. User 1 connects to Peripheral, issues some commands, and cancels the connection.
2. User 2 now wants to connect, but he cannot. Not until the 30-60 seconds have gone by.
To test this further, if after I issue a cancelPeripheralConnection I physically reset the power of the Peripheral, then the Peripheral does become available immediately upon power-up.
So my question is: What is the new recommended way to quickly set up and tear down a Bluetooth LE connection in iOS6?