I have a watchOS app communicating with a BLE peripheral during an active HKWorkoutSession.
The workout provides sufficient runtime: once connected, the Watch can receive a notifying GATT characteristic approximately once per minute for hours, including while the display is off. In normal conditions the connection is very stable.
The difficult case is outdoor use with marginal RF conditions. The peripheral and application protocol otherwise work reliably, but outdoors there are fewer reflected RF paths and normal body movement can intermittently obstruct the Watch-to-peripheral path. In those situations the link occasionally terminates with CBError.connectionTimeout.
Reconnection is particularly important because this peripheral advertises for reconnection only approximately once per minute. We also know approximately which second of each minute the peripheral becomes active, so missing a single advertising opportunity can cause a relatively long data gap.
I’m trying to better understand the supported CoreBluetooth/watchOS behavior in this situation.
- Maintaining a marginal existing connection
Once the BLE connection is established, are there any public CoreBluetooth mechanisms or recommended practices for making that connection more robust against CBError.connectionTimeout?
In particular, can application-level GATT activity have any influence on connection scheduling or link robustness, or is this entirely handled by the Bluetooth stack below CoreBluetooth?
CBConnectPeripheralOptionEnableAutoReconnectwith sparse advertising
When CBConnectPeripheralOptionEnableAutoReconnect is enabled and the connection is lost, how does watchOS handle a peripheral that advertises only very infrequently?
Does CoreBluetooth simply keep the reconnect pending and wait for subsequent advertisements indefinitely, subject to system policy?
- Known peripheral activity timing
If the app knows approximately when the peripheral becomes active and advertises each minute, is there any supported way to make use of that timing during reconnection?
Or should the app simply leave AutoReconnect pending and let CoreBluetooth handle reception?
- WWDC22 reduced reconnection range
WWDC22 session 10135 says:
“If your device is on the edge of Bluetooth range and repeatedly disconnects while in Background BLE connection, the reconnection range will be reduced. This means only devices close to the Apple Watch will reconnect.”
The session also says these limits are counted over a rolling 24-hour window and are reset when the user interacts with the app.
I would particularly appreciate clarification of how this works in practice:
- What conditions cause a disconnect to count toward this policy?
- Does this policy apply while an app has an active
HKWorkoutSessionand continues executing in the background? - Is the state maintained per peripheral, per app, or more globally?
- What exactly constitutes the user interaction that resets it?
- Does bringing an already-running workout app back to the foreground reset it, or does the app need to be relaunched?
- Is there any public API or diagnostic indication that reduced reconnection range is currently active?
- Is there any supported way to explicitly clear/reset that state?
- Connection parameters
Does watchOS expose any supported mechanism for a CoreBluetooth central to influence parameters relevant to connection robustness, such as connection interval, supervision timeout, PHY, transmit power, or similar link parameters?
- Diagnosing
CBError.connectionTimeout
When CoreBluetooth reports CBError.connectionTimeout, is there any supported diagnostic method to determine whether the Watch stopped receiving the peripheral, the peripheral stopped receiving the Watch, or whether this should simply be treated as a link-layer timeout without attribution to either side?
For context, this is not primarily a background-runtime problem. The active workout keeps the app running and the normal persistent BLE connection can operate flawlessly for many hours. I’m specifically trying to understand the best supported strategy for preserving and recovering the BLE link when RF conditions temporarily become marginal, especially with a peripheral that advertises very sparsely after a disconnect.
DTS asked me to post this question here for review.