App iOS (Node)
Disponibilità: anteprima interna. L’app iOS non è ancora distribuita pubblicamente.Cosa fa
- Si connette a un Gateway tramite WebSocket (LAN o tailnet).
- Espone capacità del nodo: Canvas, snapshot dello schermo, acquisizione della fotocamera, posizione, modalità Talk, voice wake.
- Riceve comandi
node.invokee segnala eventi di stato del nodo.
Requisiti
- Gateway in esecuzione su un altro dispositivo (macOS, Linux o Windows tramite WSL2).
- Percorso di rete:
- stessa LAN tramite Bonjour, oppure
- tailnet tramite DNS-SD unicast (dominio di esempio:
openclaw.internal.), oppure - host/porta manuali (fallback).
Guida rapida (pair + connect)
- Avvia il Gateway:
- Nell’app iOS, apri Settings e scegli un gateway rilevato (oppure abilita Manual Host e inserisci host/porta).
- Approva la richiesta di pairing sull’host del gateway:
requestId.
Esegui di nuovo openclaw devices list prima dell’approvazione.
- Verifica la connessione:
Push supportato da relay per le build ufficiali
Le build iOS ufficiali distribuite usano il relay push esterno invece di pubblicare il token APNs grezzo al gateway. Requisito lato gateway:- L’app iOS si registra presso il relay usando App Attest e la ricevuta dell’app.
- Il relay restituisce un handle relay opaco più una send grant con ambito di registrazione.
- L’app iOS recupera l’identità del gateway associato e la include nella registrazione relay, così la registrazione supportata da relay viene delegata a quel gateway specifico.
- L’app inoltra quella registrazione supportata da relay al gateway associato con
push.apns.register. - Il gateway usa l’handle relay memorizzato per
push.test, wake in background e wake nudges. - Il base URL del relay del gateway deve corrispondere all’URL del relay incorporato nella build iOS ufficiale/TestFlight.
- Se in seguito l’app si connette a un gateway diverso o a una build con un base URL del relay differente, aggiorna la registrazione relay invece di riutilizzare il vecchio binding.
- Nessun token relay valido per l’intera distribuzione.
- Nessuna chiave APNs diretta per invii ufficiali/TestFlight supportati da relay.
- Installa la build iOS ufficiale/TestFlight.
- Imposta
gateway.push.apns.relay.baseUrlsul gateway. - Esegui il pairing dell’app con il gateway e lascia che completi la connessione.
- L’app pubblica automaticamente
push.apns.registerdopo aver ottenuto un token APNs, quando la sessione operatore è connessa e la registrazione relay è riuscita. - Dopo questo,
push.test, i wake di riconnessione e i wake nudges possono usare la registrazione supportata da relay memorizzata.
OPENCLAW_APNS_RELAY_BASE_URLfunziona ancora come override env temporaneo per il gateway.
Flusso di autenticazione e attendibilità
Il relay esiste per applicare due vincoli che APNs diretto sul gateway non può fornire per le build iOS ufficiali:- Solo le build iOS OpenClaw autentiche distribuite tramite Apple possono usare il relay ospitato.
- Un gateway può inviare push supportati da relay solo ai dispositivi iOS che hanno eseguito il pairing con quel gateway specifico.
-
app iOS -> gateway- L’app esegue prima il pairing con il gateway tramite il normale flusso auth del Gateway.
- Questo fornisce all’app una sessione node autenticata più una sessione operator autenticata.
- La sessione operator viene usata per chiamare
gateway.identity.get.
-
app iOS -> relay- L’app chiama gli endpoint di registrazione del relay tramite HTTPS.
- La registrazione include prova App Attest più la ricevuta dell’app.
- Il relay convalida il bundle ID, la prova App Attest e la ricevuta Apple, e richiede il percorso di distribuzione ufficiale/di produzione.
- Questo è ciò che impedisce alle build locali Xcode/dev di usare il relay ospitato. Una build locale può essere firmata, ma non soddisfa la prova di distribuzione Apple ufficiale che il relay si aspetta.
-
delega dell'identità del gateway- Prima della registrazione relay, l’app recupera l’identità del gateway associato da
gateway.identity.get. - L’app include quell’identità del gateway nel payload di registrazione relay.
- Il relay restituisce un handle relay e una send grant con ambito di registrazione delegati a quell’identità del gateway.
- Prima della registrazione relay, l’app recupera l’identità del gateway associato da
-
gateway -> relay- Il gateway memorizza l’handle relay e la send grant di
push.apns.register. - In
push.test, nei wake di riconnessione e nei wake nudges, il gateway firma la richiesta di invio con la propria identità del dispositivo. - Il relay verifica sia la send grant memorizzata sia la firma del gateway rispetto all’identità del gateway delegata dalla registrazione.
- Un altro gateway non può riutilizzare quella registrazione memorizzata, anche se in qualche modo ottiene l’handle.
- Il gateway memorizza l’handle relay e la send grant di
-
relay -> APNs- Il relay possiede le credenziali APNs di produzione e il token APNs grezzo per la build ufficiale.
- Il gateway non memorizza mai il token APNs grezzo per le build ufficiali supportate da relay.
- Il relay invia il push finale ad APNs per conto del gateway associato.
- Per tenere le credenziali APNs di produzione fuori dai gateway degli utenti.
- Per evitare di memorizzare sul gateway i token APNs grezzi delle build ufficiali.
- Per consentire l’uso del relay ospitato solo alle build OpenClaw ufficiali/TestFlight.
- Per impedire a un gateway di inviare wake push a dispositivi iOS appartenenti a un gateway diverso.
Percorsi di discovery
Bonjour (LAN)
L’app iOS sfoglia_openclaw-gw._tcp su local. e, quando configurato, lo stesso
dominio di discovery DNS-SD wide-area. I gateway sulla stessa LAN appaiono automaticamente da local.;
la discovery cross-network può usare il dominio wide-area configurato senza cambiare il tipo di beacon.
Tailnet (cross-network)
Se mDNS è bloccato, usa una zona DNS-SD unicast (scegli un dominio; esempio:openclaw.internal.) e Tailscale split DNS.
Vedi Bonjour per l’esempio CoreDNS.
Host/porta manuali
In Settings, abilita Manual Host e inserisci host + porta del gateway (predefinita18789).
Canvas + A2UI
Il nodo iOS renderizza un canvas WKWebView. Usanode.invoke per pilotarlo:
- L’host canvas del Gateway serve
/__openclaw__/canvas/e/__openclaw__/a2ui/. - Viene servito dal server HTTP del Gateway (stessa porta di
gateway.port, predefinita18789). - Il nodo iOS naviga automaticamente verso A2UI alla connessione quando viene annunciato un URL host canvas.
- Torna allo scaffold integrato con
canvas.navigatee{"url":""}.
Eval / snapshot canvas
Voice wake + modalità Talk
- Voice wake e la modalità Talk sono disponibili in Settings.
- iOS può sospendere l’audio in background; considera le funzioni vocali come best-effort quando l’app non è attiva.
Errori comuni
NODE_BACKGROUND_UNAVAILABLE: porta l’app iOS in primo piano (i comandi canvas/fotocamera/schermo lo richiedono).A2UI_HOST_NOT_CONFIGURED: il Gateway non ha annunciato un URL host canvas; controllacanvasHostin Configurazione del Gateway.- Il prompt di pairing non appare mai: esegui
openclaw devices liste approva manualmente. - La riconnessione fallisce dopo la reinstallazione: il token di pairing nel Keychain è stato cancellato; riesegui il pairing del nodo.