AppMatic Tech builds BLE companion apps in Swift, Kotlin, and Flutter that keep sensor data syncing while the app is in the background, using iOS state restoration, Android foreground services, store-then-sync storage, and idempotent uploads to Laravel and Node.js back ends. The Ahmedabad, India team has shipped six BLE device integrations.
A wearable that works on a developer's desk and loses data in a user's pocket is almost always a background-behaviour problem, not a Bluetooth problem. The radio works; the operating system has stopped the app.
Key takeaways
| Point | Detail |
|---|---|
| iOS needs opt-in | Background mode plus a restore identifier, or the app is not relaunched. |
| Android needs a visible service | A foreground service with a notification, plus handling of battery optimisation. |
| Disconnection is normal | Reconnect logic is part of the design, not an error path. |
| Store before sending | The phone writes each reading to local storage first. |
| The device buffers too | Timestamped records on the wearable cover gaps longer than the app can survive. |
Why do readings go missing in the background?
Mobile operating systems prioritise battery life, so any app that is not in the foreground is a candidate for suspension. A wearable app is a worst case: it must stay reachable for a device that sends data at times the user does not control.
| Symptom reported by users | Typical root cause |
|---|---|
| Data missing overnight | App suspended or killed, no restoration or foreground service |
| Gap after phone restart | App not relaunched, connection never re-established |
| Duplicate readings after reconnect | Sync resumed from the wrong point, uploads not idempotent |
| Sync works on Pixel, fails on another Android brand | Vendor battery optimisation kills the service |
How does background BLE work on iOS?
iOS supports background Bluetooth with three pieces that must all be in place.
- The Bluetooth central background mode is declared in the app's capabilities, so the system delivers BLE events while the app is suspended.
- A restore identifier is passed when creating the central manager. If iOS terminates the app, it can relaunch it in the background when a connected peripheral sends data, and hand back the manager and peripherals through the restoration callback.
- Connection requests that outlive the app. Calling connect on a known peripheral creates a request that stays pending, and the system completes it when the device is in range, even with the app not running.
Background scanning also has limits: it requires specifying service UUIDs, and advertisement data is reduced, so apps should connect by saved peripheral identifier rather than rely on scanning.
AppMatic Tech rebuilds the whole connection state machine in the restoration callback and treats a restored launch as the normal path, not a rare one.
How does background BLE work on Android?
Android is less uniform. Behaviour depends on the OS version and the device maker.
- Foreground service. A long-running connection lives in a foreground service with an ongoing notification. Recent Android versions require declaring a foreground service type, and the connected device type fits BLE accessories.
- Runtime permissions. From Android 12, scanning and connecting use the Nearby devices permissions, and the app must handle denial gracefully.
- Companion Device Manager. Pairing through the Companion Device Manager lets the system associate the device with the app, which improves reconnection and reduces the permissions needed for scanning.
- Battery optimisation. Doze and vendor task killers can still stop a service, so the app detects exemption status and guides the user to settings when needed.
On both platforms, subscribing to notifications is cheaper than polling, because the device wakes the app only when there is new data.
How should data be stored and synced?
The rule used on every AppMatic Tech device build is store before sending.
- Each reading received over BLE is written to local storage on the phone with the device's timestamp and a sequence number.
- A sync worker uploads in batches, and the back end acknowledges the highest sequence it has stored.
- Uploads are idempotent, keyed by device, timestamp, and sequence, so retries cannot duplicate data.
- The app asks the wearable for records after the last acknowledged sequence, so gaps are refilled from the device's own buffer.
Wearables with small memory overwrite old records, so firmware buffer size defines the maximum tolerable gap, and that number belongs in the product requirements. The back-end side, including firmware delivery and telemetry at scale, is covered in scaling an IoT platform.
Which failure modes appear in production?
| Failure | Cause | Mitigation |
|---|---|---|
| GATT error 133 on Android | Concurrent GATT operations, stale cache, immediate reconnect | Queue operations, wait for acknowledgement, delay retries |
| Silent drop after hours | Connection supervision timeout or OS suspension | Heartbeat characteristic, reconnect with backoff |
| Truncated payloads | Default MTU too small for the data | Negotiate a larger MTU and chunk with sequence numbers |
| Wrong clock on records | Device clock drift | Sync device time on connect and store both clocks |
| Pairing lost after update | Firmware or OS change invalidated bonding | Detect and prompt for a clean re-pair |
These and the cost impact of each are broken down in BLE mobile app development: cost and timeline, and protocol selection is covered in BLE vs Wi-Fi vs MQTT.
How is background behaviour tested?
Foreground demos hide these defects, so AppMatic Tech tests the lifecycle explicitly:
- Lock the phone and leave the device running overnight, then compare device records with stored records.
- Force-quit the app and confirm restoration or service restart on both platforms.
- Reboot the phone and confirm reconnection without opening the app.
- Walk out of range and back, and confirm the gap is refilled from the device buffer.
- Run on at least one aggressive-battery Android brand, not only a reference device.
The same discipline produced the shipped builds in the Trackwel, BLE tag tracker, and EYVA case studies, and the full approach is summarised on the wearable app development page. For how the stored data then reaches HealthKit and Health Connect, see HealthKit vs Health Connect vs Google Health API. A BLE scoping conversation starts at contact@appmatictech.com.
Sources
| Claim used in this article | Source |
|---|---|
| Core Bluetooth background modes and state preservation and restoration | Apple Developer, Core Bluetooth Background Processing |
| Android Bluetooth permissions and foreground service types | Android Developers, Bluetooth permissions |
| Companion Device Manager | Android Developers, Companion device pairing |
| BLE failure modes from six shipped integrations | BLE mobile app development: cost and timeline |
Frequently Asked Questions
- Why does a BLE wearable app stop syncing when it is in the background?
- iOS and Android both suspend or restrict apps that are not visible to save battery. Without background Bluetooth modes and state restoration on iOS, or a foreground service and exemption handling on Android, the operating system stops the app and pending connections. AppMatic Tech designs background behaviour per platform from the first sprint.
- What is iOS Core Bluetooth state restoration?
- State restoration lets iOS relaunch an app that was terminated, and hand back its Bluetooth central manager with the peripherals it had connected or was scanning for. The app opts in with a restore identifier and the Bluetooth central background mode, then rebuilds its connection logic in the restoration callback.
- How do Android apps keep a BLE connection alive in the background?
- Android apps typically run a foreground service with a notification, using the connected device service type on recent Android versions, and pair devices through the Companion Device Manager where appropriate. Battery optimisation and vendor-specific task killers still interrupt some devices, so apps also need exemption guidance and reconnection logic.
- What causes Android GATT error 133?
- GATT error 133 is a generic connection failure on Android, commonly caused by issuing several GATT operations concurrently, stale connection caches, or connecting too soon after a disconnect. AppMatic Tech queues every GATT operation, waits for acknowledgement before the next, and retries connections with a short delay.
- How should a wearable app avoid losing data during a sync gap?
- The device should buffer readings with timestamps, and the app should write every received reading to local storage before attempting any upload. Sync then resumes from the last acknowledged record, so a dropped connection or a closed app delays data but does not lose it.