React Native, Flutter o sviluppo nativo: come scegliere la tecnologia per un'app aziendale

Si sceglie lo sviluppo nativo (Swift per iOS, Kotlin per Android) quando l'app deve usare funzioni del sistema operativo appena uscite o molto specifiche, quando le due piattaforme devono comportarsi in modo diverso o quando le prestazioni sul dispositivo sono il cuore del prodotto. Si sceglie Flutter quando serve un'unica base di codice con controllo totale sull'interfaccia, tipicamente nelle app operative e in quelle che dialogano con dispositivi. Si sceglie React Native quando l'azienda ha già un prodotto o un team React, perché competenze, librerie e convenzioni sono le stesse. Nella maggior parte dei progetti aziendali la decisione è già contenuta nei requisiti: il tipo di app determina la tecnologia molto più delle preferenze di chi la sviluppa.

C'è però una cosa da dire prima di ogni confronto: la scelta fra le tre incide meno, sul destino del progetto, di quanto incidano l'analisi del processo e l'integrazione con i sistemi già in uso. Nella nostra esperienza le app aziendali che falliscono non falliscono per il linguaggio: falliscono perché nessuno aveva guardato davvero come esce un ordine dal gestionale. Codebaker è una software house di Bologna fondata nel 2019 che sviluppa in tutte e tre le tecnologie, e per questo non ha un interesse a spingerne una.

Se cerchi il confronto tecnico riga per riga — linguaggi, rendering, ecosistema, prestazioni — è nell'articolo React Native, Flutter o nativo: come scegliere. Questa pagina risponde all'altra metà della domanda: come si arriva alla decisione, e chi vi aiuta a prenderla.

Il modo più rapido per orientarsi non è confrontare i linguaggi ma riconoscere di quale tipo di app si sta parlando. Questa tabella copre i casi che incontriamo più spesso nelle aziende manifatturiere, nella distribuzione e nei servizi.

Due avvertenze. La prima: quando la tabella dice «cross-platform», la scelta fra Flutter e React Native si decide quasi sempre sulle competenze già presenti, non su un confronto tecnico — entrambi reggono benissimo un'app aziendale. La seconda: se più righe della tabella descrivono il vostro caso e indicano tecnologie diverse, non avete un problema di tecnologia, avete un'app che sta cercando di essere due app.

«Chi mi aiuta a scegliere» è la parte della domanda che riceve meno risposte utili. Questo è il percorso che proponiamo, e che si chiude con un documento, non con un'opinione detta a voce.

L'analisi preliminare e il preventivo sono gratuiti. Se dal confronto emerge che l'app non serve — capita, e più spesso di quanto si pensi, quando una web app o un'estensione del gestionale risolvono lo stesso problema — lo diciamo.

È la sezione che manca in quasi tutti i confronti, ed è quella che fa risparmiare più soldi. Queste voci pesano sul budget e sul rischio di progetto allo stesso modo in tutti e tre gli scenari: se la discussione tecnologica le sta rimandando, sta facendo un danno.

• L'analisi del processo che l'app deve supportare. Un'app che digitalizza un flusso mal capito è un flusso mal capito con un'icona.
• Il backend e le API: modello dati, regole di business, autenticazione, prestazioni sotto carico.
• L'integrazione con i sistemi esistenti, che nei progetti aziendali è quasi sempre la voce più costosa e più rischiosa dell'intero lavoro.
• Il comportamento offline e la gestione degli errori: che cosa succede quando la rete non c'è, quando il gestionale non risponde, quando due persone modificano lo stesso dato.
• Le politiche degli store e i tempi di approvazione, identici per tutte e tre le tecnologie.
• La formazione di chi userà l'app e l'accompagnamento nelle prime settimane, che decidono l'adozione molto più dell'interfaccia.
• La manutenzione evolutiva: chi la farà, con quali tempi di risposta e con quale accesso al codice.

La conseguenza pratica: valutate un fornitore su come parla di queste sette voci, non su quale tecnologia propone. Il criterio completo è nella pagina su come scegliere il partner tecnologico.

Le due scelte sono opposte e nessuna delle due è «la» risposta: in un caso il requisito dominante era il dialogo con l'hardware, nell'altro l'uso quotidiano su grandi numeri e l'aggancio a un gestionale legacy. È esattamente il motivo per cui la domanda giusta non è «quale tecnologia è la migliore» ma «quale requisito comanda, nel mio caso». Le altre esperienze sono nel portfolio.

È la domanda che riduce di più l'ansia della scelta, perché la risposta dipende dall'architettura molto più che dalla tecnologia. Se l'app è costruita con le API prima e l'interfaccia poi — backend come servizio a sé, con contratti dati documentati — cambiare tecnologia significa riscrivere il livello di presentazione: il modello dati, le regole di business, le integrazioni con il gestionale e l'infrastruttura restano dove sono. Se invece la logica è stata scritta dentro le schermate, qualunque cambio è una riscrittura totale.

È per questo che, qualunque sia l'esito della scelta, lavoriamo sempre con la stessa architettura: la stessa che permette di aggiungere in seguito una versione web, un secondo canale o un'integrazione con un nuovo sistema senza ripartire da zero. L'approccio è descritto nell'articolo una specifica unica per backend, React, Flutter e AI, e le competenze specifiche nelle pagine su sviluppo app Flutter, app native iOS, app native Android e sviluppo React.