Using BLE ANCS to connect a peripheral (similar to a smart watch product) to an iPhone, we are having an issue where the peripheral and the iPhone disconnect their BLE clients. It seems to occur when the number of notifications that the iPhone attempts to send to the peripheral is too large.
We have tried to have the peripheral only listen to the metadata (and not even store the notification data), but we still had disconnects and cannot determine why. It happens on some iPhones but not all.
Methods exist in CoreBluetooth that allow you to check the maximum write size, both with and without a response from the peripheral:
func maximumWriteValueLength(for type: CBCharacteristicWriteType ) -> Int.
There is also a CBPeripheral function that allows you to check if a peripheral is ready to receive a write (without response): var canSendWriteWithoutResponse: Bool { get }, and a CBPeripheralDelegate function that is triggered when a CBPeripheral is able to receive another write without a response: optional func peripheralIsReady(toSendWriteWithoutResponse peripheral: CBPeripheral ).
If you buffer the data you plan to send, and only send the maximum packet size allowed per write (checking if the peripheral is ready to receive another write before hand), this may help solve your disconnection issue. You will want to call your write function when a peripheral is ready to receive another write (CBPeripheralDelegate method above is triggered), to empty any potentially remaining data in your buffer.
Let me know if this helps.
Thanks for the response! However, I don't think this really applies for ANCS. In this case, our app has nothing to do with ANCS and once the peripheral device is subscribed to notifications, it seems like the timing, packet size, etc. is entirely determined by iOS. We do not (and I believe cannot) control how the iPhone sends notifications - it's all built into apple's ANCS framework.
