Eight questions to ask before hiring a team for a BLE or hardware-connected app

Bluetooth, serial-port and USB projects — "app plus hardware" — look roughly like ordinary app projects on a quote. What actually decides the outcome sits on the device side: who defined the protocol, who does on-device integration, and what happens to data when a device drops off. Settling these before signing is far cheaper than arguing about them at acceptance.

Below are eight questions we, as the vendor, would want a client to ask. Each one is followed by what a passing answer sounds like, plus how we handle that stage ourselves — we are not pretending to be neutral here.

Question 1: is the device-side work yours, or do you hand it to the hardware vendor?

A hardware-connected app is always delivered in two halves: the app, and the device behind it. Some teams build only the interface and leave protocol integration, gateways and firmware coordination entirely to the hardware vendor. The result: when the device ships a new firmware version, the app breaks, and nobody owns it.

Passing answer: the team can say plainly which half they own and which needs vendor cooperation; they have real devices to integrate against, not just a simulator; the integration process is documented and can be reviewed.

How we do it: device integration is a distinct block in our delivery. We built a central device management platform where two device generations connect at once — networked devices speaking MQTT, and older equipment with nothing but an RS-485 or RS-232 port, collected locally by an industrial PC or gateway. The two channels each run their own segment inside one back end, unified by a single model above.

Question 2: how deep does the Bluetooth work go — Classic or BLE?

These two mean very different things. Bluetooth Classic (including SPP) is often used for serial passthrough; BLE works through GATT services and characteristics. Asking this question is really about whether the team has taken a protocol apart for real.

Passing answer: they can name which one is in use; they can say who defined the GATT services and characteristics (a vendor protocol document, or reconstructed by capturing traffic); they can explain how framing, reassembly, MTU and connection parameters are handled.

The test is simple: a team that cannot discuss protocol detail has probably never worked on real hardware.

Question 3: what if the protocol document is incomplete and the vendor will not help?

This is the most common opening on a hardware project: a few pages of protocol notes, or none at all, and an unreachable vendor.

Passing answer: the ability to reconstruct the protocol from packet captures and logs, and to write that reconstruction down — because whoever maintains it next will depend on it.

However good the answer sounds, it comes down to one thing: is there a maintainable document left behind?

Question 4: can new and old devices be managed in one system?

Many clients hold both recent networked devices and equipment from years earlier that does not even have a network port — and they want one platform showing all of it.

Passing answer: protocol adaptation separated from the business model — as many adapter layers as there are protocols underneath, unified by one device model above. Adding a new device should not require changing the business layer.

How we do it: in one back end we run MQTT and serial as two parallel channels and unify them into a scene → device → command model. That structure has since been reused in charging-infrastructure data collection and monitoring, and in industrial equipment status management.

Question 5: weak signal, disconnection, offline devices — how is data not lost?

The link between a mobile app and a device is unreliable: lifts, basements and device reboots all break it. Whether the seconds of data lost in that gap are dropped or re-sent matters a great deal.

Passing answer: local caching and re-send, idempotent handling of duplicate reports, an explicit rule for when a device is considered offline (how long a heartbeat timeout), and alerting on anomalies.

If the answer is only "it generally does not disconnect", ask one more question: after it disconnects, what does the app show?

Question 6: how do you handle iOS and Android differences?

Background limits, permission timing and available Bluetooth scanning scope differ between the two platforms. Copying the same logic across usually means one side works and the other generates complaints.

Passing answer: specific platform differences named, rather than "we adapt it"; a clear statement of which logic lives in the native layer and which goes cross-platform.

How we do it: projects that call device capabilities deeply go native — a depth-camera app, for instance, drives hardware directly — while lighter business layers can go cross-platform. We have delivered real projects on all four lines: Swift, Objective-C, Kotlin and Dart.

Question 7: what do I actually receive at delivery?

Hardware-connected projects are where handover goes wrong most often. "We deliver the source code" can mean a complete project or a pile of files.

Passing answer: a complete, buildable project including build configuration and dependency versions; protocol and integration records; deployment documentation; and a defined support window during handover — each item written into the contract.

In our own deliveries, source and deployment documentation are handed over in full, and the project structure holds up when opened.

Question 8: who is responsible for store submission, permissions and filing?

An app connected to hardware usually needs more permissions — Bluetooth, camera, location — and has more privacy and submission pitfalls.

Passing answer: a clear split of who does what on the app filing, the privacy manifest and permission usage descriptions, and which steps require the client. The developer account holder and the filing entity sit in the client's name; those stages should not be delegated.

How we do it: from account entity verification, certificates and provisioning profiles, through upload and rejection handling, to filing materials and the privacy manifest, we have walked every one of these stages and written them up.

The common thread

Not one of these eight questions is about how impressive the technology sounds. They all ask the same thing: has this team actually worked on the device side. The risk in a hardware-connected app is not the interface — it is the half of the chain you cannot see: protocol, integration, disconnection, handover.

If you have a project like this, run the eight questions first. Or send us the specific scenario and we can go through the device list and communication methods together before deciding how to build it.

Learn more: Native App Development · AIoT Application Development · Technical Consulting. Need a scope list in writing? Describe your business and get a requirements list in seconds.

Read the original Chinese note

All technical notes