Bluetooth BLE app development
Bluetooth BLE app development company for hardware companion apps
A Bluetooth companion app lives or dies on pairing and background behaviour. As a Bluetooth BLE app development company in Lahore, we build iOS and Android companion apps for wearables, sensors, tools, locks and other Bluetooth Low Energy devices. This page goes one level deeper than our IoT and wearable app development overview: background behaviour on iOS, Android 12+ permissions, pairing, firmware updates and battery. The goal is simple to state and hard to do: the device pairs first time and stays connected without draining either battery.
- Core Bluetooth and Android BLE APIs
- Background sync designed in
- Safe firmware update flows
- Tested on real units and phones
Why BLE apps fail in customers’ hands
Bench testing hides most BLE problems. On the bench the device sits ten centimetres from a developer phone, the app stays in the foreground and the firmware is the latest build. In a customer’s home the phone is in a pocket, the screen is locked, the OS has killed the app overnight and the device is two firmware versions behind.
The failures we are most often called in to fix follow from that gap: pairing that works only on the second or third try, connections that drop as soon as the app leaves the foreground, data that never syncs overnight, firmware updates that stall at 90%, and Android users who denied a permission prompt they did not understand. Each has a known cause, and most are app-side, not firmware.
If you already have an app with these symptoms, we start with a short audit of the connection layer and logs. If you are starting fresh, we design the connection layer first and build the UI on top of it.
Devices that live in a home ecosystem, such as locks, plugs and sensors, are covered on our smart home app development page, and wrist-worn products on our Apple Watch and Wear OS pages.
iOS vs Android: how BLE behaves on each platform
The two platforms behave differently enough that “write once” stops at the UI. Even in Flutter or React Native, the BLE layer needs platform-specific work.
| Topic | iOS (Core Bluetooth) | Android |
|---|---|---|
| Background operation | bluetooth-central background mode; scanning slows and duplicates are coalesced; about 10 seconds per wake-up | Foreground service for long-running connections; behaviour varies by manufacturer power management |
| Relaunch after termination | State preservation and restoration can relaunch the app for pending Bluetooth events | App must re-establish connections itself, usually from a service or scheduled work |
| Permissions | Bluetooth usage description and a system prompt | Android 12+ (API 31): BLUETOOTH_SCAN, BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE runtime permissions shown as “Nearby devices” |
| Location | Not required for BLE | Only if scan results derive location; otherwise declare neverForLocation. API 30 and lower need ACCESS_FINE_LOCATION to scan |
| Device identifiers | Peripheral UUID assigned by iOS, not the hardware address | Hardware or randomised address depending on device |
| Notifications | Standard notification permission | Android 13+: POST_NOTIFICATIONS off by default for new installs |
Sources: Apple Core Bluetooth background processing, Android Bluetooth permissions.
Android 12+ permissions without losing users
Since Android 12, Bluetooth access is behind a “Nearby devices” runtime permission. Ask too early, or without explanation, and many users tap Deny. Ask in the middle of setup, right after they have chosen to add a device, and most allow it.
Location is a separate decision. If your app never uses scan results to work out where the user is, declare neverForLocation and skip the location prompt entirely. That flag filters out some beacon advertisements, so beacon-based products need location, and the store listing and privacy details must say why. Supporting older devices adds a second path, because Android 11 and lower still need fine location to scan.
Our permission pattern
- Explain the benefit on a screen before the system prompt
- Request only when the user starts adding a device
- Handle “Don’t allow” with a clear route to Settings
- Separate paths for API 31+ and API 30 and lower
- Privacy details that match the permissions used
Pairing, bonding and onboarding
Setup is the first and often the only impression. We design it with your firmware team, because the right flow depends on what the device can display or accept.
Find the right device
Filter scans by your service UUID, show signal strength as “move closer” guidance, and use a code, serial or QR on the device when several units are in range, such as in a shop or a gym.
Secure the link
Bonding with an authenticated method (passkey, numeric comparison or out-of-band via QR) for anything that opens, controls or stores personal data. “Just works” pairing is fine only for low-risk data.
Claim ownership
Link the device to the user’s account in your backend, with a reset and transfer path for resale. Without this, support teams spend hours on “my device is registered to someone else”.
Recover from failure
Clear messages for “Bluetooth off”, “permission denied”, “device already bonded to another phone” and “out of range”, each with one action the user can take.
Pairing or background sync letting you down?
Send us a description of the device, its GATT profile if you have one and the symptoms customers report. Within one business day we reply with the likely causes and how we would audit or rebuild the connection layer.
Firmware updates over Bluetooth
Over-the-air firmware updates are where a BLE app can do real damage. A stalled update can leave a device unusable, and customers blame the app. We treat the update flow as a feature with its own acceptance criteria, built against your bootloader or the vendor’s DFU protocol.
The essentials: firmware images are signed and verified on the device; the app checks battery level on both phone and device before starting; transfers resume after a dropped connection rather than starting over; the device keeps a known-good image to fall back to; and the backend rolls updates out in stages so a bad build reaches a small group first. We also keep the screen awake and give the user a realistic time estimate.
Updates run in the foreground with the user watching. Background updates are possible in some cases, but the iOS wake-up window of about ten seconds makes them unreliable for large images.
Battery: protecting the phone and the device
Users notice battery drain on either side within days. These choices are agreed between the app and firmware teams.
- Scan only when needed and stop when the device is found
- Use filtered scans by service UUID rather than open scans
- Negotiate connection intervals per mode: fast for setup and updates, slow for idle
- Prefer notifications over polling characteristics
- Batch sensor data on the device and sync in bursts
- Disconnect when idle if the product does not need a live link
- Respect platform background limits instead of fighting them
- Measure drain over a full day on real phones, not estimates
How we build a BLE companion app
Aligned with our delivery process, with hardware in the loop throughout.
Protocol contract
During one to two weeks of discovery we document services, characteristics, data formats, error codes and the update protocol with your firmware team. NDA first; a fixed price follows.
Connection layer and test rig
Scanning, pairing, reconnection, background modes and logging, plus a hidden diagnostics screen your support team can use.
App features in two-week sprints
Each sprint ends with a TestFlight or Play internal testing build, run against real units on several phones.
Firmware update flow
Built and tested with deliberate interruptions: phone calls, app kills, low battery and walking out of range.
Field beta and launch
Real customers on TestFlight and Play testing tracks, connection analytics, then store submission and ongoing maintenance as OS releases change Bluetooth behaviour.
Native or cross-platform for a BLE app?
Both work. The question is where your team wants the complexity to live.
| Approach | Choose it when | Trade-off |
|---|---|---|
| Native Swift and Kotlin | BLE is the core of the product, background behaviour is critical, or you need watch apps | Two codebases for the whole app |
| Flutter or React Native with a BLE plugin | Mostly standard screens, simple connect-read-write flows | Plugin limits show up in background and edge cases; native code often still needed |
| Cross-platform UI with native BLE modules | You want one UI codebase but reliable Bluetooth | Clear module boundary to maintain on each platform |
BLE projects
[[Case study: device type, client sector and country, platforms, what we fixed or built, verified result with permission. Confirm before publishing.]]
Bluetooth BLE app development company FAQs
What should we look for in a Bluetooth BLE app development company?
Ask how they handle iOS background mode and state restoration, Android 12+ permissions, firmware updates that get interrupted, and testing across phone models. Ask to see a diagnostics screen or logging approach from past work. A team that only demos foreground connections on a developer phone has not yet met the problems your customers will.
Can a BLE app stay connected in the background on iPhone?
Yes, within limits. With the bluetooth-central background mode, iOS keeps connections and delivers events, but background scanning is slower, duplicate results are coalesced and the app gets about 10 seconds per wake-up. State restoration can relaunch a terminated app for pending Bluetooth work. We design sync to fit these rules.
Does our Android app need location permission for Bluetooth?
On Android 12 and later, not unless you use scan results to derive location. You request the Nearby devices permissions and declare neverForLocation. That flag filters some beacon advertisements, so beacon products still need location. On Android 11 and lower, scanning requires fine location permission, so apps supporting older devices need both paths.
Can you update our device firmware from the app?
Yes. We build over-the-air update flows against your bootloader or the chip vendor’s DFU protocol, with signed images, battery checks, resumable transfers and a fallback image on the device. Updates are rolled out in stages from the backend. We test with deliberate interruptions, because that is where real-world updates fail.
Can you work with our existing firmware?
Usually. We need the protocol details or, failing that, time with your firmware engineer and some engineering samples to map it. If the existing protocol makes reliable apps hard, such as no error codes or no way to resume transfers, we will recommend specific firmware changes and explain the trade-offs.
Can BLE apps be built in Flutter?
Yes, and for many products it works well. Flutter BLE plugins cover scanning, connecting and reading characteristics. Background behaviour, bonding edge cases and firmware updates often need native code on each platform, so we plan a native module boundary from the start rather than discovering the gap late.
Build a BLE app that pairs first time
Book a 30-minute call with your device spec. We will outline the connection design, the permission flow and the firmware update plan you need.