Merge non vuol dire installato: un'app senza aggiornamenti OTA

In breve. Arvo, la mia app di personal training AI, non usa expo-updates: come scrivono le note dell'esperimento del 30 settembre 2026, «A Vercel deployment cannot change installed Home code». Una correzione mergiata non è ancora nel telefono di nessuno: senza aggiornamenti OTA, il merge apre il rilascio invece di chiuderlo.

Arvo è l'app multi-agente che ho raccontato in Arvo: il personal trainer AI su architettura multi-agente. Questo articolo parla del lato distribuzione: cosa succede tra il merge e il telefono dell'utente quando non hai aggiornamenti over-the-air. Sullo stesso tema — lanciare app AI — ho già raccontato cosa chiede l'App Store alle app di salute e perché la latenza è design.

Il deploy che non raggiunge il telefono

Le note dell'esperimento cr03 del 30 settembre 2026 dicono che Arvo non usa expo-updates: «A Vercel deployment cannot change installed Home code» (docs/experiments/cr03-ready-workout-20260930.md). Il deploy aggiorna il web, non l'app installata: la schermata Home che l'utente ha nel telefono resta quella della build che ha installato, finché non arriva una nuova build dallo store e l'utente la installa.

La frase dice esattamente questo: il merge e il telefono sono due mondi separati. Sul web, mergiare e deployare è quasi la stessa cosa; sull'app installata, tra i due c'è una coda che non controlli — build, invio, revisione, aggiornamento.

Lo store ha i suoi tempi

Ad aprile 2026, Zeno colleziona tre rifiuti dell'App Store e quattro commit di fix (f74bf6b, 87d767d, eec45e4, bf59cb1); la build 1.0.0 (12) viene approvata il 13 aprile 2026 (zeno-www 53d6762). Senza aggiornamenti OTA, ogni correzione — anche la più piccola — rifà questa strada: nuova build, invio, attesa del revisore.

Il merge è l'inizio dell'attesa, non la fine del lavoro. Tra il tuo commit e il telefono dell'utente c'è una coda con i suoi tempi, e nessun deploy la salta: l'unica scorciatoia sarebbe un canale di aggiornamento che qui non c'è.

L'avvio che non puoi correggere in giornata

Il 13 aprile 2026, dai log Railway di produzione: /session/start impiegava 65-90 secondi con il timeout del client a 60 (2ca8efe); l'utente restava fermo su «Quasi pronto…» mentre il client aveva già smesso di aspettare. Nello stesso giro, 17 chiamate LLM buttate (93127d5). Con aggiornamenti OTA, il timeout o il messaggio si correggono con un aggiornamento over-the-air; senza, servono una nuova build e un nuovo giro di revisione.

La promessa vive nella build: l'onboarding offre 2-3, 5 o 10 minuti con 5 preselezionato (mobile/src/screens/OnboardingScreen.tsx:914-924); il backend ripiega su 3 (cold_start_handler.py); il rebrand dice «Il tuo coach AI, 5 min/giorno» (30e558d, 3 aprile 2026). Se la promessa è sbagliata, non la correggi dal server: la correggi nella prossima build.

La regola: mergiato non è installato

Tre fatti, una sola regola: il merge apre il rilascio, non lo chiude. La mia regola dopo questi episodi è pianificare la coda dello store e la build che la attraversa — e se una correzione deve raggiungere i telefoni in giornata, il merge da solo non basta.

Fatti e limiti

FACT. Il 30 settembre 2026 le note dell'esperimento cr03 registrano che Arvo non usa expo-updates: «A Vercel deployment cannot change installed Home code» (docs/experiments/cr03-ready-workout-20260930.md).

FACT. Ad aprile 2026 Zeno riceve tre rifiuti dell'App Store; quattro commit di fix (f74bf6b, 87d767d, eec45e4, bf59cb1); build 1.0.0 (12) approvata il 13 aprile 2026 (zeno-www 53d6762).

FACT. Il 13 aprile 2026 /session/start impiegava 65-90 secondi in produzione (log Railway) con timeout client a 60; utente fermo su «Quasi pronto…» (2ca8efe); 17 chiamate LLM buttate nello stesso giro (93127d5).

FACT. L'onboarding offre 2-3, 5 o 10 minuti con 5 preselezionato (mobile/src/screens/OnboardingScreen.tsx:914-924); il backend ripiega su 3 (cold_start_handler.py); rebrand «Il tuo coach AI, 5 min/giorno» (30e558d, 3 aprile 2026).

INTERPRETATION. Senza aggiornamenti OTA il merge apre il rilascio invece di chiuderlo: è la mia lettura dopo l'episodio Arvo del 30 settembre 2026, non un dato misurato.

INTERPRETATION. Una correzione urgente costa una nuova build più un giro di revisione: è la mia regola operativa dopo i tre rifiuti di aprile 2026 (f74bf6b, bf59cb1), in attesa di smentite.

Limiti: un solo documento per il fatto OTA (cr03, 30 settembre 2026), tre episodi da due app, non una statistica sulla distribuzione mobile. Non ho dati d'uso, retention o download: questo pezzo regge su ingegneria e store, non su risultati utenti. Non pubblico cifre di conversione da quel documento.

Domande frequenti

Cosa vuol dire che un'app è senza aggiornamenti OTA?

Che il codice nel telefono cambia solo con una nuova build dallo store: in Arvo, senza expo-updates, un deploy non tocca il codice installato (note del 30 settembre 2026). Il merge aggiorna il server, non i telefoni.

Perché il merge non basta a correggere un bug nell'app?

Perché tra il commit e il telefono c'è la coda dello store: Zeno è stato rifiutato più volte ad aprile 2026 prima dell'approvazione del 13 aprile 2026.

Quando servono davvero gli aggiornamenti OTA?

Quando la correzione non può aspettare la coda dello store: un timeout, un testo sbagliato. I casi del 13 aprile 2026 mostrano quanto costa aspettare una build.