Connected product guide
Mobile apps that connect to hardware and IoT
Build the app, device protocol, backend and operational lifecycle as one connected product. The interface is only useful when physical outcomes remain safe, observable and recoverable.
The short answer
A mobile app can connect to hardware through Bluetooth Low Energy, USB, a vendor SDK, a local network protocol, or a cloud API and message broker. Choose the path from the physical task, range, power, data volume, platform support, security, offline need and operational ownership.
Define discovery, pairing, device identity, commands, events, timeouts, duplicate handling, firmware compatibility, recovery and support before polishing the screen. For every consequential command, distinguish the user's request, protocol delivery and verified physical outcome.
01
Draw the complete connected-product boundary
Add identity, business systems, management tools, monitoring and support to this picture. Record who owns every link and which component is authoritative for configuration, access, current state and history.
App
User intent
Guides the task, validates safe input and communicates current confidence.
Service
Business authority
Applies access, records outcomes and coordinates shared or remote state.
Device
Physical capability
Enforces local safety and reports observed state in a defined protocol.
Operations
Lifecycle ownership
Provisions, monitors, updates, supports and retires the installed estate.
02
Select the transport from the operating conditions
| Path | Can fit | Watch closely |
|---|---|---|
| Bluetooth Low Energy | Nearby setup, sensors and low-power controls | Permissions, discovery, pairing, range, reconnect and platform differences |
| USB | Wired accessories, specialist terminals and high-confidence proximity | Host/accessory roles, connectors, permissions, power and driver support |
| Vendor SDK | Supported scanners, printers, payment or industrial equipment | Version support, licensing, native integration and vendor lifecycle |
| Local network | On-site equipment and higher-volume local exchange | Discovery, segmentation, certificates and unavailable internet |
| Cloud API or MQTT | Remote control, shared state, fleet events and audit | Latency, identity, service availability and physical outcome reconciliation |
Prototype the exact phones, tablets, adapters and hardware revisions. A protocol that works on a developer device may fail after operating-system changes, power constraints or fleet-specific policy.
03
Write a protocol contract before parallel development
- device model, hardware revision and firmware version;
- discovery, selection, pairing and ownership transfer;
- service, characteristic, endpoint, command and event definitions;
- payload schema, units, byte order, ranges and required fields;
- correlation and stable operation identifiers;
- acknowledgement, progress, completion and error states;
- timeout, retry, cancellation and idempotency behaviour;
- backward and forward compatibility rules; and
- diagnostic data safe to expose to users and support teams.
Use a state machine for multi-step physical operations. Unknown or invalid transitions should fail visibly. A device must not interpret missing data as permission to perform a consequential default action.
04
Keep user intent, delivery and physical outcome distinct
| State | Meaning | Evidence |
|---|---|---|
| Requested | The user or system created an authorised operation | Durable operation record |
| Accepted | A service or device recognised the command | Correlated acknowledgement |
| In progress | The physical process has started | Device event or observed state |
| Completed | The defined physical success condition was met | Final device evidence and business record |
| Unknown | Communication ended before the outcome was learned | Reconciliation required |
| Failed | A terminal condition prevented completion | Classified cause and next action |
If a response is lost, query using the original operation ID. Do not issue a fresh command until the product can prove that repeating the physical action is safe. For broker-based flows, use the MQTT mobile application guide.
05
Apply security across app, device, service and lifecycle
NIST's IoT device cybersecurity baseline describes capabilities including device identification, configuration, data protection, logical access to interfaces, secure software update, cybersecurity state awareness and device security. Map those capabilities to the people and systems that will operate the product.
- give each device a unique, revocable identity;
- authorise the current user and action in a trusted component;
- protect local and transmitted sensitive data;
- limit exposed Bluetooth, USB, network and diagnostic interfaces;
- verify firmware and application updates through a controlled process;
- remove shared secrets from application packages and repositories;
- record security and lifecycle events without collecting unnecessary personal data; and
- define reassignment, loss, compromise and retirement actions.
Use the OWASP MASVS for the mobile application boundary, then assess the firmware, backend, broker, management and supply-chain controls separately.
06
Test the physical environment and failure boundaries
- Use every supported device, phone, tablet, adapter and firmware combination.
- Remove power or connectivity between each command state.
- Send duplicate, delayed, malformed and out-of-order protocol messages.
- Move in and out of range during discovery, pairing and an active operation.
- Deny or revoke operating-system permissions.
- Restart the app, mobile device, hardware and backend independently.
- Fill queues and storage, expire credentials and change authorised users.
- Upgrade and roll back app, backend and firmware versions where supported.
- Verify safe behaviour when sensors disagree with the requested state.
- Follow one operation across mobile, transport, device and business logs.
Test in the actual noise, mounting, power, connectivity and human environment. Bench success is useful evidence, but it is not proof of a dependable field workflow.
07
Prepare the minimum integration brief
Record the physical outcome, user, environment, supported platforms, hardware and firmware versions, transport, protocol owner, command states, safety rules, source of truth, identity, permissions, offline behaviour, monitoring, support path, update method and lifecycle owner.
Build the smallest vertical slice that proves discovery or connection, one authorised command, the physical outcome, recovery from an interrupted response and the resulting business record. If the app runs on managed equipment, continue with the dedicated business device guide or the Android kiosk solution.
Sources
Primary references
Questions
Frequently asked questions
How can a mobile app connect to hardware?
A mobile app can use Bluetooth Low Energy, USB, a vendor SDK, a local network protocol or a cloud API and message broker. Choose the transport from range, bandwidth, power, platform support, environment and ownership requirements.
Should a mobile app connect directly to an IoT device?
Direct connection can fit setup, nearby control or offline work. A backend path can fit remote access, shared state, policy and audit. Many products use both, with explicit authority and reconciliation rules.
How do you know a hardware command succeeded?
Use a stable operation ID and separate accepted, started and physically completed states. Confirm against device evidence or an authoritative service rather than treating a network acknowledgement as physical completion.
What should happen if the app loses connection during a command?
Treat the outcome as unknown until the app can query or reconcile it. Retrying blindly may repeat a physical action. The device or backend should recognise the original operation ID.
How should connected hardware be secured?
Use unique device identity, secure update, protected data, constrained interfaces, revocable credentials, least-privilege authorisation, event logging and a supported device lifecycle. Apply mobile controls to the app and IoT controls to the device and service.
Plan the connected product
Bring the hardware, user journey, protocol documentation, operating environment and failure consequence.
LCR can define the integration boundary and prototype the highest-risk physical journey before a wider rollout.