MQTT carries the traffic in most smart-home and IoT systems, from Home Assistant to Zigbee2MQTT to industrial sensor networks. Most developers work with it from a laptop using desktop tools. Running MQTT on an iPhone or iPad changes where you can work: walk around the house, watch live sensor data, trigger automations, and debug broker issues away from your desk. The setup below covers plain connections and the TLS and mutual-TLS configurations that production brokers require.

What You Need

An iOS device running iOS 17 or later (iPhone or iPad)
MQTT Commander installed: a native SwiftUI app, free to download with an optional $4.99 one-time Pro unlock
The hostname or IP address of your MQTT broker (Mosquitto, HiveMQ, EMQX, Home Assistant’s built-in broker, etc.)
The broker port: 1883 for plain TCP, 8883 for TLS, 9001 / 9443 for WebSocket/WSS
Credentials if your broker requires them (username and password)

No subscription and no account: the app and a reachable broker are enough.

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.10 or mqtt.example.com)
Port: 1883 for unencrypted, 8883 for 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. The app stores them in the iOS Keychain rather than plain text. They stay on your device and go nowhere except 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), the certificate (chain, expiry, and hostname), ALPN/SNI, and finally the MQTT CONNECT itself (WebSocket/WSS upgrade issues surface inside the TCP and TLS stages). Each stage either passes or shows a specific error, so you can track the problem to one layer instead of reading 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 topics
zigbee2mqtt/#: all Zigbee2MQTT device messages
home/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, that helps when 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 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 overwrite a retained message by mistake. 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 other tools let you trigger without asking.

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 require TLS, and so does any broker exposed to the internet. 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 Manager.

Mutual TLS (client certificates)

For mTLS, you also need a client certificate and private key. You import the client identity (certificate plus private key) as a single .p12 / .pfx bundle; the private key cannot come in on its own as a standalone PEM. A private CA arrives as a PEM certificate. The Certificate Manager imports:

.p12 / .pfx bundles for the client identity (certificate + private key in one file)
PEM-formatted certificate for the CA (and server certificate)

The Certificate Manager checks the certificate’s expiry date and verifies that the Subject Alternative Name (SAN) or Common Name (CN) matches the broker’s expected value, with trust anchored to the CA you import. 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 surface WebSocket/WSS upgrade problems within the TCP and TLS stages, so you can tell whether the problem is TCP, TLS, or the upgrade itself.

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 Manager
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 names the failure stage with a human-readable description, which in most cases resolves the issue without digging through broker logs.

Privacy Note

Hostnames, credentials, certificates and message history all stay on your device. MQTT Commander sends only anonymous, opt-out crash diagnostics (via Sentry and Aptabase). No part of your broker traffic reaches a third party.

How to Use MQTT on iPhone and iPad