How to Use MQTT on iPhone and iPad
A practical guide to using MQTT on iPhone and iPad: connect to a broker, subscribe to topics, inspect payloads, and publish — with TLS and mTLS support.
June 8, 2026
MQTT is the backbone of most smart-home and IoT systems — from Home Assistant to Zigbee2MQTT to industrial sensor networks. Traditionally, developers interact with it from a laptop using desktop tools. But having MQTT on iPhone or iPad is genuinely useful: you can walk around the house, watch live sensor data, trigger automations, and debug broker issues without being tethered to a desk.
This guide walks through what you need, how to get connected, and how to work with messages safely — including the TLS and mutual-TLS setups that production brokers require.
What You Need
- An iOS device running iOS 15 or later (iPhone or iPad)
- MQTT Commander installed — a native SwiftUI app, one-time purchase at $2.99
- The hostname or IP address of your MQTT broker (Mosquitto, HiveMQ, EMQX, Home Assistant’s built-in broker, etc.)
- The broker port:
1883for plain TCP,8883for TLS,9001/9443for WebSocket/WSS - Credentials if your broker requires them (username and password)
No subscription, no account required — just the app and a reachable broker.
Connecting to a Broker
Step 1: Add a Broker Profile
Open MQTT Commander and tap the + button to create a new broker profile. Enter:
- Host — the broker’s hostname or IP (e.g.,
192.168.1.10ormqtt.example.com) - Port —
1883for unencrypted,8883for TLS - Client ID — auto-generated, or set your own
MQTT Commander supports both MQTT 3.1.1 and MQTT 5.0 — select the version your broker expects.
Step 2: Enter Credentials
If your broker requires authentication, add the username and password in the Credentials section. These are stored in the iOS Keychain, not in plain text — they stay on your device and are never transmitted anywhere other than to the broker itself.
Step 3: Connect and Confirm
Tap Connect. If the connection succeeds, the status indicator turns green and you’ll see the broker’s CONNACK details (useful with MQTT 5.0, which includes extended reason codes).
If the connection fails, the built-in Connection Doctor runs a staged diagnostic: it checks DNS resolution, TCP reachability, TLS handshake (if applicable), WebSocket upgrade (if applicable), and finally the MQTT handshake itself. Each stage either passes or shows a specific error, which makes tracking down the problem much faster than a generic “connection refused.”
Subscribing and Reading Payloads
Once connected, subscribe to a topic to start receiving messages. Tap Subscribe and enter a topic filter:
#— wildcard that matches everything (useful for exploration; use with care on busy brokers)homeassistant/#— all Home Assistant discovery and state topicszigbee2mqtt/#— all Zigbee2MQTT device messageshome/sensors/+/temperature— the+wildcard matches a single level
MQTT Commander includes a Topic Tree with Home Assistant and Zigbee2MQTT presets, so you can subscribe to the right topics without typing them from scratch.
Incoming messages appear in real time. Tap any message to open the Payload Inspector, which offers:
- JSON pretty-print with syntax highlighting
- Diff view — compare the current payload against the previous one for the same topic
- Hex and Base64 views for binary payloads
- Image preview for topics that carry image data
- JSONPath queries to extract specific fields from large JSON blobs
For Home Assistant users, this is particularly useful for watching homeassistant/sensor/+/state or inspecting device availability via homeassistant/device_automation/#.
Publishing Messages Safely
The publish composer is draft-first: you compose the full message before anything is sent. Before you tap Publish, you set:
- Topic — the exact topic string
- Payload — free text, JSON, or binary
- QoS — 0 (fire and forget), 1 (at least once), or 2 (exactly once)
- Retain flag — whether the broker should store this as the last known value
If you enable the retain flag, the app shows a warning so you don’t accidentally overwrite a retained message without realising it. If a topic already has a retained message and you want to clear it, the app prompts for confirmation before publishing an empty retained payload — a destructive operation that’s easy to do by mistake in other tools.
See the related post on Home Assistant MQTT from iPhone for examples of publishing to homeassistant/switch/my_device/set and watching the state topic respond.
Going Secure with TLS and mTLS
Most production brokers — and any broker exposed to the internet — require TLS. Some require mutual TLS (mTLS), where both the broker and the client present certificates.
Plain TLS (port 8883)
Set the port to 8883 and enable TLS in the connection settings. MQTT Commander validates the broker’s certificate against the system trust store. If your broker uses a private CA, import the CA certificate through the Certificate Wizard.
Mutual TLS (client certificates)
For mTLS, you also need a client certificate and private key. The Certificate Wizard imports:
.p12/.pfxbundles (certificate + private key in one file)- PEM-formatted certificate and key files
The wizard validates the chain, checks the expiry date, and verifies that the Subject Alternative Name (SAN) or Common Name (CN) matches the broker’s expected value. It also supports ALPN protocol negotiation and SNI (Server Name Indication) for brokers that multiplex multiple services on the same port.
For a detailed walkthrough of certificate setup and common TLS errors, see MQTT TLS and mTLS debugging.
WebSocket and WSS
If your broker is behind a reverse proxy that terminates WebSocket connections (a common setup with Home Assistant or cloud-hosted brokers), switch the transport to WebSocket (ws://, port 9001) or WSS (wss://, port 9443). The Connection Doctor’s staged checks cover the WebSocket upgrade step separately, so you can tell immediately whether the problem is TCP, TLS, or the WebSocket handshake.
Common Issues
| Symptom | Where to look |
|---|---|
| Connection times out immediately | DNS stage in Connection Doctor — check the hostname |
| TCP connects but MQTT fails | Broker requires authentication; check credentials |
| TLS handshake error | Certificate mismatch or untrusted CA; use Certificate Wizard |
| Messages arrive but payload is blank | Binary payload — switch to hex or Base64 view |
| Retained message won’t clear | Use the retained-delete confirmation in the publish composer |
The Connection Doctor surfaces the exact failure stage with a human-readable description, which is usually enough to resolve the issue without digging through broker logs.
Privacy Note
All broker connection data — hostnames, credentials, certificates, message history — stays on your device. MQTT Commander sends only anonymous, opt-out crash diagnostics (via Sentry and Aptabase). Nothing from your broker traffic is ever transmitted to any third party.