Bluetooth and BLE App Development

What a BLE app has to handle that other apps do not

In a Bluetooth Low Energy app, the phone acts as the central and your device as the peripheral. The app scans for advertisements, filters by your service identifier, connects, and then reads, writes and subscribes to characteristics defined in the device’s GATT profile. That part is well documented. The hard part is everything around it, and that is where Tepia spends most of the engineering on a connected device project.

• Platform differences. iOS hides the device’s hardware address and gives each phone its own identifier, so pairing records cannot be shared across a user’s devices without your own device ID. Android 12 introduced separate scan and connect permissions, while older versions require location permission to scan at all.
• Background behavior. iOS can relaunch an app for Bluetooth events through state restoration, and Android needs a foreground service for continuous connections. Each limits what the app can do while the screen is off.
• Small packets. The default packet size is tiny, so Tepia negotiates a larger MTU where the device supports it and frames longer messages into chunks with sequence numbers.
• Messy real conditions. Devices sleep to save battery, users walk out of range, phones restart, and someone factory resets the device without telling the app.

Common Bluetooth app types and what each must do

The device category changes the design more than the radio does. Tepia scopes the app around patterns like these:

Many products combine two rows. An access control system, for example, may use Bluetooth at the door and the cloud for administration, which is the kind of mix we handle in gate and access control apps and broader IoT and connected device app development.

Working alongside your hardware and firmware team

Most Bluetooth delays come from the gap between app and firmware teams, so Tepia closes it early. We write a shared protocol document listing every service, characteristic, data format, error code and version number, and we version the protocol so a new app can talk to older firmware still in the field. Engineers work with your development kits and real production units, use tools such as nRF Connect to inspect traffic, and keep a rack of test devices for hardware in the loop testing before each release.

Security is designed with the firmware, not added by the app. Tepia uses LE Secure Connections pairing where the hardware supports it, and for sensitive commands such as opening a door we add authentication at the application layer so a captured message cannot simply be replayed.

Phone coverage matters as much as device coverage. Bluetooth stacks differ between Android manufacturers and operating system versions, and a connection that is stable on a Pixel can drop on another brand. Tepia keeps a test matrix of current iPhones and popular Samsung, Google and Motorola models, and records which phone and OS version each connection log came from so field issues can be reproduced.

Firmware updates over the air need the most care. Tepia builds update flows that check battery level first, transfer the image in resumable chunks, let the device verify the signature before switching, and fall back to the previous image if anything fails.

How Tepia approaches Bluetooth app development

Connected device projects run through the six Tepia phases, with the hardware team involved in each.

1. Discovery: review of the device, firmware roadmap, GATT profile and any cloud backend, plus interviews with installers and end users. Deliverables include the Investigation Summary, a protocol document draft and User Stories such as a homeowner adding a second lock.
2. Design: wireframes for pairing, connection status, out of range states, firmware update progress and permission prompts, plus a style guide that suits the product’s hardware brand.
3. Development and Testing: the Bluetooth layer is built and tested against real units first. Alpha runs on a device rack covering several iOS and Android phones; Beta goes to field users with production hardware, with test plans for range, interference, battery drain and update recovery.
4. Training: installers and support staff learn commissioning, troubleshooting and how to read device logs from the admin portal.
5. Launch: store submission with the right Bluetooth usage descriptions, a staged rollout, and migration of device registrations from any previous app.
6. Support: crash and connection logs by phone model, bug tracking against firmware versions, and new features as hardware evolves.

See the full Tepia process.

Native, React Native or Flutter for Bluetooth

Native Swift and Kotlin give the most direct control over Bluetooth and background behavior, and Tepia uses them when an app streams data continuously, must stay connected for hours, or works with medical or safety critical hardware. React Native and Flutter work well for most companion apps through mature Bluetooth plugins, and the rest of the interface ships faster from one codebase.

A common middle path is to write the Bluetooth layer as a native module on each platform and build the screens cross platform, which Tepia describes in our cross platform app development work. Device data then flows to a backend on AWS, Azure or GCP and into an admin portal, as it did for the Maximum Controls apps and portal shown in our work. If you have hardware ready or in prototype, talk to Tepia about the app around it.

Frequently asked questions