Sviluppare un'applicazione separatamente per iOS e Android significa mantenere due implementazioni. Per anni, condividere il codice ha permesso di destinare più budget alle funzionalità e alla loro evoluzione. Con gli agenti di programmazione, parte di questo lavoro può ora costare meno. La scelta tecnica merita quindi un nuovo esame.
In Appik vediamo questo cambiamento come una possibilità in più per i progetti mobile. La nostra esperienza con lo sviluppo nativo, React Native e il web ci aiuta a confrontare le opzioni in base al prodotto, ai suoi utenti e alla sua manutenzione.
Shopify e Coinbase rivedono il loro sviluppo mobile
Il 10 settembre 2026, Shopify ha annunciato il ritorno a Swift e Kotlin. Gli agenti hanno cambiato il costo delle due implementazioni. L'azienda precisa che le sue app React Native sono veloci e che il framework ha portato i benefici attesi.
Coinbase descrive una riscrittura della sua applicazione mobile in Swift e Kotlin, assistita dall'IA, in un annuncio di lavoro ufficiale. È un progetto in corso, non l'annuncio di una migrazione già completata.
Queste decisioni pongono una domanda utile ai responsabili di prodotto. Se realizzare e far evolvere due versioni diventa meno costoso, quali vantaggi specifici di ciascuna piattaforma giustificano questo investimento per la nostra applicazione? La risposta dipende anche dai team e dalle risorse disponibili.
Perché Appik ha adottato il codice condiviso
Prima di lavorare con React Native, sviluppavamo già applicazioni native per iOS e Android. Condividere il codice rispondeva a un problema concreto. Una funzionalità disponibile su una piattaforma doveva spesso essere ricostruita sull'altra, per poi evolvere allo stesso modo.
Condividere il codice permetteva di ridurre questo lavoro ripetitivo mantenendo applicazioni con buone prestazioni. A seconda dei percorsi d'uso, alcune regole di business e alcuni componenti potevano servire anche sul web. Restavano necessari gli adattamenti alle piattaforme.
Per una PMI che deve offrire uno strumento su telefono e computer, questo approccio conserva il suo valore. Il budget può servire a migliorare il lavoro sul campo, collegare l'ERP o preparare il passaggio del prodotto a un altro team. La percentuale di codice condiviso è un mezzo. Il risultato atteso è un prodotto utilizzabile e mantenibile nel tempo.
React Native può offrire ottime prestazioni
Un'interfaccia React Native non è una pagina web inserita in un'applicazione. L'architettura di React Native collega React ai componenti e alle funzionalità native. La scelta degli strumenti di rendering e l'organizzazione dei calcoli hanno poi un peso rilevante.
Skia e Graphite per il rendering grafico
React Native Skia usa il motore grafico C++ Skia e la sua integrazione JSI. Permette di disegnare interfacce, grafici ed effetti in un canvas, senza chiedere a JavaScript di calcolare ogni pixel.
La versione 3.0.2 del repository di William Candillon, pubblicata il 3 ottobre 2026, sceglie Graphite come API predefinita. Questa evoluzione riguarda il nuovo ramo v3. Non significa che tutte le applicazioni che usano versioni precedenti abbiano cambiato motore.
Google descrive Graphite come un'architettura adatta alle API GPU moderne, che permette, tra l'altro, di preparare il lavoro grafico con recorder indipendenti. Ha un'utilità concreta per il rendering personalizzato. La sua adozione va verificata sui dispositivi previsti.
Reanimated per le interazioni e le animazioni
Reanimated usa worklet sul thread dell'interfaccia. La logica di un'animazione può così funzionare senza aspettare che il runtime JavaScript principale abbia terminato un'altra attività.
Questo offre strumenti adatti a spostare una mappa, interagire con un grafico o controllare una transizione con un gesto. La guida alle prestazioni di Reanimated ricorda però che le versioni, le proprietà animate e il numero di componenti influenzano il risultato. Una libreria non corregge automaticamente un'architettura che richiede troppe risorse.
Worklet per eseguire i calcoli nel posto giusto
React Native Worklets distingue i runtime RN, UI e Worker. Alcune funzioni JavaScript possono essere eseguite in un runtime dedicato, per esempio per elaborare dati. Questo non le trasforma in codice Swift o Kotlin.
L'obiettivo è evitare che un calcolo monopolizzi le risorse necessarie all'interazione. Anche gli scambi tra runtime hanno un costo. Spostare tutto il lavoro senza misurare sarebbe una cattiva strategia.
Legend List per le liste lunghe
Legend List v2 usa la virtualizzazione e offre il riciclo dei componenti. Durante lo scorrimento può riutilizzare gli elementi anziché ricrearli. I benchmark pubblicati confrontano soluzioni per liste React Native. Non dimostrano una superiorità rispetto a tutte le liste native.
Questi strumenti contano per un flusso di messaggi, un catalogo o un elenco di interventi. Immagini troppo pesanti o righe che ricalcolano continuamente il loro contenuto possono comunque peggiorare lo scorrimento.
React Native può fare meglio di un'implementazione nativa?
Sì, è possibile su un determinato percorso d'uso. Un rendering React Native che usa un motore C++ e la GPU può richiedere meno lavoro rispetto a un'altra implementazione della stessa schermata basata su molti componenti e aggiornamenti. È una possibilità tecnica da misurare, non un risultato che promettiamo per ogni progetto.
Anche Swift e Kotlin permettono di usare la GPU e motori specializzati. Gli strumenti citati mostrano soprattutto perché un linguaggio o un framework non basta a prevedere la fluidità.
Per confrontare due opzioni, usiamo le stesse interazioni, gli stessi contenuti e dispositivi, con versioni di produzione. Esaminiamo il tempo di risposta, i fotogrammi persi durante lo scorrimento, l'avvio, la memoria e il consumo energetico. Una schermata fluida su un telefono di fascia alta non dimostra che l'intera applicazione risponda alle esigenze sul campo.
L'IA amplia le possibilità, anche per React Native
Gli agenti possono aiutare ad adattare una funzionalità, preparare test e proporre un'implementazione su un'altra piattaforma. Nella nostra pratica sono molto utili anche su React e React Native. Non possiamo attribuire con certezza questa efficacia al volume dei loro dati di addestramento, che non conosciamo.
La questione economica riguarda il costo del prodotto nel tempo. Due applicazioni native richiedono comunque test, pubblicazioni e il monitoraggio dell'evoluzione dei sistemi operativi. Una base di codice condivisa richiede a sua volta lavoro sulle dipendenze, sulle parti native e sulle differenze tra piattaforme.
Un'organizzazione attrezzata per mantenere due versioni può trarre maggiore beneficio dall'accesso diretto agli strumenti Apple e Google. Un team che deve realizzare un prodotto per mobile e web può preferire il codice condiviso. Un'applicazione React Native esistente che risponde agli usi previsti merita una valutazione prima di finanziare una riscrittura.
Bonani e la nostra esperienza con lo sviluppo nativo
Abbiamo sviluppato Bonani, un piccolo taccuino dei compleanni, in nativo per iOS e Android. Il suo ambito limitato ci permette di esplorare questo approccio su un prodotto concreto, con dati locali, accesso ai contatti e promemoria.
Bonani usa SwiftUI e SwiftData su iOS, e Kotlin, Jetpack Compose e Room su Android. Le interfacce sono distinte, ma le regole e gli esempi di test restano comuni. Un compleanno senza anno non produce un'età. Un 29 febbraio rimane registrato come tale, anche quando il promemoria cade il 1° marzo.
Bonani non fornisce un benchmark delle prestazioni contro React Native. Il suo ambito limitato non permette di trarre conclusioni per un'applicazione destinata a una grande azienda.
In Appik vogliamo usare l'esperienza accumulata negli ultimi dieci anni per scegliere la tecnologia adatta a ogni progetto, con il supporto degli agenti. Il team mantiene la responsabilità dell'architettura, della verifica sui dispositivi e della messa in produzione.
Quale approccio per la vostra applicazione?
State preparando un'applicazione mobile o volete far evolvere un prodotto esistente? Contattate Appik per parlarne. Possiamo esaminare i vostri casi d'uso, le integrazioni e i vincoli che orientano la scelta tra sviluppo nativo, React Native e web.
Fonti e riferimenti
- Shopify · Ritorno al nativo
- Coinbase · Riscrittura mobile in corso
- React Native · Architettura
- Shopify · Skia, C++ e JSI
- React Native Skia · Graphite predefinito nella v3.0.2
- Google · Architettura grafica Graphite
- Reanimated · Animazioni e worklet
- Reanimated · Guida alle prestazioni
- React Native Worklets · Runtime RN, UI e Worker
- Legend List · Virtualizzazione, riutilizzo e benchmark v2
Swiss Made Software
