iOS Background BLE: State Restoration and the Limits of Background Discovery

Background BLE should be designed as a resumable, event-driven interaction. Moving a setup screen out of view does not leave the app running a private radio loop indefinitely. Decide which operation must survive interruption, which state belongs to Core Bluetooth, and which business decision must be recovered from your own storage. That separation is more useful than a generic “background enabled” flag.

Scope: this guide addresses native iOS central-role apps communicating with a BLE peripheral. It uses current Core Bluetooth API references checked on 11 October 2026, alongside Apple’s archived background guide and explicitly versioned iOS 11 restoration Q&A. The archive explains the model, not guaranteed behavior for every current release. The test plan requires real devices on the product’s supported iOS builds; no device results are claimed here.

Distinguish the lifecycle states

Record foreground, background execution, suspension and process termination separately. A suspended app still has a process but is not executing ordinary application code. A terminated app needs a new process before its callbacks can be handled. Swiping an app away is also a user action with different restoration consequences from system memory pressure.

For central-role background work, declare bluetooth-central in UIBackgroundModes. Apple’s archived background guide describes event-driven wakeups and makes clear that a background mode does not permit unlimited execution. Keep each handler short and focused on its Bluetooth event.

Background configuration does not replace privacy authorization. Provide a meaningful NSBluetoothAlwaysUsageDescription. Apple also requires the older peripheral usage-description key when the deployment target precedes iOS 13. Treat denied access and an unavailable Bluetooth manager as explicit states rather than retrying discovery blindly.

Use discovery to find devices, not count time

The scanForPeripherals API requires explicit service UUIDs for background scanning. Agree with firmware engineers which service is actually advertised. A service existing in the GATT database is insufficient evidence that the advertisement contains its UUID.

In the archived model, duplicate discoveries are coalesced in the background, and discovery may become slower when all scanning apps are backgrounded. Consequently, do not use discovery callback frequency as a reliable heartbeat or disappearance clock. A quiet callback stream alone cannot distinguish an absent peripheral from altered scan delivery.

Define a freshness policy instead. Display the age of the last application-level observation, and distinguish “not recently observed” from “confirmed disconnected.” If a product needs periodic data, evaluate a connection and characteristic subscription against its power budget. That is an architectural choice to test, not a promise of continuous execution or a deadline guarantee.

Give restoration a stable identity

Opt in when constructing the central manager using CBCentralManagerOptionRestoreIdentifierKey. The identifier reference requires the value to remain the same across app executions. Generating a fresh UUID on every launch defeats that identity. Choose a stable identifier for each logical manager and keep ownership outside a screen’s lifetime.

The current reference adds an important scene-based-app detail: do not depend on launchOptions to supply Bluetooth central identifiers when using UISceneDelegate. Persist or deterministically recover the identifiers and supply them when rebuilding managers. A startup architecture tied only to a visible view can miss the recovery path even if foreground connection works perfectly.

Reconcile restored objects before issuing new work

Implement centralManager(_:willRestoreState:) and inspect the supplied dictionary. The current API description warns that preserved parameters can be missing. Retain restored peripherals, assign their delegates, and inspect connection and discovery state before requesting missing services or characteristics. Avoid an unconditional startup sequence that disconnects restored devices and starts everything again.

Maintain a separate durable journal containing the user’s desired session, logical device association, operation identifier, last acknowledged step and cancellation state. This is an application design recommendation, not data Apple promises to preserve. Suppose an accessory received a configuration write just before the app stopped. A restored connection does not reveal whether the accessory committed that configuration. Query device status or use an idempotent transaction protocol before replaying a command.

Serialize ordinary launch and restoration handling through one coordinator. Otherwise, a normal startup scan and a restoration callback may create competing work for the same device. Handle an empty restoration dictionary as a recoverable starting point, and honor a user cancellation recorded before termination.

State the cases where relaunch is not guaranteed

Apple QA1962, dated September 2017 and scoped to iOS 11, describes restoration for pending Bluetooth work when the relevant event occurs. It distinguishes system removal from user force-quit, which does not trigger automatic relaunch under that documented model. Its reboot case also depends on first unlock when a passcode is configured. Treat these as separately tested lifecycle cases, not a universal current-version service-level agreement.

A short foreground success does not validate recovery after hours out of range. Set product expectations around eventual reconciliation and visible stale-state indicators. Where a missed event has important consequences, the accessory should preserve relevant state for later retrieval rather than relying on an uninterrupted phone callback stream.

Proposed real-device acceptance checklist

1. Record iPhone model, exact iOS build, app build, authorization and background declarations. Use release-like runs without an attached debugger.
2. Verify the advertised service filter in the foreground, then repeat after switching apps and locking the screen. Capture lifecycle transitions and callback timestamps.
3. Test an established subscription separately from discovery and a pending reconnection. Record which operation was pending before interruption.
4. Exercise system termination using a documented QA method; label the method. Test user force-quit separately and never substitute it for memory-pressure termination.
5. Restore during incomplete service discovery and after an unacknowledged command. Confirm delegates, missing discovery steps and transaction reconciliation recover without duplicate effects.
6. Test Bluetooth changes, reboot and first unlock as distinct cases. Confirm the UI explains stale data and offers a user-driven recovery route.

Pass only when the app can explain what it knows after each interruption: restored transport, confirmed device state, outstanding intent and remaining uncertainty. Background support is credible when this recovery path is demonstrable, not when a capability checkbox is enabled.