# OpenClaw Launches Native iOS and Android Companion Apps
OpenClaw has officially released native companion applications for both iOS and Android platforms. The iOS version is listed on the App Store as “OpenClaw – AI that does things.” Both apps are available as free downloads. However, it is important to understand that these are not standalone chatbots. Instead, each phone functions as a node within a self-hosted agent network. The assistant itself operates on a separate Gateway, and this architectural separation is central to the entire design philosophy.
## TL;DR
– OpenClaw’s iOS and Android apps serve as companion nodes, not standalone assistants.
– The Gateway runs the agent; phones contribute camera, location, voice, and Canvas capabilities.
– Nodes pair over WebSocket on port 18789 and require explicit approval.
– Privacy-sensitive commands remain disabled until you explicitly allowlist them.
– A Gateway running on macOS, Linux, or Windows (WSL2) is required.
## What Is OpenClaw?
OpenClaw is an open-source personal AI assistant and agent. It was created by Peter Steinberger along with community contributors. The project operates independently and maintains no affiliation with Anthropic. Its core is written in TypeScript, and the runtime requires Node 24 (recommended) or Node 22.19+. The Gateway runs on macOS, Linux, or Windows via WSL2. Users interact with the assistant through chat applications they already use daily. Supported channels include WhatsApp, Telegram, Discord, Slack, Signal, and iMessage. The agent is capable of browsing the web, running shell commands, and reading and writing files. It works with hosted models, subscription-backed models, gateway models, or local models. Users simply bring an API key from their chosen provider. The system maintains persistent memory and supports community skills and plugins.
## How the Gateway-and-Nodes Architecture Works
The Gateway serves as the single control plane. It owns sessions, routing, channels, tools, and events. Users run one Gateway process on their own machine or server. Chat messages always land on the Gateway, never on a phone. A node is a companion device that connects to that Gateway. Nodes connect over a WebSocket on the default port 18789. Each node registers with `role: “node”` during the pairing process. Nodes expose a command surface through `node.invoke`. Those command families include `canvas.*`, `camera.*`, `device.*`, `notifications.*`, and `system.*`. The documentation is explicit: “Nodes are peripherals, not gateways.” On a local network, apps discover the Gateway via mDNS/Bonjour. For remote access, OpenClaw recommends Tailscale with a `wss://` endpoint.
## What Do the Mobile Apps Add?
The phone essentially gives the agent a body. It grants device-specific hardware capabilities to your workflows. The iOS app pairs via QR code or setup code. It supports chat, realtime and background Talk mode, and approvals. Users can share text, links, and media from iOS directly into OpenClaw. Optional capabilities include camera, screen, location, photos, contacts, calendar, and reminders. The Android app functions as a companion node, not a standalone gateway. It offers streaming chat replies, image attachments, and full session history. Talk Mode uses ElevenLabs or system TTS. A live Canvas surface allows the agent to render dashboards and interactive tools. Android grants permissions one at a time. A foreground service keeps the Gateway connection alive.
## iOS Node vs Android Node
| Capability | iOS — OpenClaw – AI that does things | Android — OpenClaw node |
|—|—|—|
| Role | Companion node | Companion node |
| Pairing | QR code or setup code | Setup code or manual host/port |
| Chat | Chat from iPhone | Streaming replies, image attachments, full session history |
| Voice | Realtime and background Talk mode | Talk Mode (ElevenLabs or system TTS) |
| Canvas | Canvas surface | Live Canvas surface |
| Device capabilities | Camera, screen, location, photos, contacts, calendar, reminders | Camera, photos, screen capture, location, notifications, contacts, calendar, SMS, motion sensors |
| Action approvals | Reviewable from the iPhone | Managed on the Gateway |
| Data collection | None declared (App Store) | None declared (Google Play) |
| Requirement | iOS 18.0+ and a running Gateway | A running Gateway on macOS, Linux, or Windows (WSL2) |
## Use Cases With Examples
Consider field data collection on a job site. The agent uses iOS camera capture to photograph conditions on the ground. Location tags each photo with GPS coordinates automatically. Consider a context-aware reminder scenario. The agent triggers a specific task when you reach a designated place. Consider an incoming notification on Android. The agent reads it and drafts a reply on your behalf. Consider a live dashboard use case. The agent pushes a Canvas surface directly to your screen. Consider hands-free operation. Talk Mode holds a continuous voice conversation with the agent. One important caveat applies to camera and screen capture functionality: both require the app to be in the foreground. Background calls for these features will return an error.
## Pairing a Phone: A Minimal Walk-Through
First, run the Gateway on a supported host:
“`
# On the Gateway host (macOS, Linux, or Windows via WSL2)
npm install -g openclaw@latest
openclaw onboard –install-daemon
“`
Next, open the app and select a discovered Gateway. Alternatively, enter the host and port manually. The app connects with `role: “node”` and sends a device pairing request. Approve it from the Gateway CLI:
“`
openclaw devices list
openclaw devices approve
openclaw nodes status # confirm the node is paired and connected
“`
Privacy-heavy commands stay off by default. Examples include `camera.snap`, `camera.clip`, and `screen.record`. Users opt in explicitly through `gateway.nodes.allowCommands` in their configuration:
“`
// ~/.openclaw/openclaw.json
{
gateway: {
nodes: {
allowCommands: [“camera.snap”, “screen.record”],
},
},
}
“`
A deny list (`gateway.nodes.denyCommands`) always takes precedence over the allowlist.
## Security and Approvals
Pairing credentials are stored on the device. Every
—
*Original article source: [OpenClaw Native Mobile Apps Release](https://example.com/openclaw-mobile-apps)*# OpenClaw Gateway & Nodes: Architecture, Security, and Device Pairing Explained
## How the Gateway-and-Nodes Architecture Works
OpenClaw operates on a **Gateway-and-Nodes architecture** where a single Gateway process serves as the central control plane. The Gateway runs on macOS, Linux, or Windows (WSL2) and owns sessions, routing, channels, tools, and events. Every message from every channel — whether WhatsApp, Telegram, or Discord — lands on the Gateway first. The Gateway then routes commands to connected nodes, such as iOS or Android phones, which provide access to device hardware like cameras, location, sensors, and screen capture.
This design means the Gateway is the **single source of truth** in the system. Nodes never receive messages directly from chat apps; all communication is mediated through the Gateway’s routing layer.
## Security Model: Approval, Roles, and Encryption
OpenClaw enforces several layers of security to protect user data and device access:
**Node connection requires approval.** Before a node can communicate with the Gateway, the connection must be explicitly approved by the operator. This prevents unauthorized devices from joining the network.
**Device pairing records are durable role contracts.** Once a device is paired, its role is fixed. Token rotation — the process of refreshing authentication tokens — **cannot upgrade a node into a different role**. This ensures that a paired node cannot escalate its privileges simply by rotating its token.
**Camera and screen capture are permission-gated.** These sensitive hardware features run only when the app is in the **foreground**, and they require explicit user permission. Background access to cameras or screens is not permitted.
**Cleartext WebSocket connections are restricted.** Unencrypted `ws://` connections are limited to **LAN and `.local` hosts only**. For any public or Tailscale endpoints, a real `wss://` TLS endpoint is **required**. This ensures that traffic leaving the local network is always encrypted.
## Interactive Explainer: Simulating the System
An interactive explainer allows users to explore the architecture in a browser-based simulation. It includes three main sections:
### ① Architecture Map
Users can click on any block — Gateway, OpenClaw agent, CLI/Web UI,
