Availability: internal preview. The iOS app is not publicly distributed yet.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
What it does
- Connects to a Gateway over WebSocket (LAN or tailnet).
- Exposes node capabilities: Canvas, Screen snapshot, Camera capture, Location, Talk mode, Voice wake.
- Receives
node.invokecommands and reports node status events.
Requirements
- Gateway running on another device (macOS, Linux, or Windows via WSL2).
- Network path:
- Same LAN via Bonjour, or
- Tailnet via unicast DNS-SD (example domain:
openclaw.internal.), or - Manual host/port (fallback).
Quick start (pair + connect)
- Start the Gateway:
- In the iOS app, open Settings and pick a discovered gateway (or enable Manual Host and enter host/port).
- Approve the pairing request on the gateway host:
requestId is created.
Run openclaw devices list again before approval.
Optional: if the iOS node always connects from a tightly controlled subnet, you
can opt in to first-time node auto-approval with explicit CIDRs or exact IPs:
role: node pairing with
no requested scopes. Operator/browser pairing and any role, scope, metadata, or
public-key change still require manual approval.
- Verify connection:
Relay-backed push for official builds
Official distributed iOS builds use the external push relay instead of publishing the raw APNs token to the gateway. Gateway-side requirement:- The iOS app registers with the relay using App Attest and a StoreKit app transaction JWS.
- The relay returns an opaque relay handle plus a registration-scoped send grant.
- The iOS app fetches the paired gateway identity and includes it in relay registration, so the relay-backed registration is delegated to that specific gateway.
- The app forwards that relay-backed registration to the paired gateway with
push.apns.register. - The gateway uses that stored relay handle for
push.test, background wakes, and wake nudges. - The gateway relay base URL must match the relay URL baked into the official/TestFlight iOS build.
- If the app later connects to a different gateway or a build with a different relay base URL, it refreshes the relay registration instead of reusing the old binding.
- No deployment-wide relay token.
- No direct APNs key for official/TestFlight relay-backed sends.
- Install the official/TestFlight iOS build.
- Set
gateway.push.apns.relay.baseUrlon the gateway. - Pair the app to the gateway and let it finish connecting.
- The app publishes
push.apns.registerautomatically after it has an APNs token, the operator session is connected, and relay registration succeeds. - After that,
push.test, reconnect wakes, and wake nudges can use the stored relay-backed registration.
Background alive beacons
When iOS wakes the app for a silent push, background refresh, or significant-location event, the app attempts a short node reconnect and then callsnode.event with event: "node.presence.alive".
The gateway records this as lastSeenAtMs/lastSeenReason on the paired node/device metadata only
after the authenticated node device identity is known.
The app treats a background wake as successfully recorded only when the gateway response includes
handled: true. Older gateways may acknowledge node.event with { "ok": true }; that response is
compatible but does not count as a durable last-seen update.
Compatibility note:
OPENCLAW_APNS_RELAY_BASE_URLstill works as a temporary env override for the gateway.
Authentication and trust flow
The relay exists to enforce two constraints that direct APNs-on-gateway cannot provide for official iOS builds:- Only genuine OpenClaw iOS builds distributed through Apple can use the hosted relay.
- A gateway can send relay-backed pushes only for iOS devices that paired with that specific gateway.
-
iOS app -> gateway- The app first pairs with the gateway through the normal Gateway auth flow.
- That gives the app an authenticated node session plus an authenticated operator session.
- The operator session is used to call
gateway.identity.get.
-
iOS app -> relay- The app calls the relay registration endpoints over HTTPS.
- Registration includes App Attest proof plus a StoreKit app transaction JWS.
- The relay validates the bundle ID, App Attest proof, and Apple distribution proof, and requires the official/production distribution path.
- This is what blocks local Xcode/dev builds from using the hosted relay. A local build may be signed, but it does not satisfy the official Apple distribution proof the relay expects.
-
gateway identity delegation- Before relay registration, the app fetches the paired gateway identity from
gateway.identity.get. - The app includes that gateway identity in the relay registration payload.
- The relay returns a relay handle and a registration-scoped send grant that are delegated to that gateway identity.
- Before relay registration, the app fetches the paired gateway identity from
-
gateway -> relay- The gateway stores the relay handle and send grant from
push.apns.register. - On
push.test, reconnect wakes, and wake nudges, the gateway signs the send request with its own device identity. - The relay verifies both the stored send grant and the gateway signature against the delegated gateway identity from registration.
- Another gateway cannot reuse that stored registration, even if it somehow obtains the handle.
- The gateway stores the relay handle and send grant from
-
relay -> APNs- The relay owns the production APNs credentials and the raw APNs token for the official build.
- The gateway never stores the raw APNs token for relay-backed official builds.
- The relay sends the final push to APNs on behalf of the paired gateway.
- To keep production APNs credentials out of user gateways.
- To avoid storing raw official-build APNs tokens on the gateway.
- To allow hosted relay usage only for official/TestFlight OpenClaw builds.
- To prevent one gateway from sending wake pushes to iOS devices owned by a different gateway.
apps/ios/fastlane/.env only stores
App Store Connect / TestFlight auth such as ASC_KEY_ID and ASC_ISSUER_ID; it does not configure
direct APNs delivery for local iOS builds.
Recommended gateway-host storage:
.p8 file or place it under the repo checkout.
Discovery paths
Bonjour (LAN)
The iOS app browses_openclaw-gw._tcp on local. and, when configured, the same
wide-area DNS-SD discovery domain. Same-LAN gateways appear automatically from local.;
cross-network discovery can use the configured wide-area domain without changing the beacon type.
Tailnet (cross-network)
If mDNS is blocked, use a unicast DNS-SD zone (choose a domain; example:openclaw.internal.) and Tailscale split DNS.
See Bonjour for the CoreDNS example.
Manual host/port
In Settings, enable Manual Host and enter the gateway host + port (default18789).
Canvas + A2UI
The iOS node renders a WKWebView canvas. Usenode.invoke to drive it:
- The Gateway canvas host serves
/__openclaw__/canvas/and/__openclaw__/a2ui/. - It is served from the Gateway HTTP server (same port as
gateway.port, default18789). - The iOS node auto-navigates to A2UI on connect when a canvas host URL is advertised.
- Return to the built-in scaffold with
canvas.navigateand{"url":""}.
Computer Use relationship
The iOS app is a mobile node surface, not a Codex Computer Use backend. Codex Computer Use andcua-driver mcp control a local macOS desktop through MCP
tools; the iOS app exposes iPhone capabilities through OpenClaw node commands
such as canvas.*, camera.*, screen.*, location.*, and talk.*.
Agents can still operate the iOS app through OpenClaw by invoking node
commands, but those calls go through the gateway node protocol and follow iOS
foreground/background limits. Use Codex Computer Use
for local desktop control and this page for iOS node capabilities.
Canvas eval / snapshot
Voice wake + talk mode
- Voice wake and talk mode are available in Settings.
- iOS may suspend background audio; treat voice features as best-effort when the app is not active.
Common errors
NODE_BACKGROUND_UNAVAILABLE: bring the iOS app to the foreground (canvas/camera/screen commands require it).A2UI_HOST_NOT_CONFIGURED: the Gateway did not advertise a canvas host URL; checkcanvasHostin Gateway configuration.- Pairing prompt never appears: run
openclaw devices listand approve manually. - Reconnect fails after reinstall: the Keychain pairing token was cleared; re-pair the node.