When developing a mobile IoT application, choosing the right data exchange protocol is critical. MQTT — a publish/subscribe model over TCP with delivery guarantees — has become the standard for resource-constrained devices. However, on iOS/Android, MQTT configuration must account for background modes, battery efficiency, and unstable networks. In our practice, integrating MQTT into a smart home project on Flutter reduced telemetry latency to 200 ms with 10,000 devices. Key decisions were QoS 1, persistent sessions, and mTLS. We have been working with IoT for over 7 years and have implemented MQTT in 50+ projects — from simple sensors to industrial controllers. MQTT is 10x more efficient than HTTP for IoT data transmission, reducing bandwidth usage significantly.
Choosing Optimal QoS for IoT
The QoS level determines the balance between reliability and traffic overhead. For mobile devices with limited bandwidth, this is critical.
| QoS Level | Delivery Guarantee | Traffic | Typical Use Case |
|---|---|---|---|
| 0 | None (fire and forget) | Minimal | Telemetry (temperature, coordinates) |
| 1 | At least once (possible duplicates) | Moderate | Commands (on/off) |
| 2 | Exactly once (four-phase handshake) | Maximum | Critical operations (finance, security) |
In practice, for IoT commands we most often use QoS 1 combined with idempotent processing on the device side. QoS 2 on a mobile device in the background can cause session hangs due to handshake interruptions — our cases confirm a 5% loss rate for commands at QoS 2 due to disconnections. Compare: for the same data volume, HTTP with long polling generates 80% more traffic, which is critical for capped data plans.
Last Will Is Mandatory for IoT
Last Will Message (LWM) is a mechanism that allows the broker to automatically publish a message about an abnormal client disconnection. Without LWM, the UI will show the device as online until the keep-alive timeout expires (20–60 seconds). We always configure LWM with topic {deviceId}/status and message {"status":"offline"}. A persistent session (cleanSession: false) complements LWM: the broker stores a message queue for the offline client. On reconnection, the client receives all missed commands. It is important to set sessionExpiryInterval (in MQTT 5) or cleanSession (in MQTT 3.1.1) so the queue does not grow indefinitely — for example, for sensors with infrequent reporting, 1 hour is sufficient.
Persistent Sessions: Guaranteed Delivery
A persistent session guarantees message delivery during temporary device disconnection. It is indispensable for systems where every command must be executed, such as door locks or industrial controllers. However, on memory-constrained devices, the queue may overflow — we recommend setting sessionExpiryInterval to no more than 24 hours. In one project on Kotlin Multiplatform, configuring persistent sessions reduced command loss from 12% to 0.1%.
Choosing a Client Library
Each platform has optimal options.
| Platform | Recommended Library | MQTT 5 Support |
|---|---|---|
| Android | HiveMQ MQTT Client | Yes |
| iOS | CocoaMQTT | No |
| Flutter | mqtt_client | No |
| React Native | react_native_mqtt (wrapper) | No |
Android: For Android MQTT development, HiveMQ is actively maintained, works with Kotlin Coroutines. iOS: For iOS MQTT, CocoaMQTT is a good choice; it is simple to set up but does not support MQTT 5. Flutter: mqtt_client is popular, supports MQTT 3.1.1 and WebSocket transport. React Native: no native MQTT — use a wrapper over native Paho or WebSocket transport with mqtt.js. For projects with high-frequency data streams (over 1000 messages/sec), consider MQTTNio on iOS.
TLS and Connection Security
For production, always use MQTT over TLS (port 8883). Mutual TLS (mTLS) is the security standard in IoT, but for a mobile app, username/password paired with a server certificate is sufficient. Store credentials in Keychain (iOS) or EncryptedSharedPreferences (Android). Never hardcode the broker URL — use remote config. We apply this scheme in all projects, and over 7 years we have had zero credential leaks.
How to Integrate MQTT in a Mobile App
Follow these steps for a successful integration:
- Define the topic schema and choose QoS levels for each data type.
- Select a broker (Mosquitto, EMQX, HiveMQ) and configure TLS.
- Integrate the chosen MQTT client library (HiveMQ for Android, CocoaMQTT for iOS).
- Configure Last Will and persistent session parameters.
- Test in background mode and on unstable networks, then deploy.
What Our MQTT Integration Work Includes
We offer a full integration cycle with specific deliverables:
- Documentation of topic schema and QoS recommendations
- Access to configured broker with admin rights
- Training session for your team (2 hours)
- Support for 30 days post-deployment
Integration timeline for MQTT into an existing mobile app is 1–3 weeks depending on complexity. Our MQTT integration service starts at $2,500 and can save you up to 40% on development time compared to in-house implementation. Get your project evaluated in 2 days — just write to us. Receive a consultation on protocol and architecture selection.
MQTT standard is defined in the OASIS MQTT specification. Order an analysis of your IoT project — we will help you choose the optimal stack and settings.