«Ci serve un'app: meglio nativa o ibrida?» È tra le prime domande che riceviamo quando un'azienda decide di portare il proprio prodotto sul telefono dei clienti. È una domanda legittima, perché dietro c'è una preoccupazione concreta: non sbagliare un investimento destinato a durare anni. La risposta onesta, però, è che così com'è la domanda è incompleta.
Il confronto, di solito, si apre e si chiude sulle prestazioni: quale delle due è più veloce, quale scorre più fluida. È il terreno su cui si sono giocati quindici anni di discussioni, ed è anche quello che oggi conta meno. Un'app nativa parla la lingua madre del dispositivo su cui vive: è scritta con gli stessi strumenti che Apple e Google costruiscono per le proprie piattaforme. Un'app cross-platform si affida invece a un interprete: un solo testo, tradotto simultaneamente in due lingue. E un interprete eccellente, oggi, esiste davvero.
Il punto è un altro. Un interprete eccellente basta per la maggior parte delle conversazioni, ma non per tutte. Soprattutto, ti lega alla sua disponibilità. Non esiste un vincitore assoluto tra le due strade: esiste la scelta giusta per quel prodotto, in quel momento, con quell'orizzonte temporale davanti. Ed è proprio l'orizzonte temporale, come vedremo, a pesare più di quanto si creda.
Native, ibride, cross-platform: tre famiglie da non confondere
Buona parte della confusione su questo tema, comprese molte statistiche che circolano, nasce dal mettere nello stesso cesto tecnologie molto diverse tra loro. Le famiglie sono tre.
Le app native sono scritte nei linguaggi e con gli strumenti della piattaforma: Swift e SwiftUI per iOS, Kotlin e Jetpack Compose per Android. Significa due sviluppi separati, uno per ciascun sistema operativo.
Le app ibride, in senso stretto, sono costruite con le tecnologie del web (le stesse dei siti internet) e girano dentro una WebView: un browser incapsulato nell'app, invisibile all'utente. È la definizione che ne danno gli stessi produttori di questi strumenti, come Cordova o Capacitor.
Il cross-platform compilato è la terza famiglia, quella di Flutter e React Native. Qui non c'è nessuna WebView: Flutter compila codice nativo e disegna l'interfaccia con un proprio motore grafico, React Native pilota direttamente i componenti del sistema. Sono soluzioni molto più solide dell'ibrido classico, e confonderle con quello è l'errore più diffuso della categoria.
Nel linguaggio corrente «ibrido» finisce per coprire entrambe le ultime due famiglie. Qui useremo i termini precisi, perché le differenze fra le tre non sono sfumature.
Le prestazioni sono ancora il vero fattore discriminante?
No, e conviene dirlo subito prima di tutto il resto.
Un confronto del 2025, condotto con codice pubblico e quindi ripetibile da chiunque su due telefoni di fascia alta, ha misurato Flutter come il più fluido nello scorrimento di elenchi lunghi: nessuno scatto, su entrambe le piattaforme, alla pari o meglio del nativo. Il luogo comune per cui «il nativo è sempre più veloce» non regge più.
Lo stesso confronto mostra però due punti in cui il nativo vince netto, e sono punti che l'utente finale percepisce. Il primo è la memoria occupata: l'app nativa ne consuma poco più di un terzo rispetto a Flutter e circa un quinto rispetto a React Native. Il secondo è il peso del pacchetto da scaricare: confrontando l'app più semplice possibile su entrambe le strade, il pacchetto nativo pesa circa un terzo di quello Flutter su Android, e su iOS il divario arriva a quaranta volte. La ragione è strutturale, e Flutter stessa la dichiara nella propria documentazione: ogni app porta con sé il proprio motore grafico, e quel motore va scaricato insieme all'app.
Detto questo, ecco la sintesi onesta: per la classica applicazione gestionale o di servizio, il tuo utente non percepirà differenze di velocità tra le due strade. Le differenze vere stanno altrove ed è lì che va spostata la decisione.
L'esperienza utente: parlare la lingua della piattaforma
Qui la differenza inizia a vedersi. Flutter, per sua stessa documentazione, non usa i componenti nativi del sistema operativo: li ridisegna tutti con il proprio motore. Il risultato è che l'app può somigliare molto a un'app iOS o Android, ma non eredita automaticamente i loro comportamenti, i loro aggiornamenti, la loro evoluzione.
C'è un esempio recente e molto istruttivo. Con iOS 26 Apple ha introdotto un nuovo linguaggio visivo per tutto il sistema, «Liquid Glass»: le app scritte con gli strumenti Apple lo hanno ricevuto al day one. Il team di Flutter, invece, ha dichiarato pubblicamente che per ora non sta realizzando i nuovi componenti e non accetta contributi in merito. Chi ha un'app Flutter, semplicemente, aspetta.
Non è un incidente: è la conseguenza di dove le piattaforme investono. Apple spinge su SwiftUI, Google si dichiara «Kotlin-first»: Jetpack Compose esiste solo per Kotlin, oltre settanta app di Google sono scritte in Kotlin, e secondo i dati di Google le app Android che usano Kotlin hanno il 20% di probabilità in meno di andare in crash. Sono gli strumenti con cui Apple e Google costruiscono le proprie piattaforme: per questo sono i primi ad allinearsi a ogni loro cambiamento.
Sull'ibrido in senso stretto il segnale è ancora più diretto: le linee guida dell'App Store chiedono esplicitamente che un'app sia qualcosa di più di «un sito web reimpacchettato». Non vietano nulla, ma dicono con chiarezza dove Apple mette l'asticella.
Infine, sia Flutter sia React Native documentano che, per le funzioni di sistema che non coprono, occorre comunque scrivere codice nativo: ciascuno dei due ha un proprio meccanismo dedicato a fare da ponte. Il cross-platform riduce il lavoro doppio; non elimina la competenza nativa, la sposta e la concentra nei punti più delicati.
Quando l'app comanda un oggetto fisico: il caso IoT
Fin qui abbiamo parlato di app che dialogano con un server. Quando invece dialogano con un oggetto fisico (un impianto domotico, un radiatore, un paio di occhiali smart) entriamo nell'Internet of Things, l'internet delle cose, o IoT: oggetti connessi che scambiano dati, e un'app che fa da interfaccia per comandarli. Qui la natura del problema cambia: all'interprete non basta più tradurre le parole, deve rispettare tempi e comportamenti che non decide lui.
Parlare con un oggetto fisico, infatti, non è una funzionalità dell'app: è un permesso che il sistema operativo concede, alle sue condizioni. Le strade sono diverse e ognuna ha le sue regole: l'oggetto può farsi trovare sulla rete Wi-Fi di casa, creare una rete propria a cui il telefono si collega direttamente, passare da un hub che fa da tramite, o (quando deve durare mesi con una batteria piccola) parlare in Bluetooth Low Energy, o BLE, la versione a basso consumo del Bluetooth. Ognuna di queste strade passa da funzioni del sistema operativo, non da componenti che si aggiungono da fuori: evolvono con lui e ne seguono le regole.
Le regole si fanno più severe proprio nello scenario tipico dell'IoT: quando l'app deve restare in ascolto in background, cioè quando non è quella in primo piano, perché l'utente sta usando un'altra applicazione o ha il telefono bloccato in tasca. In quel caso, su iOS, l'app deve dichiarare in anticipo che intende farlo, e in cambio riceve meno di quanto avrebbe in primo piano: se sta cercando dispositivi Bluetooth, le segnalazioni ripetute dello stesso dispositivo vengono accorpate, gli intervalli di ricerca si allungano, trovare l'oggetto può richiedere più tempo. Sono dettagli che non compaiono in un preventivo e decidono tutto sul campo: è la differenza tra un'app che si sincronizza da sola e una che lo fa solo quando l'utente si ricorda di aprirla.
Nel cross-platform, invece, il BLE non arriva dal sistema: arriva da librerie scritte e mantenute da terzi. Su Flutter la più diffusa è pubblicata da un editore indipendente, non da Google; su React Native da una società esterna, non da Meta. Sono progetti validi e usatissimi, ma restano esterni e sono le librerie stesse a dichiarare per iscritto cosa non coprono: alcune modalità di comunicazione, il Bluetooth nella sua versione classica, il funzionamento in background su Android, per il quale servono altri componenti di terzi ancora. Ogni limite dichiarato è un anello in più in una catena che non controlli.
Anche il primo collegamento del dispositivo, quando l'oggetto appena acquistato entra nella rete di casa, è una funzione che i due sistemi operativi si sono costruiti su misura e si tengono strette. Android ne ha una nata proprio per configurare oggetti connessi come altoparlanti e televisori; su iOS, per usare l'equivalente, non basta scriverne il codice: va richiesta come capacità dichiarata e Apple deve concederla.
L'IoT è un terreno che conosciamo da vicino. Con UNAMobile, l'app di domotica di Master, la versione precedente era generata con uno strumento cross-platform e l'abbiamo riscritta in nativo: la scelta di un'architettura nativa Android (Kotlin) e iOS (Swift) si è rivelata strategica per garantire performance elevate e l'interazione con il protocollo IoT ha richiesto una profonda comprensione dei meccanismi di comunicazione a basso livello. Con Stone Connect Wi-Fi, per i radiatori connessi di Zoppas Industries, la sfida era completare la configurazione dell'impianto anche in situazioni totalmente offline, su reti prive di accesso a internet. Con iSee Connect, gli occhiali smart per persone non vedenti e ipovedenti di iVision Tech, le sfide erano gli aggiornamenti del firmware OTA (in modalità wireless) e la stabilità del collegamento tra dispositivo e app.
Va detta anche l'altra metà. Se il tuo oggetto manda i propri dati a un servizio in cloud e l'app si limita a interrogare quello, non sei nel caso che abbiamo descritto: sei tornato a un'app che dialoga con un server, e lì il cross-platform va benissimo. Non è vero, comunque, che con il cross-platform l'IoT diretto sia impossibile: Nordic Semiconductor, per esempio, oltre alla libreria nativa pubblica anche una versione ufficiale per Flutter. La tesi difendibile non è che non si possa fare, è che ogni capacità hardware in più diventa una dipendenza in più da qualcun altro. Quando l'app è l'interfaccia del prodotto fisico che vendi, quella catena di dipendenze non è un dettaglio tecnico: è un rischio di business.
Il tempo è il vero giudice: manutenzione e longevità
Questo è il costo che non compare nel preventivo. Un framework cross-platform è un intermediario, e un intermediario può cambiare strategia o smettere di esistere: Xamarin, per anni una delle scelte più solide del settore, è stato ufficialmente dismesso da Microsoft il 1° maggio 2024, e chi lo usava ha dovuto migrare. Apache Cordova, la base storica delle app ibride, ammette pubblicamente di essere a corto di sviluppatori che contribuiscono. Già nel 2021 Microsoft l'aveva rimosso dai propri strumenti per popolarità in calo.
Anche i framework in piena salute impongono migrazioni: React Native ha rifatto le proprie fondamenta interne, e le app già scritte hanno dovuto adeguarsi. Ha risolto problemi reali, ma il conto lo paga chi ha già un'app pubblicata e funzionante. Perfino Shopify, il più convinto sostenitore di React Native, scrive che aggiornare le proprie app a ogni nuova versione del framework «richiede una quantità significativa di lavoro». Swift e Kotlin, invece, evolvono insieme alla piattaforma, senza un intermediario che decida quando è ora di rifare tutto.
Poi c'è il costo organizzativo, che è quello che si sottovaluta di più. Nel 2018 Airbnb abbandonò React Native per tornare al nativo, dichiarando di non essere riuscita a raggiungere i propri obiettivi iniziali: difficoltà nel debugging (trovare gli errori) e, soprattutto, il peso di mantenere di fatto tre piattaforme invece di due (iOS, Android e il layer React Native in mezzo). È giusto aggiungere che nello stesso resoconto Airbnb riconosce come, quando funzionava, l'esperienza fosse all'altezza delle attese. Dropbox arrivò a una conclusione simile abbandonando il proprio codice condiviso in C++: strumenti da costruirsi in casa e difficoltà ad assumere e trattenere sviluppatori, perché chi lavora sul mobile non era interessato a imparare C++. Scegliere gli strumenti standard della piattaforma è anche una scelta su quanto facilmente troverai le persone.
E allora quando è il cross-platform la scelta giusta?
Spesso. Con team piccoli, o senza specialisti mobile, il cross-platform moltiplica la forza: fu esattamente la ragione per cui Airbnb lo adottò (non aveva abbastanza sviluppatori mobile) ed è il beneficio che Shopify rivendica oggi, con team che fanno di più a parità di persone. La condivisione di codice reale, poi, è alta: Instagram ha misurato tra l'85% e il 99% di codice condiviso fra iOS e Android, a seconda della funzionalità.
Non è nemmeno una scorciatoia per progetti secondari. Shopify ha portato in React Native tutte le proprie app, non un esperimento laterale in un angolo dell'azienda, e a cinque anni di distanza ne pubblica i numeri: più del 99,9% delle sessioni senza un solo crash, tre quarti dei caricamenti sotto il mezzo secondo. Flutter, a sua volta, è particolarmente adatto quando l'interfaccia deve somigliare al tuo marchio più che alla piattaforma: se l'identità visiva è forte e deve restare identica su entrambi i sistemi, il suo motore grafico diventa un vantaggio invece che un limite.
Il dato più interessante, però, è dove si fermano loro. La stessa Shopify dichiara di non usare React Native quando servono prestazioni estreme, elaborazioni molto intensive, molte operazioni in parallelo mentre l'app non è in primo piano, supporto a dispositivi datati o SDK di basso livello (strumenti che lavorano vicino all'hardware). Aggiunge poi che la competenza nativa resta essenziale per le funzionalità hardware e per l'ottimizzazione. È la mappa dei confini disegnata da chi il cross-platform lo ama.
Le domande da farsi prima di scegliere
Come in ogni scelta tecnologica, la domanda utile non è "quale è migliore" ma "quale è giusta per noi". Nella nostra esperienza sei domande bastano a orientare la decisione.
L'app è il tuo prodotto principale o un canale di supporto? Se è il prodotto su cui costruisci il business, vale la pena investire sulla scelta che invecchia meglio; se è un canale accanto ad altri, conta più la velocità con cui lo metti in piedi.
Che orizzonte temporale ha il prodotto? Cinque o dieci anni ti espongono al rischio che il framework cambi strada, e Xamarin e Cordova insegnano. Uno o due anni, no.
Ti serve che l'app sembri e si comporti come iOS e Android, adottando le novità di sistema appena escono? O ha un'identità visiva tutta sua, identica ovunque?
Quanto pesano hardware e funzioni di sistema: sensori, fotocamera, funzionamento in background, widget, orologi? Più pesano, più codice nativo scriverai comunque.
La tua app comanda un dispositivo fisico? È l'indicatore più forte verso il nativo: qui l'app non è un canale di comunicazione, è l'interfaccia del prodotto che vendi.
Qual è il tuo budget, e su che arco di tempo lo stai guardando? Per essere presto su entrambi gli store contenendo la spesa iniziale, il cross-platform è la strada più diretta: un solo sviluppo invece di due. Se invece il conto lo fai sull'intera vita del prodotto, in quel conto entrano anche le migrazioni che il framework ti imporrà.
Se rileggi le risposte, noterai che quasi nessuna riguarda la velocità.
Quindi, per la tua app: nativa o ibrida?
Un interprete eccellente copre quasi tutte le conversazioni, e per molti progetti è esattamente la scelta giusta: più rapida, più economica, perfettamente adeguata. Ma il prodotto su cui costruisci il tuo business, quello che i tuoi clienti useranno ogni giorno per anni, merita di parlare la lingua madre dei dispositivi su cui vive.
In Moku sviluppiamo sia app native sia app cross-platform, e continueremo a farlo: non esiste un vincitore assoluto. La nostra esperienza, però, ci porta a dire che quando un prodotto deve restare in vita per anni, e seguire le piattaforme mentre cambiano, la scelta nativa invecchia meglio. Perché la differenza tra un'app nativa e un'app ibrida non si vede alla consegna: si vede quando l'app deve cambiare.
Con UNAMobile siamo stati chiamati esattamente a quel punto della storia: l'app esisteva già, generata con uno strumento cross-platform, e la decisione di riscriverla in nativo è arrivata quando il prodotto ha dovuto crescere. È il caso che riassume meglio tutto quello che abbiamo raccontato qui. La scelta giusta, per il tuo prodotto, dipende da dettagli che vale la pena guardare insieme.
