iOS Bluetooth background limits: what hardware teams must design for
Why devices disconnect when the app sleeps, and the patterns that keep them connected.
Karan · Founder & CTO, NavikX
· 7 MIN READ
iOS suspends apps in the background, so a BLE device stays connected only if the app uses the right background mode, keeps scans narrow and lets iOS reconnect for it. Design for this from day one.
Why devices disconnect when the app sleeps
When a user locks the phone, iOS suspends your app within seconds. Unless the app declares the bluetooth-central background mode and has an active connection or a pending connect request, it stops receiving data and the device looks 'offline'.
Android is more permissive but has its own traps: battery optimisation, location permission rules for scanning and manufacturer-specific power savers.
Patterns that keep devices connected
- Declare bluetooth-central background mode and only use it for real device communication.
- Issue a pending connect() to known devices; iOS will reconnect when they come back in range, even if the app is suspended.
- Scan for your specific service UUID only. Background scans without a UUID filter return nothing.
- Use state restoration so iOS can relaunch your app to handle a device event.
- Keep payloads small and send summaries, not raw streams, when the app is in the background.
What the firmware team should know
Advertising interval, connection interval and MTU size all affect battery and reliability on phones. Agree them with the app team early; changing them after launch means a firmware update on every device.
FAQ
Can an iOS app keep a BLE connection forever?
Not guaranteed. iOS can terminate the app under memory pressure. State restoration and pending connects make recovery automatic, which is what users experience as 'always connected'.
Does Flutter handle background BLE?
Yes, with the right plugin and native configuration. Some background work still needs small native code on each platform.
Karan Kumar Maurya · Founder & CTO, NavikX
LinkedIn