A connected device is only as good as its connection to the phone. When that connection drops, the user does not blame the operating system. They blame the device, and often they return it.
Most dropped Bluetooth connections are not bugs in the firmware. They come from the phone itself, which closes background work to save battery. This guide covers what iOS and Android actually do, the tools each one gives you, and how to design a device and its app so a lost connection never loses data.
Why phones close Bluetooth connections
Phones have small batteries and dozens of apps that would all like to run in the background. Apple and Google handle this the same way: once an app leaves the screen, the system limits what it can do, and after a while it stops the app entirely. A companion app holding a Bluetooth connection is exactly the kind of background work the system wants to stop.
The four states matter because each one needs a different answer. Code that works perfectly while the app is on screen can fail the moment the screen locks, and testing on a desk with the app open will never show it.
iOS: Core Bluetooth state restoration
On iOS, an app that declares the Bluetooth background mode keeps its connections while it is in the background. When memory runs low, the system may still suspend the app and then end it. State preservation and restoration is how Apple lets a Bluetooth app survive that. The app opts in when it creates its Bluetooth manager, and the system keeps track of its connections and pending requests on its behalf.
When the device reconnects, sends a notification or completes a pending request, iOS relaunches the app in the background and hands back the state it saved. The app has a short window to restore its Bluetooth manager and handle the event, so that code has to be fast and has to run before anything else at launch.
What state restoration will not do
- Relaunch an app the user swiped away in the app switcher.
- Relaunch an app after Bluetooth was turned off and on again in settings.
- Keep a connection the app never asked the system to restore.
The first point catches most teams out. When a user closes the app by swiping it away, iOS treats that as a clear instruction, and nothing in Core Bluetooth will bring the app back until the user opens it again.
Android: a foreground service and the Companion Device Manager
Android gives an app more freedom in the background, and takes it away more suddenly. Without a foreground service, a backgrounded app usually loses its Bluetooth connection within minutes. A foreground service tells the system the app is doing work the user cares about, and shows a notification so the user knows it is running. On recent Android versions the service has to declare the connected device type and request the matching permission.
The Companion Device Manager goes a step further. When the user pairs the device through it, Android treats the app as the companion of that device and grants exemptions ordinary apps do not get, including permission to start its foreground service from the background when the device comes back into range. For a product that needs to stay connected all day, this is the most reliable route Android offers.
Phone makers add their own battery rules
Some manufacturers ship battery savers that go further than stock Android and close apps even while a foreground service is running, sometimes within twenty minutes. The dependable answer is to detect these phones and walk the user through allowing the app to run unrestricted, at the moment it matters, with clear steps for their exact phone.
Design the device for a missing app
Every technique above makes disconnections rarer. None of them makes disconnections impossible, so the device and the app have to treat a lost link as normal. The pattern that works is simple: the device stores readings it could not send, numbers each one, and sends them in order when the link returns.
- The device keeps readings in a buffer sized for the longest gap you expect, with a clear rule for what to drop if it fills.
- Each reading carries a sequence number and the time it was taken, so its place in the history is fixed whenever it arrives.
- On reconnect, the app asks for everything after the last number it confirmed, and the cloud ignores any number it has already stored.
- The app shows the user when data last synced, so a gap looks like a gap and the device does not look broken.
How to test it before your users do
Background behaviour only shows up in testing that copies real life. Every companion app should go through the same set of situations on real phones, including at least one phone from each manufacturer known for aggressive battery saving.
- Lock the screen for an hour, then check every reading arrived.
- Leave the phone still overnight so it reaches its deepest power saving state.
- Walk out of range and back again.
- Swipe the app away, take readings, then open the app and check the sync.
- Turn Bluetooth off and on, and restart the phone.
- Update the app while the device is connected.
A test passes only when every reading taken during it reaches the cloud once, in the right order.
That is how we build companion apps at CoreFinity Tech. The firmware, the app and the cloud are designed together around one message format, so a dropped connection becomes a short delay the user barely notices. If your device is losing data in the background, send us a short description and we will tell you where it is likely breaking.