Lo sviluppo mobile cross-platform consiste nello scrivere una sola base di codice che gira su iOS e Android, e spesso anche sul web, invece di un'app in Swift per iPhone e un'altra in Kotlin per Android. Nel 2026 non è più un compromesso riservato ai prototipi: i due framework più usati, Flutter e React Native, fanno girare app di Google, Meta, Microsoft e Shopify, e un terzo approccio, Kotlin Multiplatform, è ormai abbastanza stabile perché Google lo raccomandi ai team Android.
La vera domanda si è spostata. Non è più «cross-platform o nativo?» ma «quale cross-platform, per quale team?». Le quattro famiglie disegnano lo schermo in quattro modi diversi, e questo solo fatto decide l'aspetto, le prestazioni, il bacino di assunzione e la manutenzione a cui vi impegnate. Questa guida le mette in fila, con i numeri dove i numeri esistono, e poi vi propone un percorso di decisione.
Cosa significa cross-platform nel 2026
I dati di adozione più affidabili vengono dallo Stack Overflow Developer Survey, che chiede a circa 45.000 sviluppatori quali framework hanno usato nell'ultimo anno. I framework mobile sono una piccola fetta di tutti gli sviluppatori, ma la classifica all'interno di quella fetta è stabile.
| Framework | Quota su tutti i rispondenti | Linguaggio | Sostenuto da |
|---|---|---|---|
| Flutter | 9,4% | Dart | |
| React Native | 8,4% | JavaScript / TypeScript | Meta, con Expo come framework raccomandato |
| .NET MAUI | 3,1% | C# | Microsoft |
| Ionic | 2,5% | Tecnologie web | Ionic (OutSystems) |
| Capacitor | 1,8% | Tecnologie web | Ionic (OutSystems) |
Kotlin Multiplatform non compare in quella lista, perché il sondaggio non lo proponeva come opzione. Conta comunque: JetBrains ha rilasciato Compose Multiplatform 1.8 a maggio 2025, rendendo stabile la sua interfaccia condivisa per iOS, e Google ha appoggiato l'approccio per condividere la logica di business tra Android e iOS.
Tre cose sono cambiate dall'ultima volta che potreste averci guardato. React Native ha eliminato il vecchio bridge asincrono con la New Architecture, diventata il default per l'intero ecosistema con la versione 0.85 ad aprile 2026. Flutter ha sostituito il suo motore di rendering con Impeller. E l'approccio del web incapsulato si è diviso in due: le progressive web app, che saltano del tutto gli store, e le shell come Capacitor, che mettono un'app web in una scheda dello store. Se la vostra rosa è già ridotta ai due leader, il nostro confronto diretto React Native contro Flutter approfondisce quella scelta specifica.
Da ricordare
Cross-platform non significa più rinunciare all'aspetto e alla resa. Significa scegliere dove si ferma la condivisione: tutta l'interfaccia, solo la logica di business, o una pagina web in una shell nativa. Ogni framework è un punto su quella linea.
Quattro famiglie, quattro modi di disegnare un pixel
I nomi nascondono la differenza importante, cioè cosa diventa il vostro codice sul dispositivo.
React Native, con Expo
I vostri componenti React diventano vere viste native: un controllo UIKit su iOS, una View Android su Android. L'app appare e si comporta come la piattaforma perché usa la piattaforma. Il bacino di talenti è il più ampio dei quattro, dato che qualsiasi sviluppatore JavaScript o TypeScript può contribuire, e lo stesso team di React Native raccomanda ormai di iniziare con il framework Expo, che aggiunge navigazione, una libreria standard di API del dispositivo e build nel cloud. Spieghiamo quel livello in Cos'è Expo?.
Flutter
Flutter fa la scommessa opposta. Non usa affatto widget nativi: il suo motore Impeller disegna ogni pixel da solo, quindi l'app è identica sulle due piattaforme e un design su misura costa poco da costruire. Il prezzo è Dart, un linguaggio che il vostro team dovrà probabilmente imparare, e un'interfaccia che segue le convenzioni della piattaforma solo nella misura in cui la libreria di widget di Flutter le imita. Google dichiarava più di un milione di app rilasciate con Flutter già nel 2023.
Kotlin Multiplatform
KMP condivide le parti che gli utenti non vedono mai: rete, modelli di dati, regole di business, scritte una volta in Kotlin e compilate per entrambe le piattaforme. Le schermate restano native (SwiftUI su iOS, Jetpack Compose su Android), oppure possono essere condivise anch'esse con Compose Multiplatform, stabile su iOS da Compose Multiplatform 1.8. È il percorso naturale per un'azienda che ha già sviluppatori Android e vuole un'app iOS senza un secondo strato di logica.
Capacitor e Ionic: il web in una shell
La vostra app web esistente gira dentro una WebView, e dei plugin le espongono la fotocamera, le notifiche o il file system. È la strada più rapida da un sito web a una scheda dello store, e la più debole sulla sensazione d'uso: scorrimento, gesti e transizioni sono quelli del browser, non quelli della piattaforma. Apple inoltre rifiuta le app che sono «essenzialmente un sito web incapsulato» senza valore nativo, quindi la shell deve guadagnarsi il posto con vere funzioni del dispositivo.
| React Native + Expo | Flutter | Kotlin Multiplatform | Capacitor / Ionic | |
|---|---|---|---|---|
| Interfaccia | Widget nativi | Disegnata in proprio, identica ovunque | Nativa, o condivisa con Compose | Pagina web in una WebView |
| Cosa si condivide | Quasi tutto | Tutto | Prima la logica, interfaccia opzionale | Tutto, web compreso |
| Profilo di prestazioni | Nativo per l'interfaccia, JS per la logica | Compilato, animazioni fluide | Nativo | Limitato dal browser |
| Assunzioni | Sviluppatori web e JS | Sviluppatori Dart, bacino più piccolo | Sviluppatori Kotlin / Android | Qualsiasi sviluppatore web |
| Ideale per | App di prodotto, team che vengono dal web | App molto curate nel design e nelle animazioni | Team Android esistenti | App web esistenti che hanno bisogno di una scheda nello store |
I compromessi che decidono davvero
Costo: un solo team, ma la tassa di piattaforma resta
Il risparmio è reale ed è soprattutto organizzativo: un solo team, un solo backlog, una sola release invece di due che si allontanano l'una dall'altra. Ciò che il cross-platform non elimina è tutto quello che le piattaforme fanno pagare dal loro lato. Vi servono comunque un'iscrizione all'Apple Developer Program, un account Google Play Console, un Mac da qualche parte per firmare i build iOS (vostro o nel cloud), e passate comunque entrambe le revisioni degli store con le stesse regole di un'app nativa.
La tassa di piattaforma che non potete saltare
99 USD all'anno per Apple, 25 USD una tantum per Google, una macchina di build macOS o un servizio di build nel cloud per iOS, e un ciclo di revisione su ciascuno store. Qualunque framework scegliate, mettete queste voci a budget prima della prima riga di codice. La nostra checklist per pubblicare su App Store e Google Play le passa in rassegna una per una.
Prestazioni: bastano per i prodotti, nativo per gli estremi
Per la stragrande maggioranza delle app, form, liste, mappe, chat, pagamenti, fotocamera e notifiche, tutte e quattro le famiglie sono abbastanza veloci da non far notare la differenza agli utenti. Il nativo vince ancora agli estremi: 3D e realtà aumentata, elaborazione audio e video in tempo reale, widget della schermata Home e integrazioni profonde con il sistema operativo, e giochi. Se il vostro prodotto è uno di questi, la decisione è già presa.
Manutenzione: l'aggiornamento annuale che nessuno pianifica
Ogni settembre Apple e Google rilasciano nuovi sistemi operativi, e ogni framework pubblica aggiornamenti per stare al passo. Expo pubblica tre versioni dell'SDK all'anno, Flutter rilascia ogni trimestre, Kotlin Multiplatform segue il ritmo di Kotlin, e un'app web incapsulata si aggiorna con il web. Niente di tutto questo è difficile se restate al passo; tutto diventa penoso se lasciate passare due anni. Mettete un aggiornamento a trimestre nella roadmap e il costo resta contenuto.
Come scegliere: una guida alla decisione
Partite dal team che avete, non dai benchmark. Il framework per cui un team può assumere e che può mantenere batte quello che vince un test sintetico.
Il vostro team scrive JavaScript
React Native con Expo. I vostri sviluppatori web sono produttivi dal primo giorno, l'interfaccia è davvero nativa, ed Expo gestisce build e invio agli store dal cloud.
Avete sviluppatori Android
Kotlin Multiplatform. Condividete la logica che avete già scritto, mantenete schermate native e aggiungete Compose Multiplatform per l'interfaccia condivisa quando ha senso.
Design e animazione vengono prima di tutto
Flutter. Un'interfaccia su misura, identica al pixel sulle due piattaforme, al prezzo di imparare Dart e di vivere leggermente fuori dalle convenzioni di piattaforma.
Avete già un'app web
Una progressive web app se potete fare a meno di una scheda nello store, Capacitor se ve ne serve una. Aggiungete vere funzioni del dispositivo perché la revisione dello store abbia qualcosa da approvare.
Poi passate una breve checklist prima di impegnarvi:
- 1. Elencate le funzioni del dispositivo che vi servono. Fotocamera, notifiche push, posizione in background, Bluetooth, pagamenti. Verificate che ognuna abbia un modulo mantenuto nel framework che state valutando.
- 2. Contate le persone che lo manterranno. Una persona può tenere in vita un'app Expo; una configurazione KMP con schermate native richiede almeno una mano iOS e una Android.
- 3. Stimate la durata di vita. Un'app per una campagna di tre mesi e un prodotto di cinque anni non meritano la stessa architettura.
- 4. Fate un prototipo in una settimana. Costruite le due schermate più difficili con il vostro candidato principale e mettetele su un telefono vero. A quel punto la maggior parte dei dubbi sparisce.
- 5. Pianificate la pipeline di rilascio. Firma, build nel cloud, TestFlight e tracce di test interno. Decidetelo ora, non la settimana del lancio.
E se non avete nessun team mobile
Il caso più comune per un fondatore o una piccola impresa non è «quale framework?» ma «chi lo scriverà?». Un AI app builder risponde a quella domanda con un vero stack cross-platform invece di un template. Su Cadrant, un progetto mobile nativo è un'applicazione Expo e React Native: descrivete l'app in linguaggio naturale, la vedete in anteprima nella cornice di un telefono, la testate sul vostro dispositivo con Expo Go e poi la pubblicate sull'App Store tramite i vostri account Expo e Apple. Se una scheda nello store non serve, lo stesso builder produce invece una progressive web app o un'app WebView. La pagina del creatore di app mobile descrive le tre opzioni.
Consiglio pratico
Qualunque cosa scegliate, portate l'app su un telefono vero nella prima settimana. I simulatori nascondono le tre cose che decidono se gli utenti tengono un'app: latenza al tocco, sensazione di scorrimento e consumo di batteria. Un framework che risulta fluido su un Android di due anni fa lo sarà ovunque.
Il cross-platform nel 2026 è una famiglia di scelte mature, non una scorciatoia. Scegliete quella che il vostro team può far propria, mettete a budget i costi di piattaforma che nessun framework elimina e segnate l'aggiornamento annuale sul calendario. Il resto è costruire il prodotto.