Connected application guide
Using MQTT in mobile applications
MQTT can make device events and commands efficient, but a dependable product needs more than a broker connection. Design the message contract, mobile lifecycle and business outcome together.
The short answer
Use MQTT in a mobile application when the product benefits from lightweight publish-and-subscribe messaging between the app, connected equipment and backend services. Define a stable client identity, narrow topic permissions, message schema, quality of service, expiry, duplicate handling, session recovery and an authoritative record of consequential outcomes.
Do not make the user journey depend on a socket remaining open. Mobile operating systems suspend background work and networks change without warning. The app must reconnect safely, recover missed state and distinguish a broker acknowledgement from proof that a real-world action completed.
01
Use MQTT where the interaction model earns it
| Need | Likely fit | Reason |
|---|---|---|
| Live device telemetry | Good MQTT candidate | Many producers and consumers can exchange small updates efficiently |
| Commands with asynchronous results | Good with an outcome model | The request and later device response can use separate topics |
| Ordinary record editing | Often use an API | Request-response validation and authoritative records are clearer |
| Historical reporting | Use durable storage | A broker should feed the system of record, not replace it |
| Push while the app is suspended | Use platform notification services | The operating system controls background execution |
A connected product can use MQTT for device traffic and an API for identity, configuration, history and reporting. Select the boundary by responsibility instead of forcing every exchange through one protocol.
02
Treat topics and payloads as a versioned product contract
Name topics around tenancy, device identity and message purpose. Avoid topic structures that reveal sensitive customer information or require clients to subscribe broadly. A command should carry enough context to recognise the logical operation without duplicating secrets or the full business record.
- schema and contract version;
- message and correlation identifiers;
- device, tenant and actor context appropriate to the receiver;
- event or command type;
- creation time and useful expiry;
- payload with units, ranges and enumerated states; and
- an outcome or error structure that a person can act on.
Publish a schema and compatibility rule before independent app, backend and firmware releases begin. Consumers should reject unsupported versions visibly instead of interpreting unknown fields as safe defaults.
03
Give every client a deliberate session and catch-up strategy
Identity
One accountable client
Use revocable credentials and a stable identity appropriate to the installation or signed-in user.
Session
Known reconnect state
Choose clean or persistent session behaviour from the messages the client must recover.
Presence
Evidence, not certainty
Keepalive and will messages help indicate a lost connection but do not prove physical condition.
Catch-up
Authoritative refresh
After reconnect, reconcile current device and business state rather than trusting only queued events.
Client identifiers must not collide across app installations. If a user changes account, a device is reassigned or credentials are revoked, define how the old session and subscriptions are closed.
04
Match protocol delivery to business idempotency
| Mechanism | What it provides | What the product still needs |
|---|---|---|
| QoS 0 | At most once protocol delivery | Tolerance for missing replaceable updates |
| QoS 1 | At least once protocol delivery | Duplicate-safe command and event processing |
| QoS 2 | Exactly once protocol exchange | Business idempotency across services and physical actions |
| Retained message | Latest retained publication for a new subscriber | Freshness, authority and deletion rules |
| Message expiry | Limits stale delivery | A product decision about what to do after expiry |
A door command, payment instruction or machine start must have a stable operation ID and a server-side outcome record. A timeout leaves the physical outcome unknown. Retry or query using the same identity so uncertainty cannot create a second action.
05
Design for mobile suspension, reconnect and network change
- Connect only when the current journey needs it or the platform permits useful background work.
- Observe network capability as a hint, then handle real connection failure.
- Use bounded reconnect backoff with jitter to protect batteries and the broker.
- Restore subscriptions and reconcile authoritative state after reconnect.
- Persist consequential outgoing operations before attempting delivery.
- Use platform-supported background scheduling for deferrable work.
- Use push notifications where the operating system must wake or inform the user.
Continue with the unreliable-connectivity guide for the broader product journey and the synchronisation guide for durable outbox and reconciliation patterns.
06
Constrain each app and device at the broker boundary
- require TLS and validate the intended broker identity;
- provision unique, revocable client credentials through a controlled path;
- authorise exact publish and subscribe topic patterns;
- validate tenant, actor and business authority again in trusted services;
- avoid shipping shared broker secrets inside the application package;
- rotate credentials and revoke lost, retired or reassigned clients;
- limit payload size, frequency and retained-message use;
- protect logs from credentials, tokens and sensitive message bodies; and
- record security-relevant connection and authorisation events.
The broker is part of the trust boundary, not a shortcut around it. Mobile application controls should follow the OWASP MASVS baseline, while device identity and lifecycle belong to the wider connected-product security model.
07
Test messages across time, failure and physical state
- Reconnect after application suspension and process termination.
- Change between Wi-Fi and cellular during command delivery.
- Send duplicate, delayed, expired and out-of-order messages.
- Revoke credentials while a session is active.
- Publish a schema version the client does not understand.
- Lose the response after the physical device completes an action.
- Restart the broker or backend consumer during an operation.
- Verify that one tenant cannot infer or access another tenant's topics.
- Compare broker, backend, app and hardware evidence using one correlation ID.
For device protocols and peripherals, continue with the hardware and IoT integration guide. LCR's public work includes an Android kiosk platform with MQTT and locker hardware integration; see the disclosed context on the work page.
Sources
Primary references
Questions
Frequently asked questions
What is MQTT used for in a mobile app?
MQTT is commonly used to exchange lightweight commands and events between an app, a broker and connected devices. It can suit live status, telemetry and device-control journeys when the topic, identity, delivery and recovery rules are explicit.
Should a mobile app keep an MQTT connection open all the time?
No mobile design should assume a permanent connection. Operating systems suspend apps, networks change and devices lose power. The app needs a reconnect and catch-up strategy, plus an API or notification path where the business journey requires it.
Which MQTT quality of service should a mobile app use?
Choose per message type. QoS 0 may fit replaceable telemetry, while QoS 1 can fit commands or events that must arrive at least once. QoS 2 has more protocol overhead and still does not replace business-level idempotency.
Are retained MQTT messages a database?
No. A retained message can provide the latest value on a topic, but it is not a complete historical or transactional source of truth. Important business outcomes should be recorded in an authoritative service.
How should MQTT access be secured?
Use encrypted transport, individual client identity, narrow topic permissions, short-lived or revocable credentials, server-side authorisation and an auditable device lifecycle. Do not embed a shared broker administrator credential in an app.
Design the message flow
Bring one device command, its event response, identity rules and failure consequence.
LCR can model the MQTT boundary and prototype it across the mobile app, broker, hardware and business system.