Bluetooth & IoT Device Integration

Hardware projects fail in places a design file never reaches. A device pairs on one phone and refuses on another. The link drops when the screen locks, and reconnecting means walking the user through a pairing screen they have already completed.

We build the mobile side of connected products: iOS and Android apps that discover, pair with, read, and command external hardware over Bluetooth Low Energy or Wi-Fi, and that behave predictably when the radio link does not.

What device integration covers

A connected product has two halves that meet at a documented interface. The hardware side is usually another team's work. Our job is the app that makes the device usable, plus the services behind it.

The work usually includes:

• Discovery and pairing, filtered by service UUID so the list shows hardware the app can control
• Connection lifecycle: bonding, reconnecting after backgrounding or a phone reboot, and recovering when another phone holds the device
• Reads, writes, and notifications on GATT characteristics, with the parsing that turns a byte array into a value a person can read
• Protocol and firmware version handling, so the app knows which command set a unit speaks and can warn when firmware is too old for a feature
• Calibration and offsets, because factory sensor defaults are rarely precise enough for professional measurement
• Streaming rates and buffering: how often the device reports, and what the app does when data arrives faster than the interface can redraw
• Wi-Fi paths for devices that move more data than Bluetooth comfortably handles

What only shows up on real hardware

Emulators have no radio, and a simulator never drops a connection. The decisions that decide whether a device app is good come from using the physical unit.

Dropped connections. A Bluetooth link is not a socket. Android throttles background scanning, iOS suspends the app when it leaves the foreground, and either system can end a connection without telling the app why. We make the connection state explicit (connected, disconnected, reconnecting, needs pairing), add retry with backoff, and restore sessions after a phone restart.

Vendor SDK quirks. Many hardware makers ship an SDK whose sample app shows the easy path: connect, read, done. The real unit may answer a write with a notification instead of a response, reject a command when the battery is low, or change behaviour after an undocumented firmware update. We test those cases and work at the characteristic level where an SDK blocks what the product needs.

Battery drain. Scan windows, connection intervals, notification rates, and background timers all draw current, on the phone and on the device. An app that scans continuously drains the phone, and a device reporting every twenty milliseconds will not last a working day. We measure consumption on real units and tune the reporting rate against what the user needs.

Who this is for

We work with teams where a phone has to operate something physical:

• Measurement and diagnostic tools such as level, distance, temperature, or pressure instruments
• Utility and building controls, including pumps, irrigation, solar, and access systems
• Wearables and fitness devices that collect data away from the phone and sync later
• Medical and laboratory instruments that need a clear reading and an audit trail
• Hardware startups with a working board and no app before the production run

What we deliver

A working app is the visible part. Alongside it you get the protocol layer as a separate module with its own tests, a data format documented for the firmware team, a connection state model the interface can rely on, and a written record of the device behaviours we found, quirks included. That record often stops the next developer from rediscovering a vendor bug six months later.

Where the product must work without a live connection, we build local storage and sync rules as described in offline-first mobile development. Where hardware exposes a web API, the same practice applies as in our API development and integration work.

Where the project starts

Three starting points change the first weeks of work.

A plain idea with no hardware selected yet. We help specify the protocol and data format, review candidate modules, and build a reference implementation the firmware side can test against. This adds a short discovery phase, and it prevents a rewrite when a protocol turns out to be missing a field the product needs.

An existing conventional codebase that already talks to a device. If your app is written in Swift, Kotlin, React Native, or Flutter and the Bluetooth layer was hand-rolled, we audit the connection lifecycle, the parsing, and the failure paths, then fix what breaks on real units. The existing architecture and users stay in place.

An AI-assisted or vibe-coded prototype. Fast tooling gets a pairing flow working on the developer's own phone, which is useful for showing the idea to an investor. What remains unfinished is usually reconnection, firmware variation, battery behaviour, and the tests that catch a regression after a harmless-looking change. We keep what works, replace the fragile parts, and leave a device interface another developer can extend.

How the engagement runs

We start with a paid discovery: read the protocol documentation, connect to a real unit, and write down what the app will need. Then we agree a scope with a device type, the screens involved, and the definition of done.

Development runs in short iterations against hardware you can access or that we ship to our office. Each iteration ends with a build you can install and use with your own device. Before launch we run a matrix of phone models and OS versions, check the background behaviour users hit daily, and prepare the store submissions. After launch, our free bug-fixing policy applies to the code we wrote.

What it costs

Work is billed at our flat rate of $39 per hour, or as a fixed scope once the device and protocol are known. A fixed price is hard to set before the hardware is in hand, so most device projects start with a short paid discovery.

From there, a mobile MVP with one device type, a pairing flow, and a small cloud backend sits in the range published on the pricing page, where a cross-platform mobile MVP is listed at about $4,800 to $8,500 across four to six weeks. A second radio, a second device generation, or work inside an existing app extends the timeline rather than multiplying it. Teams needing sustained capacity use the monthly plan from $2,699.

Proof

AccuLevels is a precision measurement app for iOS and Android that reads the accelerometer and gyroscope and includes a calibration flow so users can zero it against a known reference. It shows how we handle raw hardware data: sensor variance between devices, calibration, and readings stable enough for tradespeople to work from.

Black Box Control is a React Native app that monitors and controls rainwater harvesting systems from a phone, on iOS and Android. It is the clearest example in our portfolio of software sitting on top of physical equipment, where an honest status screen matters more than feature count.

SMRTSGN connects to interfaces we do not own, including Google Docs, Microsoft 365, and Dropbox, and keeps working when they change. That is the same discipline a vendor device SDK demands: the contract is documented elsewhere, and our code has to survive changes we do not control.

Related services

• Mobile apps development for the full app build around a device integration
• Sensor and precision measurement app development when the sensors live in the phone rather than in a separate unit
• Mobile backend and cloud infrastructure for storing, syncing, and reporting device data
• Offline-first mobile development for devices used where the network is not
• API development and integration for hardware that exposes an HTTP interface instead of a radio protocol

Next step

Bring the device, or the protocol documentation, and tell us who is meant to use it. We will say what the app needs, where the risk sits, and what the first phase costs.

Contact us to describe your hardware and the app around it, or run the project through the Vasilkoff.info estimator for a first scope and cost range.