iOS BLE Connection Timeout Policy: Per-Peripheral or Per-App Radio Session?

Question

Created Oct ’25

Replies 1

Boosts 0

Participants 2

Hi Core Bluetooth team,

I’m seeking official clarification on iOS system-level BLE connection management policy, specifically regarding idle timeouts.

Question:

When iOS disconnects a BLE peripheral with the error: "The connection has timed out unexpectedly."

Is this timeout enforced:

Per peripheral (each connection has its own idle timer), or
Per app / per Bluetooth radio session (one idle timer for all BLE connections in the app)?

In other words:

Does a single GATT operation (e.g., a write or notification) on any one peripheral reset the idle timeout for all other BLE connections in the same app?

Context (General, No App Code):

This is about system behavior, not a bug in any specific app.
Applies to foreground and bluetooth-central background mode.
No state restoration involved.
iOS 17–18, all modern devices.

Why This Matters:

If per-app, one keep-alive can protect multiple peripherals → simplifies design.
If per-peripheral, each connection needs independent activity → higher power use.

Reference:

Core Bluetooth docs recommend “regular GATT operations” but don’t specify scope.
WWDC sessions mention “shared Bluetooth radio” but not timeout granularity.

Official Answer Requested:

Is the BLE idle timeout per peripheral or per app/radio session in iOS?

Thank you for the authoritative guidance.

Boost

Answer 1

robert_mm OP

3w

I'm no BLE expert, but I've recently been dealing with the "The connection has timed out unexpectedly" issue you mentioned. I found that even if the app issued a GATT command every 30 seconds I still would get unexpected timeouts. It was only by adjusting the BLE connection parameters on our device to comply with the recommendations from Apple (see link below) that we were able to eliminate the intermittent disconnects.

https://developer.apple.com/library/archive/qa/qa1931/_index.html

0