Sviluppo
Scegliere tra React Native, Flutter e nativo senza tifoserie
React Native o Flutter è una domanda che si risolve solo guardando il contesto: chi scrive il codice, quanto l'app deve toccare il sistema operativo, chi la manterrà fra due anni. Qui trovi i criteri che usiamo per decidere, il confronto con il nativo puro e le condizioni in cui ciascuna scelta si ripaga.
React Native o Flutter: la domanda giusta parte dal contesto
React Native o Flutter è una domanda a cui non si risponde in astratto. Prima servono altre tre risposte: chi scriverà il codice, quanto l'app deve dialogare con il sistema operativo, chi la manterrà quando il progetto avrà due anni. Cambia una di queste variabili e cambia la risposta, anche a parità di funzionalità richieste.
Entrambi i framework sono maturi e reggono applicazioni in produzione. La differenza vera è architetturale. React Native costruisce l'interfaccia con componenti nativi del sistema, pilotati da codice JavaScript o TypeScript: quello che appare sullo schermo è un widget di Android o di iOS. Flutter fa l'opposto. Disegna la propria interfaccia su una superficie grafica, con codice Dart compilato in anticipo per la piattaforma di destinazione. Il sistema operativo gli presta soltanto una tela su cui disegnare.
Da questa scelta discende quasi tutto il resto: la resa visiva, il comportamento quando il sistema si aggiorna, il modo in cui si raggiungono le funzioni del dispositivo, la profondità dell'ecosistema di pacchetti. Chi imposta il confronto sulle prestazioni di solito sta guardando il dettaglio meno rilevante per il tipo di app che ha in mente.
I criteri che contano davvero nella scelta di un framework cross platform
Nella pratica la decisione si gioca su sei criteri. Li elenchiamo in ordine di peso reale, non di popolarità nelle discussioni tecniche.
Le competenze già presenti in squadra
Chi scrive React tutti i giorni parte avvantaggiato su React Native: stessa logica a componenti, stessi hook, stesso modo di gestire lo stato e le chiamate ai servizi. Dart si impara in fretta, ma conoscere un linguaggio e conoscerne le trappole sono cose diverse. Con una scadenza stretta questo criterio pesa più di qualunque considerazione architetturale.
Quanto l'app deve somigliare al sistema operativo
Alcune app devono sembrare parte del telefono: menu contestuali, gesto di ritorno, campi di testo che si comportano esattamente come l'utente si aspetta. Altre hanno un'identità visiva propria, identica su Android e iOS, e quella coerenza è un requisito. Il primo caso spinge verso React Native o il nativo, il secondo verso Flutter.
L'uso di funzioni native del dispositivo
Fotocamera con elaborazione in tempo reale, Bluetooth, sensori, notifiche articolate, widget di sistema, dati sanitari, esecuzione in background. Ogni funzione non coperta di serie diventa un ponte da scrivere in Kotlin o Swift. Il peso della decisione sta nel numero di ponti previsti, prima ancora che nella difficoltà del singolo: è lì che il vantaggio del codice unico si assottiglia.
Il riuso di codice con il web
React Native condivide con il web linguaggio, modelli mentali e buona parte della logica non grafica: validazioni, client delle API, tipi condivisi in TypeScript. Flutter compila anche per il web, ma l'output resta una tela disegnata, con i limiti noti su indicizzazione e accessibilità. Se esiste già un frontend React da cui pescare, il conto cambia parecchio.
Le librerie disponibili per le integrazioni previste
Mappe, pagamenti, abbonamenti sugli store, scanner, chat in tempo reale, analytics. Prima di scegliere prepariamo l'elenco delle integrazioni del primo anno e verifichiamo una per una che esista un pacchetto con manutenzione attiva e rilasci recenti. Un pacchetto fermo da tempo, su un framework che rilascia versioni maggiori, è un debito che si paga al primo aggiornamento obbligatorio richiesto dagli store.
Chi manterrà il codice fra due anni
Se la manutenzione passerà a un altro fornitore o verrà internalizzata, la domanda diventa quanto è facile trovare quella competenza nel bacino e nel budget disponibili. Un framework scelto benissimo e poi abbandonato da chi sa leggerlo resta una scelta sbagliata.
Dove React Native conviene nello sviluppo app multipiattaforma
React Native rende al meglio quando l'interfaccia è per gran parte standard e il valore sta nella logica applicativa: gestionali, prenotazioni, marketplace, cataloghi, app di contenuti. Liste, moduli, filtri, autenticazione, sincronizzazione. Sono schermate che il sistema operativo sa già disegnare bene e non serve reinventarle.
Il secondo scenario è quello di un prodotto che esiste già sul web in React. Client delle API, tipi TypeScript, regole di validazione, gestione degli errori e persino parte della logica di stato si spostano quasi senza attrito. Il riuso resta parziale, perché il livello grafico va comunque riscritto, e la parte che invecchia più in fretta rimane unica.
Un vantaggio operativo poco discusso riguarda le correzioni. La parte JavaScript può essere aggiornata senza attendere una nuova revisione dello store, nei limiti previsti dai regolamenti delle piattaforme. Per un'app usata da personale interno, che non tollera due settimane di attesa per un errore di calcolo, questa differenza si sente.
Il prezzo si paga sugli aggiornamenti. Le versioni maggiori toccano la parte nativa dei pacchetti, e un modulo non mantenuto blocca l'intera catena. La manutenzione di un'app React Native somiglia alla cura di un giardino: interventi regolari e distribuiti nel tempo, invece di un rilascio ogni tanto.
Dove Flutter conviene rispetto a React Native
Flutter conviene quando l'interfaccia è un requisito a sé, con un peso proprio nel progetto. Design system proprietario, animazioni continue, transizioni curate, resa identica sulle due piattaforme e anche su dispositivi Android datati: disegnando i propri widget, Flutter riduce le sorprese fra versioni del sistema e fra produttori.
Il secondo motivo è la compattezza della catena di strumenti. Un linguaggio, un compilatore, un gestore di pacchetti, un modello di rendering. Chi arriva dal backend o dal mobile nativo, senza esperienza di JavaScript, trova un percorso più lineare rispetto a un ecosistema che mescola runtime JavaScript, moduli nativi e configurazioni di build su due piattaforme.
I limiti sono speculari ai pregi. Ricreare i controlli significa curare a mano dettagli che altrove arrivano gratis: comportamento dei campi di testo, selezione, accessibilità, adattamento alle impostazioni di sistema. L'ecosistema è solido sulle integrazioni comuni e più stretto su quelle di nicchia, dove spesso tocca scrivere il canale verso il codice nativo. Anche l'ingombro di base del pacchetto parte più alto, e su alcuni mercati conta.
Quando serve il nativo puro e insistere sul cross-platform è un errore
Il cross-platform si ripaga quando si rilasciano due piattaforme. Con una sola piattaforma di destinazione, l'astrazione resta un costo senza contropartita: aggiunge un livello da aggiornare, una catena di build più fragile e una distanza in più fra il codice e le API del sistema.
Il nativo torna obbligato quando l'app vive sulle funzioni del dispositivo. Elaborazione della fotocamera, inferenza sul dispositivo, audio o video in tempo reale, lavoro in background con vincoli di batteria, widget di sistema, integrazioni con i permessi sanitari. In questi casi il framework sposta il lavoro dentro moduli ponte che qualcuno dovrà scrivere e mantenere comunque in Kotlin o Swift, senza alcun risparmio reale.
Terzo caso: quando la roadmap dipende da API di sistema appena annunciate. Chi vuole adottare una novità il giorno del rilascio non può aspettare che il framework la esponga. Quarto caso, il più ignorato: app piccola, squadra che conosce già la piattaforma. Introdurre un framework per tre schermate significa aggiungere una dipendenza a un problema che non esiste.
Va detta anche l'ipotesi opposta. A volte conviene uscire da tutti e tre i percorsi. Beachfy, la piattaforma per stabilimenti balneari che sviluppiamo, resta un'applicazione web installabile: il cliente sceglie l'ombrellone sulla piantina e ordina al bar con un codice, senza registrazione e senza scaricare nulla. Obbligare un utente stagionale a passare da uno store avrebbe aggiunto attrito e nessun beneficio.
Confronto per criterio: React Native, Flutter e nativo
Lo schema riassume le differenze che pesano nelle decisioni reali. Nessuna riga vale da sola: contano insieme, pesate sul progetto.
| Criterio | React Native | Flutter | Nativo |
|---|---|---|---|
| Competenze richieste | JavaScript o TypeScript, React | Dart e modello a widget | Kotlin e Swift, SDK di piattaforma |
| Aderenza all'aspetto del sistema | Alta, usa componenti nativi | Media, li replica | Totale |
| Identità grafica personalizzata | Buona, con lavoro aggiuntivo | Molto buona, è il punto di forza | Buona, ma da rifare due volte |
| Accesso a funzioni del dispositivo | Pacchetti o moduli nativi | Plugin o canali di piattaforma | Diretto, senza intermediari |
| Riuso con un frontend web | Alto: linguaggio e logica condivisi | Limitato alla logica scritta in Dart | Nullo |
| Tempo per la seconda piattaforma | Ridotto | Ridotto | Sostanzialmente raddoppiato |
| Correzioni rapide dopo il rilascio | Possibili sulla parte JavaScript | Richiedono una nuova build | Richiedono una nuova build |
| Rischio principale in manutenzione | Moduli nativi abbandonati | Ecosistema stretto su integrazioni di nicchia | Costo doppio di evoluzione |
| Reperibilità di chi lo manterrà | Ampia, attinge al bacino web | In crescita, più specialistica | Ampia ma più costosa |
Le prestazioni contano meno di quanto si creda
Nei confronti fra framework le prestazioni occupano lo spazio maggiore e nelle decisioni reali sono quasi sempre irrilevanti. Per un'app gestionale il collo di bottiglia sta altrove: latenza di rete, query non indicizzate, immagini servite a piena risoluzione, liste che ricaricano tutto invece di paginare, avvio a freddo appesantito da inizializzazioni sincrone. Nessuno di questi problemi si risolve cambiando framework.
Quello che gli utenti percepiscono davvero è un elenco corto: quanto ci mette l'app ad essere usabile dopo il tocco sull'icona, se lo scorrimento di una lista con foto rimane fluido su un telefono di fascia bassa, se le animazioni saltano, quanto pesa l'aggiornamento su una connessione lenta. Su questi punti la differenza la fanno le decisioni di implementazione, riga per riga, mentre l'etichetta della tecnologia resta sullo sfondo.
L'eccezione esiste ed è netta: grafica in tempo reale, elaborazione di flussi video, modelli eseguiti sul dispositivo, strumenti musicali, giochi. Lì il discorso cambia e il confronto si sposta direttamente fra Flutter e nativo. Per tutto il resto, prima di ottimizzare il framework conviene misurare la propria API.
Il caso di DietApp: perché l'abbiamo sviluppata in Android nativo
DietApp è la nostra app per piani alimentari personalizzati, pubblicata su Google Play il 26 settembre 2025 e aggiornata di recente. L'abbiamo scritta in Android nativo, lasciando da parte i framework cross platform, e i criteri elencati sopra spiegano perché.
Il primo motivo è il perimetro. Il rilascio riguardava una sola piattaforma. Con un solo bersaglio, il risparmio del codice condiviso non si materializza: resta solo il livello aggiuntivo da mantenere. Il secondo motivo sono le integrazioni previste: acquisizione della foto del piatto per la stima di calorie e macronutrienti, gestione degli abbonamenti tramite RevenueCat sulla fatturazione di Google Play, dati sanitari trattati con il consenso previsto dall'articolo 9 del GDPR. Tre punti che toccano il sistema operativo da vicino, dove i ponti li avremmo scritti comunque in Kotlin.
Il terzo motivo è meno tecnico. Il codice lo manteniamo noi, e la competenza che vogliamo tenere fresca su quel prodotto è quella della piattaforma, non quella di un livello intermedio. Vale la pena notare che il sito di DietApp è costruito in React con Vite, Tailwind e prerendering statico: le competenze JavaScript c'erano. Non sono bastate a giustificare React Native, perché il criterio delle competenze resta uno fra sei e non vince sempre.
Il conto di quella scelta è visibile e lo dichiariamo: la versione iOS è annunciata senza data e oggi comporta un nuovo progetto da avviare da capo, con la ricompilazione fuori discussione. È il prezzo che abbiamo accettato per avere un rilascio Android più diretto e un controllo pieno sulle funzioni di sistema. In un prodotto diverso abbiamo deciso in modo diverso: BarbierItalia, la piattaforma per barbieri e parrucchieri, nasce come applicazione web su Next.js con pannello mobile-first, con app dedicata al singolo salone. Stesso studio, criteri diversi, esiti diversi.
Quale framework scegliere per la tua app: la raccomandazione con le sue condizioni
Se esiste già un frontend React e l'app è fatta di elenchi, moduli, autenticazione e chiamate ai servizi, scegli React Native. Il riuso della logica e la continuità di competenze valgono più di qualunque differenza di rendering.
Se parti senza eredità JavaScript, l'interfaccia è personalizzata e deve risultare identica su Android e iOS, e prevedi animazioni e schermate su misura, scegli Flutter. Una sola catena di strumenti e un rendering prevedibile anche su dispositivi vecchi ripagano l'ecosistema più stretto.
Se rilasci su una sola piattaforma, oppure l'app vive di fotocamera, sensori, esecuzione in background, widget o dati sanitari, scegli il nativo e lascia stare il cross-platform. Se invece l'uso è occasionale, non serve accesso alle funzioni del telefono e il valore sta in una prenotazione o in una consultazione, valuta prima un'applicazione web installabile: eviti lo store e riduci l'attrito iniziale.
Se dopo questa griglia le due opzioni restano appaiate, scegli quella che sai già mantenere. Il pareggio tecnico si rompe sempre sul criterio umano, e chi paga la manutenzione se ne accorge molto prima di accorgersi del framework.
Domande frequenti su React Native, Flutter e sviluppo app multipiattaforma
Con un fornitore esterno la domanda si sposta su chi manterrà il codice dopo la consegna. Se in futuro pensi di internalizzare e assumerai profili web, React Native ti tiene vicino a un bacino di competenze più ampio. Se il prodotto ha un'identità grafica forte e nessun legame con un sito in React, Flutter riduce le parti in movimento. In entrambi i casi chiedi al fornitore l'elenco delle dipendenze di terze parti e la loro attività recente: è l'informazione più utile e la meno richiesta.
La logica applicativa sì, in larga parte. Restano fuori la configurazione dei progetti nativi, i permessi, le notifiche, gli acquisti sugli store, le regole di pubblicazione, le icone adattive e i test su dispositivi reali. Il risparmio è consistente e parziale: conviene ragionare in termini di un lavoro unico più due code di piattaforma, tenendo da parte l'idea del lavoro dimezzato.
Per un'app gestionale la domanda è quasi sempre mal posta: la differenza percepita dipende da rete, immagini, gestione delle liste e avvio a freddo, cioè da scelte di implementazione che restano identiche in entrambi i framework. Flutter ha un vantaggio strutturale sulla resa grafica continua, perché disegna la propria interfaccia. Diventa un criterio decisivo solo con animazioni complesse, grafica in tempo reale o elaborazione di flussi multimediali.
Non esiste una cifra applicabile a tutti i casi, ma esistono le variabili che la determinano: numero di schermate, quantità di logica già isolata dal livello grafico, integrazioni che vanno rifatte con SDK diversi, gestione degli abbonamenti, revisione dello store e prove sui dispositivi. La voce che pesa di più è quasi sempre data dalle integrazioni con i servizi di sistema e dal collaudo, con la riscrittura dell'interfaccia in secondo piano.
Se l'utente usa il servizio poche volte l'anno e non servono fotocamera, sensori o lavoro in background, l'applicazione web installabile evita lo store e riduce l'abbandono al primo accesso. È la strada che abbiamo seguito per la piattaforma degli stabilimenti balneari. L'app dedicata conviene quando l'uso è ricorrente, servono notifiche affidabili o funzioni del dispositivo, oppure quando la presenza sullo store ha un valore commerciale.