AppMatic Tech builds IoT mobile applications over Bluetooth Low Energy, Wi-Fi, and MQTT, using Swift with Core Bluetooth, Kotlin with the Android BLE stack, and EMQX or AWS IoT Core brokers, choosing the protocol from range, power, and throughput requirements. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
Why is protocol choice the first IoT architecture decision?
The communication protocol connecting a physical device to a mobile application determines the product's range, battery life, data throughput, pairing model, and cloud architecture. Getting this decision wrong early means refactoring hardware and firmware later, a significantly more expensive fix than changing application code.
AppMatic Tech has built IoT-connected mobile applications across BLE, Wi-Fi, and MQTT-based architectures. This article documents the technical characteristics of each protocol and the conditions that favour one over the others.
When should an IoT mobile app use Bluetooth Low Energy (BLE)?
BLE operates over the 2.4 GHz radio band at ranges of 10–30 metres depending on antenna design and environmental conditions. It is the correct protocol when the mobile device and the IoT hardware are in close physical proximity and the device runs on a battery.
How BLE Communication Works in Mobile Apps
BLE communication is structured around the Generic Attribute Profile (GATT). A BLE device exposes one or more Services, each containing Characteristics, essentially named data channels with defined read, write, and notify permissions. The mobile app connects to the device, discovers its GATT services, and subscribes to characteristic notifications for real-time data updates.
On iOS, BLE access is handled through the Core Bluetooth framework. On Android, the Android BLE API provides equivalent functionality with different behaviour around scan modes, connection intervals, and background reconnection. These platform differences are a known source of integration complexity; a BLE integration that works correctly on iOS may behave differently on Android 8 vs Android 12 due to background scan restrictions introduced in successive Android versions.
When AppMatic Tech Uses BLE
AppMatic Tech built the Capmedic asthma controller Android app with BLE as the primary device communication channel. The Capmedic hardware device connects to the tablet app over BLE, transmitting spirometry readings, inhaler usage events, and sensor measurements to the application in real time. The short-range nature of BLE is not a constraint in this use case; the device and the tablet are in the same room during every clinical interaction.
AppMatic Tech also built the BLE Tag Tracker mobile app for asset tracking hardware. The app communicates with BLE-enabled tracking tags to report proximity and location data. BLE's low power draw allows the tags to operate for months on coin cell batteries, a requirement that ruled out Wi-Fi from the start.
BLE Trade-offs
BLE is not appropriate when data rates exceed approximately 1 Mbps, when the device and phone are not in physical proximity, or when the product requires cloud connectivity without a phone as an intermediary.
When should an IoT device connect over Wi-Fi?
Wi-Fi is appropriate when the IoT device is mains-powered, positioned in a fixed location, and needs to transmit high volumes of data, including camera feeds, audio streams, or dense sensor arrays.
A Wi-Fi connected device does not require a phone as an intermediary gateway. It connects directly to the local network and exposes an HTTP or WebSocket API that both the mobile app and a cloud backend can reach. This architecture simplifies the mobile integration (standard REST or WebSocket calls, no Bluetooth pairing flow) but requires the user to provision the device onto the Wi-Fi network during setup.
Wi-Fi provisioning is the main UX friction point in Wi-Fi IoT products. Getting the device onto the home or enterprise network requires a configuration flow, typically SoftAP (the device acts as a temporary access point) or BLE-assisted provisioning (the phone sends Wi-Fi credentials to the device over BLE, then the device disconnects and joins the main network). Both flows require careful UX design to succeed reliably across router configurations and Android Wi-Fi permission models.
When is MQTT the right protocol for IoT telemetry?
MQTT is a lightweight publish/subscribe messaging protocol designed for unreliable networks and constrained devices. It operates over TCP/IP and does not require the mobile device to be near the IoT hardware; MQTT is the correct protocol when devices publish telemetry to a cloud broker that the mobile app subscribes to.
The MQTT Architecture
An MQTT deployment has three components: the device (publishes sensor data to a topic), the broker (receives publications and routes them to subscribers), and the subscriber (the mobile app or backend system that consumes the data). The broker handles connection persistence, message queuing during disconnections, and Quality of Service guarantees.
MQTT defines three QoS levels: QoS 0 (at most once: fire and forget, no guarantee), QoS 1 (at least once: delivery confirmed, possible duplicates), and QoS 2 (exactly once: highest overhead, guaranteed single delivery). For telemetry data where occasional missed readings are acceptable, QoS 0 or 1 is standard. For command-and-control messages (turning a device on or off), QoS 2 is appropriate.
Broker Selection
Common MQTT broker options for production IoT systems:
- Mosquitto: Open-source, lightweight, suitable for low-device-count deployments on a single server. Not horizontally scalable without additional tooling.
- EMQX: Scales to millions of concurrent connections, supports clustering, and includes a management console. Since version 5.9, EMQX is licensed under the Business Source License 1.1: a single node is free for production use, and a cluster requires a license. AppMatic Tech uses EMQX for mid-to-large IoT deployments.
- AWS IoT Core: Fully managed MQTT broker from AWS. Integrates natively with AWS Lambda, DynamoDB, S3, and CloudWatch. Certificates-based device authentication. The correct choice when the rest of the infrastructure is already on AWS and the team wants a managed service.
When AppMatic Tech Uses MQTT
MQTT is the correct choice for asset tracking systems where devices are spread across a geography and report location or status data to a central platform. The mobile app subscribes to device-specific topics and receives live telemetry without requiring a direct connection to the hardware.
How do BLE, Wi-Fi, and MQTT compare for IoT apps?
| Criterion | BLE | Wi-Fi | MQTT |
|---|---|---|---|
| Range | 10–30 metres | Local network | Unlimited (cloud-routed) |
| Power draw | Very low | High | Device-dependent |
| Data throughput | Up to ~1 Mbps | Up to hundreds of Mbps | Low (designed for small payloads) |
| Requires phone as gateway | Yes | No | No |
| Cloud connectivity | Via phone | Direct | Direct |
| Best for | Wearables, medical devices, proximity tags | Smart home, fixed appliances | Fleet tracking, industrial telemetry |
| Mobile SDK complexity | High (GATT, platform differences) | Low (standard HTTP/WebSocket) | Moderate (MQTT client library) |
How does AppMatic Tech build IoT mobile apps?
AppMatic Tech builds IoT-connected mobile applications for device manufacturers and platform operators across BLE, Wi-Fi, and MQTT architectures. For a BLE implementation example, see how AppMatic Tech delivered the BLE Tag Tracker companion app with native iOS and Android device integration. For decisions that compound at platform scale, read how to scale an IoT platform from 100 to 100,000 devices and MCP server architecture for IoT device management. Contact the team at contact@appmatictech.com for a technical scoping discussion.
Frequently Asked Questions
- Should an IoT mobile app use BLE, Wi-Fi, or MQTT?
- AppMatic Tech uses BLE when a battery-powered device sits near the phone, Wi-Fi when a mains-powered device in a fixed location must move high volumes of data, and MQTT when a fleet of devices publishes telemetry to a cloud broker that the mobile app subscribes to. Many products combine them, using BLE for setup and MQTT for cloud telemetry.
- What is the range of Bluetooth Low Energy?
- Bluetooth Low Energy typically reaches 10 to 30 metres over the 2.4 GHz band, depending on antenna design and the environment. AppMatic Tech does not use BLE when data rates exceed roughly 1 Mbps, when the phone and device are not in physical proximity, or when the product needs cloud connectivity without a phone acting as the gateway.
- Can a single IoT device use both BLE and MQTT?
- Yes. A common architecture is dual-radio: the device uses BLE to talk to a nearby phone during setup and local interaction, and MQTT over Wi-Fi or cellular for cloud telemetry. AppMatic Tech has implemented this pattern for asset tracking hardware, running configuration and firmware updates over BLE and location reporting over MQTT.
- Which MQTT QoS level should an IoT app use?
- For telemetry where an occasional missed reading is acceptable, AppMatic Tech uses MQTT QoS 0 or QoS 1. For command-and-control messages, such as switching a device on or off, QoS 2 provides exactly-once delivery at the cost of higher overhead, which is the correct trade-off when a duplicated or lost command has consequences.
- How does AppMatic Tech handle Android BLE background scan restrictions?
- Android 8 and later restrict BLE scanning in the background. AppMatic Tech runs BLE operations that must continue outside the foreground inside a foreground service, which shows the persistent notification Android requires, and manages the connection within the service lifecycle rather than the Activity lifecycle.