Native Mobile & Bluetooth (BLE) App Development for Connected Devices
We build native mobile apps that talk to physical hardware over Bluetooth Low Energy — and we build them so they keep working after the demo. Most teams can ship a screen that lists nearby devices; the hard part is a connection that survives a dropped link, a GATT 133 error, an OS that re-bonds at the wrong moment, and a user who walks out of range mid-sync. That reliability layer is our wedge, and you own every line of it when we're done.
BLE is mostly edge cases — that's the work
Reading a characteristic once is easy. Holding a stable bonded link through reconnects, retrying with backoff instead of hammering the radio, disconnecting before close to dodge the Android 133 error, and guarding against stale GATT callbacks is where connected-device apps actually live or die. We've shipped a native app that runs a multi-opcode sync sequence against real firmware — heartbeat, set-time, calibration reads, record count, request records, sync-complete — and recovers cleanly when any step drops. We treat the unhappy path as the product, because for hardware it is.
When there's no SDK, we read the protocol off the wire
Plenty of connected devices ship with no documentation and no developer SDK — just a vendor app and a chip. We reverse-engineer the GATT service: capturing the official app's traffic with a BLE sniffer, mapping the characteristics and opcodes, and rebuilding the protocol in your app from scratch. We're honest about the limits of this — if a flow was only ever observed during sync and not during pairing, we'll tell you that's a known gap rather than pretend the map is complete.
Native or React Native — chosen for the radio, not the resume
For BLE-heavy apps we usually reach for native (Kotlin/Jetpack Compose on Android, Swift on iOS) because you get direct, predictable control over bonding, GATT, and background services. When a project genuinely benefits from one codebase, we'll build it in React Native with a Bluetooth Low Energy library and drop to a native module exactly where the radio reliability demands it. We pick based on where your app's risk actually is, and we explain the tradeoff before we write code.
Background sync, batteries, and the OS fighting you
Connected-device apps have to keep syncing when the screen is off and survive a reboot, without draining the phone or getting killed by the OS. We build foreground sync services with sane intervals, boot receivers that bring them back, and notifications for the events that matter — a reading threshold crossed, a low device battery. We've also fought the platform-specific traps: GrapheneOS hiding Bluetooth scanning behind a location toggle, Private Space blocking BLE scans, runtime-revocable INTERNET permission silently breaking uploads. We design around them instead of getting surprised in the field.
Local-first, and the code is yours
Most connected-device data is personal — health readings, location, sensor history — and it does not need to live on someone else's servers. We default to local-first: data persists on-device in a real database, deduplicated and queryable, with the network optional rather than required. No rented backend you can't leave, no account wall between a user and their own hardware. At handoff you get the full source, the build toolchain, and the reverse-engineered protocol notes — you own the app, the data, and the path to maintain both.
Frequently asked questions
- Can you build a native app that connects to our existing Bluetooth device?
- Yes — that's our core work. If you have a developer SDK or a GATT spec we'll build to it; if you don't, we can reverse-engineer the protocol by sniffing your current app's BLE traffic and rebuild it in a native app. We've done exactly this for a device with no public SDK, including the full opcode-level sync sequence.
- Should our connected-device app be native or React Native?
- It depends where the risk is. For Bluetooth-heavy apps we usually recommend native (Kotlin or Swift) for direct, predictable control over bonding, GATT, and background sync. If a single codebase matters more and the BLE surface is modest, we'll build it in React Native with a Bluetooth Low Energy library and write native modules for the parts that need radio-level reliability. We'll walk you through the tradeoff for your specific device before committing.
- Why do BLE apps work in a demo but break in the real world?
- Real-world Bluetooth means dropped links, range loss mid-transfer, OS-level bonding quirks, GATT 133 connection errors, and stale callbacks after a reconnect. A demo never hits these; a shipped app hits them daily. We build the retry, backoff, reconnect, and bond-management layer as a first-class part of the app, which is the difference between a prototype and something you can put in users' hands.
- Who owns the code and the data when you're finished?
- You do. We hand off the complete source code, the build and release toolchain, and our protocol and reliability notes. We default to local-first storage so user data stays on the device rather than on a backend you'd have to keep renting. There's no platform lock-in and no dependency on us to keep the app running.
Have something worth building?
Tell us what you're building — you'll hear back from the person who'd actually write the code, usually within a day.