Customers judge a connected product by its app: if pairing fails or an update bricks the device, the hardware gets the blame. Agnotic Technologies builds Bluetooth Low Energy companion apps that pair reliably, update firmware safely and behave the same across phones.
Trusted by global innovators
BLE apps
BLE app development is building the iOS and Android app that finds, pairs with and updates a Bluetooth Low Energy product such as a lock, tracker, sensor or tool. Agnotic Technologies builds companion apps that follow each platform's permission and background rules, update firmware without bricking devices and work across many phone models.
This page is for connected consumer and industrial products. BLE health devices that feed clinical records, and the GATT and pairing security basics, are covered on our BLE medical device integration page.
Most BLE bugs come from the phone side: permissions, background limits and chipset differences. We design for them from the first sprint.
Failure points
The failures we design against on every connected product app.
Challenge
Scans find nothing on Android 12 and later because the app never asked for the new Bluetooth permissions.
Agnotic approach
Declare BLUETOOTH_SCAN and BLUETOOTH_CONNECT, ask for them in context, and set neverForLocation when the app does not use scans for location.
Challenge
iOS suspends the app in the middle of a long transfer.
Agnotic approach
Use the bluetooth-central background mode and state restoration, and design transfers to resume from the last confirmed chunk.
Challenge
A firmware update drops halfway and the device will not boot.
Agnotic approach
Dual-slot images on the device, verified before the swap, with automatic rollback to the previous image.
Challenge
A resold device stays bonded to the previous owner's account.
Agnotic approach
An ownership transfer flow: a factory reset clears bonds and keys on the device, and the cloud record is released before a new owner claims it.
Challenge
Connections behave differently on one phone brand or chipset.
Agnotic approach
A test matrix across chipsets and OS versions, and connection settings that tolerate slower phones.
Platform rules
Both mobile platforms limit what an app can do with Bluetooth, and the limits change between OS versions.
Firmware updates
A failed update is the most expensive bug a connected product can ship, so the flow assumes the connection will drop.
Battery level, current firmware version and signal quality are checked, and the update waits if any is too low.
The signed image is downloaded and verified on the phone first, so a weak mobile network never interrupts the BLE transfer.
Data moves in numbered chunks with acknowledgements, and an interrupted transfer resumes from the last confirmed chunk.
The device checks the signature and hash of the complete image before it will boot it.
The new image boots from a second slot; if it fails its self-test, the device returns to the previous image.
The app reads the new version back and reports the result to your backend, so support can see each device's state.
First-time setup, naming, and Wi-Fi credential handover for devices that also have Wi-Fi.
Claiming a device, sharing it with family or a team, transfer on resale and revoking access.
Logs and readings stored on the device, synced when the phone connects and deduplicated on the server.
Staged rollouts by device group, using the update flow above.
Signal strength, connection events and error codes that users can send to your support team.
The backend for accounts, the device registry and update management.
Testing
Lock and open flows that must work fast, offline and only for the right person.
Background scanning and last-seen location within each platform's rules.
Bikes, rowers and scales sending sessions to the app, for consumer fitness rather than medical use.
Configuration, readings and maintenance logs collected in the field by technicians.
Settings, firmware updates and registration for audio, lighting and home devices.
References
Platform rules from Apple, Google and the Bluetooth SIG, each read on its source page.
Apps that target Android 12 (API level 31) or higher must declare BLUETOOTH_SCAN to look for BLE devices, BLUETOOTH_CONNECT to talk to paired devices and BLUETOOTH_ADVERTISE to make the phone discoverable.
Source: Android Developers: Bluetooth permissionsOn Android, an app can mark BLUETOOTH_SCAN with the neverForLocation flag to assert it never derives location from scans, but some BLE beacons are then filtered from the scan results.
Source: Android Developers: Bluetooth permissionsApple requires the NSBluetoothAlwaysUsageDescription key, a message telling people why the app needs Bluetooth, in any iOS app that uses the device's Bluetooth interface.
Source: Apple Developer Documentation: NSBluetoothAlwaysUsageDescriptionFor Core Bluetooth state restoration, the restore identifier passed to the central manager must be identical across executions of the app, because iOS uses it to identify that manager.
Source: Apple Developer Documentation: CBCentralManagerOptionRestoreIdentifierKeyThe Bluetooth SIG states that all Bluetooth products must be qualified, through the Bluetooth Qualification Process completed in its Qualification Workspace tool.
Source: Bluetooth SIG: qualify your productScope and cost
We do not publish prices. These factors change the size of the build.
Native iOS and Android, or a cross-platform app with native Bluetooth modules.
How complete the device protocol documentation is and how quickly the firmware team can ship test builds.
Signed images, dual slots, staged rollouts and reporting.
Each hardware revision adds protocol differences to handle and test.
Accounts, device registry, sharing and update management.
How many phone models and OS versions must be covered before release.
