Sviluppare una volta e pubblicare su iOS e Android è la promessa di ogni framework cross-platform. Flutter, il progetto open source di Google basato sul linguaggio Dart, è quello che oggi la mantiene meglio: non traduce il codice in componenti di sistema, ma disegna direttamente l’interfaccia con un proprio motore grafico. Il risultato è un’app unica, fluida e identica su ogni dispositivo. Vediamo come funziona davvero, quando conviene e quando invece è meglio il nativo.
Come funziona Flutter
Flutter si compone di tre elementi: il linguaggio Dart, una libreria di widget e un motore di rendering.
- Dart compilato in codice macchina. In produzione il codice viene compilato AOT (ahead-of-time) in istruzioni ARM o x64: non c’è un interprete o un “ponte” JavaScript a runtime. In sviluppo si usa la compilazione JIT, che abilita l’hot reload.
- Tutto è un widget. L’interfaccia si descrive in modo dichiarativo componendo widget: si dichiara come deve apparire la UI per un certo stato e il framework si occupa di aggiornarla. Sono disponibili sia i widget Material (stile Android) sia i Cupertino (stile iOS).
- Impeller disegna ogni pixel. Il motore grafico attuale precompila gli shader in fase di build, eliminando gli scatti che in passato comparivano alla prima esecuzione di un’animazione. Le app girano a 60 fps, e a 120 fps sui dispositivi che li supportano.
Poiché Flutter disegna la UI invece di usare i componenti di sistema, l’app appare identica su ogni telefono, indipendentemente da versione del sistema operativo e personalizzazioni del produttore: un vantaggio enorme quando il design deve essere rispettato al pixel.
I vantaggi concreti
Un solo codice, due piattaforme (e oltre)
Logica applicativa, interfaccia, validazioni e gestione degli errori si scrivono una volta sola. Restano specifici per piattaforma solo i permessi, le notifiche push e le integrazioni di sistema: in pratica il 90% del lavoro è condiviso. Lo stesso progetto può inoltre generare build per web e desktop.
Sviluppo più rapido grazie all’hot reload
Ogni modifica al codice si vede sul dispositivo in meno di un secondo, senza perdere lo stato dell’applicazione. Su un progetto reale significa cicli di revisione molto più brevi: si può discutere una schermata con il cliente e modificarla mentre la si guarda insieme.
Prestazioni vicine al nativo
Niente ponte JavaScript, niente serializzazione dei messaggi tra due mondi: il codice compilato parla direttamente con il motore grafico. Scroll di liste lunghe, animazioni e transizioni restano fluidi anche su dispositivi di fascia media.
Un design system coerente
Colori, tipografia, spaziature e componenti si definiscono una volta nel theme e valgono per tutta l’app. È il motivo per cui un layout Figma si traduce in Flutter con grande fedeltà.
Manutenzione dimezzata
Una correzione o una nuova funzionalità si scrive e si testa una volta, poi va in entrambi gli store. Nel tempo è il vantaggio economico più rilevante, spesso più della fase di sviluppo iniziale.
Flutter, nativo o React Native?
| Aspetto | Flutter | Nativo (Swift / Kotlin) | React Native |
|---|---|---|---|
| Codice condiviso | ~90% | 0% (due progetti) | ~85% |
| Rendering | Motore proprio (Impeller) | Componenti di sistema | Componenti di sistema via JSI |
| Prestazioni UI | Molto alte | Massime | Alte, con qualche limite sulle animazioni complesse |
| Coerenza grafica | Identica ovunque | Segue lo stile del sistema | Segue lo stile del sistema |
| Accesso alle novità del sistema | Dopo l’aggiornamento dei pacchetti | Immediato | Dopo l’aggiornamento dei pacchetti |
| Peso base dell’app | Qualche MB in più | Minimo | Qualche MB in più |
| Costo indicativo | Uno sviluppo | Due sviluppi | Uno sviluppo |
Non esiste una scelta giusta in assoluto: esiste quella giusta per il vostro progetto, ed è il primo tema che affrontiamo insieme in fase di analisi.
Quando Flutter è la scelta giusta
- Serve l’app su entrambi gli store con budget e tempi da singolo progetto.
- Il design è curato e deve restare identico su iPhone e Android.
- Il cuore dell’app sono dati e processi: gestionali, prenotazioni, ordini, presenze, assistenza sul campo.
- Si parte da un MVP da validare in fretta e far evolvere senza riscrivere tutto.
- Il team che manterrà l’app è piccolo: una sola base di codice da conoscere.
È il caso di Easy Yacht Service, l’app per la manutenzione nautica che abbiamo sviluppato in Flutter per iOS e Android, e di Badge Lavoro, dove l’app mobile lavora insieme a una web app di back office.
Quando conviene il nativo
Lo diciamo apertamente, perché consigliare la tecnologia sbagliata costa a tutti:
- Realtà aumentata evoluta con ARKit o ARCore, o grafica 3D intensiva (in quel caso si valutano anche motori come Unity).
- Estensioni di sistema: widget della schermata home complessi, complicazioni per smartwatch, App Clip e Instant App.
- App che devono pesare pochissimo o girare su hardware molto datato.
- Uso immediato di API rilasciate ieri dal sistema operativo, prima che i pacchetti Flutter le supportino.
In diversi progetti la risposta migliore è mista: app in Flutter con moduli nativi scritti su misura e collegati tramite platform channel o FFI.
Come sviluppiamo un’app in Flutter
- Architettura e stato. Separiamo interfaccia, logica e dati e adottiamo una gestione dello stato adeguata alla complessità (Riverpod o Bloc), così l’app resta leggibile anche dopo due anni di evoluzioni.
- Dati e sincronizzazione. API REST o GraphQL, cache locale con SQLite/Drift e strategia offline-first quando l’app deve funzionare anche senza rete, come nell’assistenza sul campo.
- Test automatici. Unit test sulla logica, widget test sulle schermate e test di integrazione sui flussi principali: login, pagamento, invio di un ordine.
- CI/CD. Build automatiche a ogni modifica e distribuzione ai tester tramite TestFlight e canali interni del Play Console, così il cliente prova l’app mentre la stiamo costruendo.
- Pubblicazione e dopo. Ci occupiamo di schede store, privacy label, versioni e monitoraggio dei crash; poi restiamo per aggiornamenti e nuove funzionalità.
Quando serve un back office o un’API su misura li sviluppiamo noi: trovi i dettagli nelle pagine sviluppo app e sviluppo web. Se invece l’app deve integrare funzioni intelligenti — ricerca semantica, classificazione di documenti, assistenti — le realizziamo con il servizio di consulenza AI.
Domande frequenti
Nella stragrande maggioranza dei casi sì: il codice Dart viene compilato in linguaggio macchina (AOT) e l’interfaccia è disegnata dal motore grafico Impeller, che precompila gli shader ed evita gli scatti alla prima animazione. La differenza con il nativo si nota solo in scenari estremi, come grafica 3D intensiva o elaborazione video in tempo reale.
Sì. Dallo stesso codice si generano il pacchetto iOS (IPA) e quello Android (AAB). Restano separati solo gli adempimenti degli store: account sviluppatore, certificati di firma, schede prodotto e revisione di Apple.
Flutter compila anche per il web, ma per siti e piattaforme indicizzabili restiamo su tecnologie web classiche, che offrono SEO e tempi di caricamento migliori. Usiamo Flutter web solo per gestionali e aree riservate, dove l’indicizzazione non serve.
Tramite API REST o GraphQL verso il vostro gestionale, CRM o e-commerce. Quando l’API non esiste, la sviluppiamo noi (spesso in Laravel) insieme all’app, gestendo autenticazione, permessi e sincronizzazione offline.
Va aggiornata la toolchain, ricompilata l’app e verificati i pacchetti di terze parti. È un’attività di manutenzione pianificabile: la prevediamo un paio di volte l’anno, oltre agli aggiornamenti di sicurezza.
Un’app semplice è pronta in 6–8 settimane; per soluzioni con back office, integrazioni e ruoli utente si va da 3 a 5 mesi. Rispetto a due sviluppi nativi separati, il risparmio tipico è del 30–40% sul lavoro di sviluppo, perché la logica applicativa si scrive una volta sola.
Vuoi capire se Flutter è la scelta giusta per la tua app? Raccontaci il progetto: in una call di 30 minuti ti diciamo quale tecnologia conviene, con tempi e costi realistici. Nessun impegno e nessuna call inutile.