Implementing IoT Device Interaction via Mobile App

Implementing IoT Device Interaction via Mobile App

The smart lock app stops receiving updates when the user walks more than 50 meters away — Bluetooth drops, and no Wi-Fi fallback is in place. Or a temperature sensor sends data once an hour, but the MQTT broker doesn’t acknowledge receipt, and readings are lost. We encounter such cases regularly: connection drops, state desynchronization, OTA update failures. On one project, 80% of lost commands were due to QoS 0 — after migrating to QoS 1, the error rate dropped by a factor of 10. Over our years of work with IoT, we have delivered more than 30 projects where stable mobile-to-device communication was the key challenge. In this article, we break down how to properly implement IoT device interaction via a mobile app, using proven protocols and patterns. We also cover how to avoid typical mistakes when choosing a protocol and setting up infrastructure.

We offer turnkey integration: from protocol selection to app store deployment. Proper architecture can save up to 40% in operational costs. Contact us for a free assessment of your project.

Which Protocol to Choose for Your IoT Device?

A mobile app most often acts as an MQTT client or BLE Central. Direct Zigbee control from a phone without a hub is rare. BLE uses 10 times less energy than Wi-Fi, which is critical for battery-powered devices.

MQTT: The Most Common IoT Transport

MQTT is a pub/sub protocol over TCP, described in MQTT. A broker (Mosquitto, AWS IoT, HiveMQ) receives messages and distributes them to subscribers. The mobile app subscribes to device topics and publishes commands.

iOS — MQTT-Client-Framework or CocoaMQTT:

import CocoaMQTT let client = CocoaMQTT(clientID: "mobile-\(UUID().uuidString)", host: "broker.example.com", port: 8883) client.username = "user" client.password = "pass" client.enableSSL = true client.keepAlive = 60 client.delegate = self client.connect() // Subscription after connect: func mqtt(_ mqtt: CocoaMQTT, didConnectAck ack: CocoaMQTTConnAck) { guard ack == .accept else { return } mqtt.subscribe("devices/sensor-01/temperature", qos: .qos1) } // Receiving data: func mqtt(_ mqtt: CocoaMQTT, didReceiveMessage message: CocoaMQTTMessage, id: UInt16) { if let payload = message.string { let temp = Double(payload) updateUI(temperature: temp) } } // Publishing a command: client.publish("devices/lamp-01/command", withString: "{\"state\":\"on\",\"brightness\":80}") 

Android — Paho MQTT Android Service or HiveMQ MQTT Client:

// HiveMQ (modern, no deprecated API) val client = MqttClient.builder() .useMqttVersion5() .serverHost("broker.example.com") .serverPort(8883) .sslWithDefaultConfig() .simpleAuth() .username("user") .password("pass".toByteArray()) .applySimpleAuth() .buildAsync() client.connect().whenComplete { _, throwable -> if (throwable == null) { client.subscribeWith() .topicFilter("devices/sensor-01/temperature") .qos(MqttQos.AT_LEAST_ONCE) .callback { publish -> val payload = String(publish.payloadAsBytes) // update UI via Handler or LiveData } .send() } } 

How QoS Affects MQTT Reliability

QoS 0 — at most once. Fast, no acknowledgment. Suitable for high-frequency updates (temperature every second). QoS 1 — at least once. With acknowledgment, possible duplicates. Minimum for commands (on/off). QoS 2 — exactly once. Guaranteed delivery without duplicates. For payment operations, critical commands. Choosing QoS is a trade-off between speed and reliability. For most IoT scenarios, QoS 1 is sufficient.

Last Will Message

MQTT allows setting a message that the broker sends when a client disconnects unexpectedly. Important for IoT: if the phone goes offline, other clients should know:

client.willMessage = CocoaMQTTMessage( topic: "clients/mobile-app/status", string: "{\"online\":false}" ) 

Synchronizing Device State

The main architectural problem: when the app opens, what is the current state of all devices? MQTT does not store history by default. Solutions:

Retained messages — the device publishes its state with the retain = true flag. The broker stores the last message and immediately delivers it on subscription. The mobile app subscribes to devices/+/state on startup and gets the current states. Retained messages restore state after reconnection 5 times faster than sending a request via REST API.

Shadow/Digital Twin — AWS IoT Device Shadow, Azure Device Twin — REST API for reading the last known device state. Useful when there are many states and retained MQTT is insufficient.

OTA Firmware Updates

If the device supports updates via the mobile app (BLE OTA or MQTT), this is a separate task. Standards: Nordic DFU (for nRF chips via BLE), ESP-IDF OTA over HTTP/MQTT, MCU Bootloader over UART-bridge.

How to Handle Background Work Without Draining the Battery?

A mobile app cannot keep an MQTT connection in the background constantly. For device event notifications — APNS/FCM: the broker or backend sends a push on state change. This approach saves up to 30% battery life compared to a permanent connection.

What’s Included in the Work

1. Requirements analysis and protocol selection
2. Interaction architecture design (topics, QoS, retained messages)
3. Mobile client development (iOS/Android) with BLE/MQTT integration
4. Broker and backend configuration (if needed)
5. Implementation of OTA updates via the app
6. Push notification setup (APNS/FCM) for device events
7. Testing on real devices and debugging
8. Documentation preparation and access handover

Timeline and Cost

Integration timeline: from 1 week (basic MQTT client) to 3–4 weeks (full stack with OTA, state synchronization, push notifications). Cost is determined after an individual assessment. Contact us for an accurate estimate and free consultation.