Blog

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: 1883 for plain TCP, 8883 for TLS, 9001 / 9443 for 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.10 or mqtt.example.com)
  • Port1883 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. 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 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, 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 / .pfx bundles (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

SymptomWhere to look
Connection times out immediatelyDNS stage in Connection Doctor — check the hostname
TCP connects but MQTT failsBroker requires authentication; check credentials
TLS handshake errorCertificate mismatch or untrusted CA; use Certificate Wizard
Messages arrive but payload is blankBinary payload — switch to hex or Base64 view
Retained message won’t clearUse 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.

← All guides

Debug MQTT on your iPhone

MQTT Commander brings this workflow to iOS and iPadOS.

Coming soon to theApp Store

Coming soon to the App Store · $2.99