Scegliere tra app nativa o cross-platform significa decidere se scrivere due app separate, una per iPhone e una per Android, ciascuna nel linguaggio della propria piattaforma, oppure scrivere gran parte dell’app una volta sola e farla girare su entrambe con un framework come Flutter o React Native. Il nativo offre l’adattamento più preciso a ogni dispositivo e l’accesso più rapido alle nuove funzioni; il cross-platform offre un unico codice condiviso, una strada più veloce verso entrambi gli store e, di solito, modifiche meno costose. Questa guida definisce ogni opzione, mette a confronto cinque approcci, mostra quando conviene ciascuno e si chiude con un metodo per decidere e con l’effetto su costi e manutenzione.
Ultimo aggiornamento: 26 ottobre 2026.
Cosa significano davvero nativo e cross-platform?
Sono parole usate con poca precisione, quindi conviene fissarle prima di confrontare qualcosa. La domanda di fondo è sempre la stessa: quanta parte dell’app si scrive una volta sola e quanta per ogni piattaforma.
App native
Un’app nativa si sviluppa con gli strumenti forniti da chi gestisce ogni piattaforma: Swift e SwiftUI in Xcode per iPhone e iPad, documentati sul sito per sviluppatori di Apple, e Kotlin con Jetpack Compose in Android Studio per Android. Due codebase, due set di competenze, e ciascuna parla direttamente al proprio sistema operativo, senza livelli intermedi.
App cross-platform
Un’app cross-platform condivide gran parte del codice tra iOS e Android. I due framework di cui si sente parlare di più seguono strade diverse. Flutter, di Google, disegna da sé ogni pixel dell’interfaccia con un proprio motore di rendering ed è scritto in Dart. React Native, di Meta, si scrive in JavaScript o TypeScript e usa i veri componenti della piattaforma: un pulsante è il pulsante del sistema. Entrambi permettono di scendere al codice nativo quando una funzione lo richiede.
Le due opzioni intermedie
Kotlin Multiplatform condivide in Kotlin la logica (dati, chiamate al server, regole di business) e lascia nativa l’interfaccia su ciascun lato, oppure condivide anche quella con Compose Multiplatform. Una progressive web app (PWA) è un sito web che si installa sulla schermata Home, funziona offline e può inviare notifiche, senza passare dagli store. Entrambe rientrano nel confronto perché, per molti progetti, sono la risposta migliore.
In breve: nativo significa due app scritte per due piattaforme. Cross-platform significa un’app, un linguaggio principale e un framework che fa da traduttore. Kotlin Multiplatform condivide il motore e mantiene schermate native. Una PWA salta del tutto gli store. Nessuna è giusta per ogni progetto.
Perché questa scelta conta più della guerra tra framework?
Quasi tutti gli articoli su Flutter vs React Native sembrano una gara. Per un’azienda la domanda più utile è un’altra: cosa deve fare l’app nei primi due anni, chi la manterrà e quanto spesso dovrà cambiare. Il framework viene di conseguenza.
In Odduel, agenzia creativa e tecnologica con sedi a Barcellona e São Paulo, iniziamo ogni progetto di sviluppo app da questa domanda, non da uno stack preferito. Se stai ancora definendo la prima versione, la nostra guida allo sviluppo di un MVP spiega come ridurre il perimetro prima di scegliere la tecnologia: spesso basta questo a chiudere la questione.
App nativa o cross-platform: il confronto
La tabella mette a confronto i cinque approcci sui punti che chi compra avverte quando l’app è online. Descrive un comportamento tipico: un’app ben costruita in qualsiasi colonna può battere un’app costruita male in un’altra.
| Nativo (Swift / Kotlin) | Flutter | React Native | Kotlin Multiplatform | PWA | |
|---|---|---|---|---|---|
| Performance | Il massimo; accesso diretto al sistema | Molto vicino al nativo; motore di rendering proprio | Vicino al nativo per gran parte delle app; le animazioni pesanti richiedono cura | Interfaccia nativa, logica condivisa a velocità nativa | Buono per contenuti e moduli; limitato per la grafica pesante |
| Fedeltà dell’interfaccia | Aspetto e comportamento esatti della piattaforma | Identico al pixel su entrambe; la sensazione nativa va costruita | Usa i veri componenti della piattaforma | Schermate completamente native (o condivise con Compose) | Aspetto web; sembra un sito se non è progettato con cura |
| Funzioni del dispositivo | Tutte, dal primo giorno di ogni nuovo sistema operativo | Quasi tutte tramite plugin; le novità dopo l’aggiornamento dei plugin | Quasi tutte tramite moduli; le novità dopo l’aggiornamento dei moduli | Tutte, sul lato nativo | Limitate; variano per browser e piattaforma |
| Codice condiviso | Nessuno tra le piattaforme | Gran parte dell’app, interfaccia compresa | Gran parte dell’app; parte della logica condivisibile con una web app | Logica condivisa, interfaccia facoltativa | Un’unica codebase per ogni dispositivo e il desktop |
| Competenze del team | Due specializzazioni: iOS e Android | Dart e Flutter | JavaScript o TypeScript, vicino ai team web | Kotlin, più competenze iOS per l’interfaccia | Sviluppo web |
| Manutenzione | Due codebase da aggiornare a ogni modifica | Un’unica codebase; aggiornamenti del framework da seguire | Un’unica codebase; gli aggiornamenti delle dipendenze richiedono disciplina | Nucleo condiviso, due interfacce leggere | Un’unica codebase, nessuna revisione degli store |
| App store | Sì | Sì | Sì | Sì | No (pubblicazione facoltativa su alcuni store) |
La tabella nasconde un punto che vale la pena dire ad alta voce: la distanza tra il nativo e un buon cross-platform si è ridotta molto. Per gran parte delle app aziendali, gli utenti non sanno dire quale approccio sia stato usato. La differenza si vede ai margini: hardware nuovo, grafica pesante, integrazione profonda con il sistema e la lunga coda della manutenzione.
Quando conviene il nativo?
Il nativo è la scelta giusta quando il valore dell’app dipende dal dispositivo stesso. Sceglilo quando:
- l’app si basa su hardware nuovo o particolare: fotocamere con elaborazione personalizzata, sensori, dati sulla salute, realtà aumentata, wearable o accessori Bluetooth;
- l’app deve adottare ogni nuova funzione del sistema operativo il giorno stesso in cui esce, come widget, Live Activity o nuovi formati di schermo;
- le prestazioni sono il prodotto: audio o video in tempo reale, giochi, mappe con molta grafica;
- l’app vive soprattutto su una piattaforma, quindi la seconda codebase è piccola o non serve ancora.
I nuovi formati di dispositivo sono un buon banco di prova. Quando Apple introduce una nuova forma di schermo, le app native possono adeguarsi appena escono gli strumenti, mentre i framework seguono quando arriva il loro supporto. Abbiamo esaminato questo caso in dettaglio in cosa cambia iPhone Duo per le app.
Quando conviene Flutter?
Flutter è adatto alle app in cui l’aspetto del brand conta più delle convenzioni della piattaforma e la stessa interfaccia deve apparire identica su entrambi i telefoni. Poiché disegna da sé l’interfaccia, un design system su misura, animazioni dedicate e un’identità visiva forte si trasferiscono su ogni schermata senza adattamenti. Dallo stesso codice raggiunge anche web e desktop, un vantaggio per strumenti interni e dashboard. Il compromesso: la sensazione della piattaforma (fisica dello scorrimento, menu di sistema, dettagli di accessibilità) va verificata con attenzione su ciascun lato. La documentazione ufficiale è su flutter.dev.
Quando conviene React Native?
React Native è adatto alle aziende che hanno già sviluppatori web in JavaScript o TypeScript, o un sito in React di cui condividere logica e persone con l’app. Poiché usa i componenti della piattaforma, tende a sembrare a casa propria su ogni telefono senza lavoro in più. Gli aggiornamenti over-the-air del livello JavaScript possono accorciare la strada delle piccole correzioni, entro le regole degli store. Il compromesso è un insieme più ampio di dipendenze di terze parti da tenere aggiornate. La documentazione del progetto è su reactnative.dev.
Quando conviene Kotlin Multiplatform?
Kotlin Multiplatform è adatto ai team che vogliono schermate native ma non intendono scrivere due volte le stesse regole di business. Va bene per app con logica complessa (prezzi, sincronizzazione offline, prenotazioni, calcoli finanziari), dove un bug corretto una volta deve essere corretto ovunque, e per un’app Android esistente che si estende a iOS. L’interfaccia resta completamente nativa: per le schermate costa più di Flutter o React Native, nel complesso meno di due app native separate.
Quando basta una progressive web app?
Una PWA basta quando l’app è fatta soprattutto di contenuti, moduli, ordini o gestione dell’account, e quando il vero ostacolo è convincere le persone a installare qualcosa. Condivide un’unica codebase con il sito web, si aggiorna nel momento in cui pubblichi e non richiede la revisione degli store. I suoi limiti riguardano l’accesso alle funzioni del dispositivo, le attività in background e le notifiche push, che variano per browser e piattaforma. Molti prodotti nascono come un sito mobile ben costruito, dimostrano la loro utilità e solo dopo giustificano un’app sugli store.
Come scegliere tra nativo e cross-platform?
Questi sono i passaggi che seguiamo con i clienti. Richiedono un breve workshop, non un progetto di ricerca.
- Elenca cosa deve fare l’app nel primo rilascio e nell’anno successivo. Segna ogni funzione che tocca il dispositivo: fotocamera, posizione, notifiche, pagamenti, sensori, uso offline.
- Segna le funzioni nuove o specifiche di una piattaforma. Se diverse sono al centro del prodotto, nativo o Kotlin Multiplatform salgono in classifica.
- Decidi quanto il design deve seguire ogni piattaforma. Un’identità forte e su misura indica Flutter; una sensazione familiare della piattaforma indica React Native o il nativo.
- Guarda chi la manterrà. Un team web interno indica React Native o una PWA; un team Android indica Kotlin Multiplatform; un partner esterno deve indicare persone e piano.
- Verifica se ti servono davvero gli store. Se la risposta è «non ancora», una PWA può essere il primo passo.
- Costruisci come prova una schermata rischiosa. Un breve spike tecnico sulla funzione più difficile ti dice più di qualsiasi tabella.
- Metti per iscritto la decisione con le sue ragioni. Chi modificherà l’app dopo di te deve sapere perché è stata costruita così.
Il modo in cui gestisci lo sviluppo conta quanto lo stack. Il nostro confronto agile vs waterfall spiega perché per le app funziona di solito una fase di discovery definita seguita da brevi cicli di sviluppo.
Cosa cambia per costi e manutenzione?
Il costo segue la quantità di lavoro, e i diversi approcci spostano quel lavoro invece di eliminarlo. Non pubblichiamo fasce di prezzo, perché dipendono dal brief; a un brief breve segue un preventivo fisso. Possiamo però dire dove vanno i soldi.
La realizzazione
Due app native significano due interfacce da sviluppare, due serie di test e di solito due specialisti. Il cross-platform ne condivide gran parte, quindi lo sviluppo è di solito la voce minore, anche se le rifiniture specifiche per piattaforma e i moduli nativi richiedono comunque tempo. Kotlin Multiplatform sta nel mezzo. Una PWA è di solito lo sviluppo più contenuto, perché estende il sito web.
Gli anni dopo il lancio
È nella manutenzione che la scelta si vede davvero. Ogni nuova versione del sistema operativo, ogni cambio di policy degli store e ogni aggiornamento di sicurezza vanno assorbiti. Il nativo significa farlo due volte; il cross-platform una volta, più gli aggiornamenti del framework; una PWA significa seguire i browser. Nell’arco di vita di un’app la manutenzione spesso supera il primo sviluppo: chiedi in ogni preventivo come vengono gestiti aggiornamenti, upgrade e pubblicazioni sugli store.
Come leggere un preventivo
Un buon preventivo indica l’approccio e il motivo della scelta, separa design, sviluppo, test e pubblicazione sugli store e dice cosa copre l’assistenza dopo il lancio. Se due preventivi sono molto diversi, controlla se uno include entrambe le piattaforme, i test di accessibilità e un piano di manutenzione e l’altro no.
Le domande più comuni
Un’app nativa è sempre più veloce di una cross-platform?
Il nativo ha l’accesso più diretto al dispositivo, quindi fissa il limite massimo delle prestazioni. In pratica, le app Flutter e React Native girano in modo fluido per gran parte degli usi aziendali, come elenchi, moduli, ordini e account. La differenza emerge con grafica pesante, media in tempo reale e animazioni complesse, dove il nativo o un’ottimizzazione accurata valgono il lavoro in più.
Flutter o React Native: quale scegliere?
Scegli Flutter quando un design forte e su misura deve apparire identico su entrambe le piattaforme e lavorare in Dart non è un problema. Scegli React Native quando hai sviluppatori JavaScript o TypeScript, un sito in React con cui condividere la logica, o vuoi i componenti propri di ogni piattaforma. Entrambi sono maturi, molto diffusi e in grado di richiamare codice nativo.
Posso passare dal cross-platform al nativo in seguito?
Sì, ma di solito si tratta di riscrivere l’interfaccia più che di una migrazione. Logica di business, design, contenuti e servizi back-end si conservano; le schermate no. Un percorso comune è lanciare in cross-platform, capire cosa serve davvero agli utenti e ricostruire solo le parti che richiedono prestazioni native o accesso al dispositivo.
Apple e Google accettano le app cross-platform?
Sì. Entrambi gli store accettano app sviluppate con Flutter, React Native e Kotlin Multiplatform e le valutano con le stesse linee guida delle app native. Conta che l’app funzioni bene, rispetti le regole sulla privacy e offra un valore reale. Un semplice involucro attorno a un sito web, senza funzioni da app, ha più probabilità di essere rifiutato.
Una PWA è una vera alternativa a un’app?
Per contenuti, ordini, prenotazioni e strumenti di gestione dell’account spesso sì: si installa sulla schermata Home, funziona offline e richiede un’unica codebase. È più debole per l’accesso profondo al dispositivo, il lavoro in background e alcune notifiche, che variano per browser e piattaforma. È un primo passo solido quando non sei sicuro di aver bisogno di una presenza sugli store.
Se stai valutando un’app nativa o cross-platform per un nuovo prodotto o un rifacimento, il modo più rapido per andare avanti è un breve brief: cosa deve fare l’app, chi la manterrà e quando deve arrivare nelle mani delle persone. Ti diremo quale approccio è adatto, e perché, nell’ambito del nostro lavoro di sviluppo app. Parlaci della tua app.
