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.

Qui sotto trovi entrambe le metà della domanda: prima le differenze tecniche criterio per criterio, poi come si arriva alla decisione, con le otto domande che la risolvono, un esempio della raccomandazione scritta che consegniamo e le alternative (Kotlin Multiplatform, web app, low-code) che vale la pena conoscere. L'approfondimento per sviluppatori è nell'articolo React Native, Flutter o nativo: come scegliere.

La differenza di fondo è dove vive l'interfaccia: il nativo usa i componenti del sistema operativo con due codici separati, Flutter disegna ogni pixel con un proprio motore grafico a partire da un solo codice, React Native pilota da un solo codice JavaScript i componenti nativi di ciascuna piattaforma. Tutte le altre differenze — costo nel tempo, accesso all'hardware, team necessario — discendono da qui.

Letta in verticale, la tabella dice una cosa sola: il nativo compra il massimo controllo pagando due basi di codice, i due cross-platform comprano un solo codice pagando una dipendenza dal framework. Fra Flutter e React Native le differenze tecniche esistono, ma in un'app aziendale decidono meno delle competenze che dovranno mantenerla.

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.

Sono le domande con cui apriamo ogni workshop di scelta, nello stesso ordine. Rispondere da soli prima dell'incontro è il modo migliore per arrivarci preparati: nella maggior parte dei casi, alla quinta domanda la tecnologia è già decisa.

Se due risposte puntano in direzioni opposte — per esempio un dispositivo Bluetooth con un SDK solo nativo e un team interno React — è il caso in cui serve davvero un parere esterno: quasi sempre la soluzione è un'app cross-platform con un modulo nativo ben isolato, ma va verificato sul dispositivo vero.

«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.

Questo è un esempio illustrativo, non il documento di un cliente: un'app per gli agenti di commercio di un'azienda che ha già un portale ordini web in React. La struttura è quella che consegniamo davvero; la sezione che conta di più è l'ultima.

La quinta sezione è quella che distingue un parere da una raccomandazione: dichiara in anticipo a quali condizioni la scelta smette di essere giusta, così chi decide può verificarla anche dopo, senza dipendere da chi l'ha scritta.

È 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.

La domanda si pone quasi sempre a tre, ma le opzioni reali sono di più. Queste tre vanno considerate prima di scegliere, perché in alcuni casi risolvono il problema con meno codice.

Per le app interne costruite sull'ecosistema Microsoft il confronto fra low-code e sviluppo su misura è nella pagina su sviluppo su Microsoft 365 e Azure.

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.