Shopify abbandona React Native per Swift e Kotlin. Il motivo non è quello che pensi.

Shopify sta abbandonando React Native. Il 10 settembre 2026, Mustafa Ali, responsabile del reparto mobile dell'azienda, ha pubblicato due post di ingegneria annunciando che le app di Shopify vengono ricostruite in Swift e Kotlin, una codebase per piattaforma, come in passato. La app Shop è già stata rilasciata come build completamente nativa. La principale app Shopify, con oltre 300 schermate, un'app per Watch e widget per la schermata di blocco, è la prossima, e dovrebbe arrivare entro la fine dell'anno.
Ciò che rende questa notizia interessante è il tempismo. A gennaio 2025 la stessa persona aveva scritto un articolo intitolato «Cinque anni di React Native in Shopify» e aveva dichiarato al settore che, se non si era provato React Native da un po', era un buon momento per riconsiderarlo. Venti mesi dopo sta migrando via. Non è un'azienda che si è innamorata di un framework per poi abbandonarlo. È un'azienda che ha visto cambiare uno dei suoi presupposti fondamentali e ha avuto il coraggio di dirlo pubblicamente.
L'assunzione riguardava i costi. Shopify è passata a React Native nel 2020 per smettere di sviluppare ogni funzionalità due volte. Ali è diretto: il framework ha fatto il suo lavoro: «Le app React Native possono essere veloci. Le nostre lo sono.» Il motivo dell'abbandono non è la performance. È che gli agenti AI di coding sono diventati abbastanza capaci da rendere meno costoso scrivere la stessa funzionalità in Swift e in Kotlin. Quando un agente può farsi carico di gran parte della seconda implementazione, il principale argomento a favore di una codebase condivisa si indebolisce, mentre i vantaggi del nativo, più vicino alla piattaforma e con meno livelli di dipendenza, rimangono esattamente dove erano.
I numeri sono reali. Ricostruita in nativo, la app Shop ha ridotto il cold start del 23% su iOS e del 50% su Android. Le sessioni con crash sono diminuite di circa dieci volte, passando da una stabilità del 99,5% al 99,95%. Le build di rilascio su Android sono diventate circa il 75% più veloci, il binario Android si è ridotto di 109 MB e il feed mantiene 120 FPS durante lo scorrimento. Sei ingegneri l'hanno portata dal proof of concept all'App Store in 12 settimane, dopo che un singolo ingegnere aveva trascorso una settimana a dimostrare che l'idea potesse funzionare del tutto.
Dove rallenteremmo il tuo percorso
Il titolo che tutti hanno condiviso è «L'AI ha ucciso il cross-platform». Il dettaglio più utile è sepolto nel resoconto della migrazione: il più grande guadagno di velocità di Shopify è venuto dalla separazione della logica di business dall'interfaccia utente, in modo da farla girare in modalità headless, gestita da un tool a riga di comando invece che da un simulatore. I loro agenti potevano così iterare in millisecondi invece di aspettare un simulatore per minuti a ogni modifica. Questo trucco non ha nulla a che fare con Swift o Kotlin. Puoi farlo in React Native oggi stesso. Sposta la tua logica in moduli semplici senza import UI, eseguili sotto Node dietro una CLI minimale, e i tuoi agenti, così come i tuoi test, ottengono lo stesso ciclo veloce. Nel nostro lavoro nativo su iOS e Android, e nelle app sanitarie e IoT che abbiamo sviluppato dove la correttezza conta più dei pixel, questa separazione è il singolo cambiamento che ripaga, che un agente tocchi mai il codice o meno.
La seconda cosa che vale la pena dire ad alta voce: Shopify aveva ancora bisogno di esperti nativi. Il loro stesso post ammette che il codice generato ha introdotto duplicazioni, deriva architetturale e problemi di performance, e che la competenza nativa è rimasta essenziale. Il costo di due codebase non è scomparso. Si è spostato dallo scrivere codice al revisionarlo. Revisionare del codice Swift che non hai scritto, e sapere se è davvero buono, è la parte costosa, e non si parallelizza come fa la generazione. Una startup di cinque persone non ha il team di revisione di Shopify. Copia la decisione senza copiare la capacità di revisione e finisci con due codebase e metà della fiducia.
Il consiglio concreto è quindi: non leggere questo come un segnale per riscrivere qualcosa. Leggilo come uno spunto per fare un esperimento. Scegli una schermata, estrai la sua logica dall'interfaccia utente in un modulo headless con i propri test, e misura quanto più velocemente si muovono sia i tuoi ingegneri che i tuoi agenti. È un giorno di refactoring, è reversibile, e ti dirà più sulla tua codebase di qualsiasi metrica di Shopify.
C'è anche una lezione di sicurezza più silenziosa nel post del 2025 di Ali. Ha segnalato che la dipendenza di React Native dalle librerie di terze parti allarga la superficie di attacco della supply chain. Ancora vero, e non esclusivo di React Native. Ogni progetto nativo si appoggia anch'esso a pacchetti. Durante i nostri engagement di pentesting, l'albero delle dipendenze è uno dei primi posti dove guardiamo, perché un pacchetto transitivo compromesso è un vettore di accesso molto più comune rispetto a un bug nel proprio codice. Meno livelli di framework possono significare meno componenti da verificare, ma solo se si tiene davvero traccia di ciò che si importa.
Niente di tutto ciò significa che React Native sia finito. Shopify è un caso molto specifico: app enormi, budget per l'inferenza AI e revisori nativi, e una migrazione verso la New Architecture imminente che ha reso la ricostruzione da zero competitiva con l'aggiornamento in-place. La maggior parte dei team non si trova in quella posizione. Lo stack giusto dipende ancora dal tuo team, dalle tue app e da quanta parte della seconda build puoi onestamente affidare a un agente.
Se la scelta tra nativo, cross-platform o un refactor headless per la tua prossima release mobile ti suona familiare, parliamone. Abbiamo rilasciato sia app native che cross-platform, e ti diremo chiaramente quando un rewrite è la scelta sbagliata.