Sviluppo cross-platform: Flutter, React Native o Kotlin Multiplatform?
Lo sviluppo cross-platform continua a rappresentare una scelta rilevante per le aziende che devono distribuire applicazioni su più piattaforme, ma nel 2026 il concetto non coincide più semplicemente con l’idea di scrivere una volta il codice e utilizzarlo senza modifiche su Android e iOS. Le principali tecnologie disponibili adottano infatti modelli differenti di condivisione, rendering, interoperabilità con le API native e gestione dell’interfaccia utente, con conseguenze dirette su performance, manutenibilità, competenze necessarie e costo complessivo del prodotto.
Il panorama tecnologico è inoltre cambiato significativamente rispetto a pochi anni fa. Xamarin, a lungo una delle piattaforme di riferimento per lo sviluppo mobile multipiattaforma in ambiente Microsoft, ha concluso ufficialmente il proprio ciclo di supporto il 1° maggio 2024 ed è stato sostituito nel percorso evolutivo Microsoft da .NET MAUI. Parallelamente, Flutter ha continuato a consolidare il proprio modello basato su UI condivisa e Dart, React Native ha completato il passaggio alla New Architecture e Kotlin Multiplatform ha raggiunto un livello di maturità maggiore anche sul fronte della condivisione dell’interfaccia, con Compose Multiplatform stabile per Android, iOS e desktop.
La scelta tra questi approcci non può quindi essere ricondotta alla sola percentuale di codice riutilizzabile. Per Tech Leader, Mobile Architect e partner IT diventa più utile valutare quale parte del sistema convenga realmente condividere, quale livello di integrazione nativa sia necessario e quale modello organizzativo sia sostenibile durante l’intero ciclo di vita dell’applicazione.
Cross-platform non significa necessariamente un’unica applicazione identica
Il principio alla base dello sviluppo cross-platform rimane la possibilità di riutilizzare una parte della codebase su piattaforme differenti, riducendo la duplicazione rispetto alla costruzione di applicazioni completamente separate in Swift per iOS e Kotlin per Android.
La quantità e il tipo di codice condiviso, tuttavia, dipendono dalla tecnologia.
Flutter tende a condividere sia logica sia interfaccia utente attraverso il proprio framework di rendering. React Native permette di costruire la UI attraverso componenti React che vengono integrati con l’ambiente nativo. Kotlin Multiplatform, invece, nasce storicamente con un approccio differente, nel quale è possibile condividere business logic, networking, data layer e altre componenti mantenendo UI native separate, anche se Compose Multiplatform consente oggi di estendere la condivisione anche all’interfaccia.
Questa distinzione è importante perché il codice condiviso non rappresenta necessariamente un obiettivo da massimizzare.
Un’applicazione potrebbe trarre valore dal condividere l’80% della business logic mantenendo il 20% dell’esperienza utente specifica per ogni piattaforma. In altri casi potrebbe essere preferibile condividere quasi completamente anche la UI.
La decisione dipende dal prodotto.
Native development e cross-platform rispondono a trade-off differenti
Lo sviluppo nativo mantiene alcuni vantaggi strutturali.
Swift e SwiftUI su iOS e Kotlin con Jetpack Compose su Android permettono di utilizzare direttamente API, componenti, lifecycle e pattern messi a disposizione dalle rispettive piattaforme.
Questo livello di integrazione può essere particolarmente importante quando l’applicazione utilizza intensamente Bluetooth, NFC, fotocamera, sensori, background processing o capability specifiche del sistema operativo.
Il costo è la presenza di due codebase e, frequentemente, di competenze differenti.
Il cross-platform riduce questa duplicazione, ma introduce un ulteriore layer tra l’applicazione e la piattaforma.
La rilevanza di questo layer varia significativamente a seconda della tecnologia utilizzata.
Per questa ragione la decisione non dovrebbe essere formulata come un confronto tra sviluppo “efficiente” e sviluppo “costoso”, ma come valutazione del rapporto tra condivisione del codice e necessità di specializzazione per piattaforma.
Flutter: una piattaforma orientata alla UI condivisa
Flutter adotta uno dei modelli di condivisione più estesi.
Il framework sviluppato da Google utilizza Dart e permette di costruire applicazioni multipiattaforma attraverso una singola struttura di widget e un rendering gestito direttamente dal framework, invece di delegare completamente la UI ai componenti nativi del sistema operativo.
La documentazione ufficiale descrive Flutter come un framework per costruire applicazioni multipiattaforma a partire da un’unica codebase, con supporto per mobile, web e desktop. A maggio 2026 la documentazione ufficiale rifletteva Flutter 3.44, mentre la roadmap pubblicata per il 2026 confermava l’attenzione del progetto verso performance, developer productivity e ampliamento dell’esperienza multipiattaforma.
Il principale effetto architetturale di questo modello è una forte uniformità dell’interfaccia.
Lo stesso component tree può essere utilizzato su Android e iOS, mentre eventuali differenze vengono gestite attraverso componenti adattivi o implementazioni specifiche.
Questo può risultare utile per prodotti nei quali la coerenza visuale tra piattaforme rappresenta un requisito importante.
Il compromesso consiste nel fatto che l’applicazione segue il modello UI di Flutter prima di quello nativo della piattaforma.
Flutter e rendering: controllare l’interfaccia invece di mapparla
Una delle differenze più significative tra Flutter e altri framework consiste nel modo in cui viene costruita l’interfaccia.
Flutter utilizza un proprio engine di rendering e non dipende esclusivamente dai controlli UI standard di Android o iOS.
Questo permette di ottenere una rappresentazione molto coerente tra dispositivi e di implementare design personalizzati senza dover riprodurre separatamente lo stesso comportamento sulle due piattaforme.
Per applicazioni caratterizzate da forte identità visuale, animazioni custom o interfacce molto specifiche, questo modello può essere vantaggioso.
Al tempo stesso, un controllo maggiore sul rendering significa che alcune evoluzioni introdotte dai sistemi operativi possono richiedere un adattamento da parte del framework prima di essere disponibili in modo pienamente integrato.
La valutazione dovrebbe quindi distinguere tra applicazioni nelle quali la UI rappresenta principalmente un linguaggio di brand e applicazioni nelle quali è importante aderire il più possibile alle convenzioni native della piattaforma.
Dart come investimento di competenza
La scelta di Flutter implica anche l’adozione di Dart.
Il linguaggio è strettamente collegato all’ecosistema Flutter e permette di sviluppare l’intera applicazione attraverso una toolchain relativamente coerente.
Questa caratteristica riduce parte della frammentazione tecnologica interna al progetto, ma può introdurre un costo organizzativo quando il team non possiede già competenze Dart.
Il confronto con React Native è significativo.
Un’organizzazione che dispone di numerosi sviluppatori JavaScript o TypeScript può trovare più semplice costruire una capability React Native rispetto a introdurre un nuovo linguaggio.
Un’organizzazione che considera invece il mobile una capability autonoma può valutare il costo di adozione di Dart come meno rilevante rispetto alla coerenza fornita dal framework.
La disponibilità delle competenze deve quindi essere considerata parte della decisione architetturale.
React Native nel 2026: la New Architecture è diventata il modello corrente
React Native utilizza JavaScript o TypeScript e porta il paradigma React nello sviluppo di applicazioni mobile.
Negli ultimi anni l’architettura del framework è stata profondamente rivista.
La cosiddetta New Architecture ha sostituito progressivamente il vecchio bridge asincrono tra JavaScript e ambiente nativo attraverso JavaScript Interface, Fabric e TurboModules, con l’obiettivo di migliorare interoperabilità, rendering e gestione delle chiamate tra i due runtime.
Dalla versione 0.76 la New Architecture è stata abilitata per impostazione predefinita e dalla 0.82 React Native opera esclusivamente su questa architettura, eliminando progressivamente il supporto al modello legacy. Nel 2026 il progetto ha continuato l’evoluzione attraverso le release 0.84, 0.85 e 0.86.
Questa evoluzione riduce la validità di alcuni giudizi storici su React Native basati sui limiti del vecchio bridge.
Il framework del 2026 presenta un modello tecnico significativamente diverso dalle sue prime generazioni.
React Native e JavaScript Interface: ridurre il costo dell’interoperabilità
La New Architecture utilizza JSI per consentire un’interazione più diretta tra JavaScript e componenti nativi.
Nel modello precedente, molte informazioni dovevano essere serializzate e trasferite attraverso un bridge asincrono. JSI consente invece a JavaScript e C++ di lavorare attraverso riferimenti diretti, riducendo il costo di alcune classi di interazione.
Questo aspetto è particolarmente importante per applicazioni che utilizzano fotocamera, elaborazione immagini, database locali o altre funzionalità nelle quali il trasferimento frequente di dati tra JavaScript e componenti nativi può avere un impatto significativo.
La presenza della New Architecture non rende però automaticamente equivalenti React Native e sviluppo nativo.
Moduli specifici possono continuare a richiedere implementazioni Swift, Objective-C, Kotlin o C++ quando l’applicazione utilizza funzionalità non esposte dalle librerie disponibili.
Il vantaggio risiede nella possibilità di utilizzare queste componenti soltanto dove sono realmente necessarie.
React Native e React: condividere competenze più che codice
Uno dei principali vantaggi organizzativi di React Native riguarda la vicinanza all’ecosistema React.
Team che utilizzano già React e TypeScript per applicazioni web possono riutilizzare una parte significativa del modello mentale, delle competenze e, in alcuni casi, della business logic.
Questo non significa che una web application React possa essere automaticamente trasformata in un’applicazione React Native.
DOM e componenti mobile appartengono a runtime differenti e la UI deve normalmente essere progettata in modo specifico.
Il vero riuso riguarda spesso soprattutto competenze, pattern, librerie di dominio e parte del tooling.
Per aziende che gestiscono contemporaneamente piattaforme web e mobile questo elemento può ridurre il costo di creazione e gestione dei team.
Expo e il ruolo dell’ecosistema React Native
Nella valutazione di React Native è inoltre necessario considerare l’ecosistema che lo circonda.
Expo, in particolare, fornisce tooling, build services, API e workflow capaci di ridurre la quantità di configurazione nativa necessaria per molti progetti.
Questo migliora la developer experience, ma introduce anche una decisione ulteriore relativa alla quantità di infrastruttura che l’organizzazione desidera delegare all’ecosistema.
La flessibilità di React Native rimane quindi contemporaneamente uno dei suoi punti di forza e uno degli elementi che richiedono maggiore governance.
Due applicazioni React Native possono essere strutturalmente molto diverse in funzione delle librerie, del navigation framework, dei servizi e dei pattern scelti dai rispettivi team.
Kotlin Multiplatform: condividere il dominio senza rinunciare necessariamente alla UI nativa
Kotlin Multiplatform adotta un modello concettualmente differente.
Il principio originario non consiste nel costruire necessariamente una sola applicazione UI, ma nel condividere le componenti per le quali la duplicazione produce poco valore.
Business logic, data access, API client, validation, caching e use case possono essere implementati in Kotlin e utilizzati sia dall’applicazione Android sia da quella iOS.
L’interfaccia può invece continuare a essere implementata attraverso Jetpack Compose su Android e SwiftUI su iOS.
Questa soluzione consente di mantenere un elevato livello di integrazione con le rispettive piattaforme preservando al tempo stesso una parte significativa della logica condivisa.
È un modello particolarmente interessante per organizzazioni che non considerano la condivisione totale della UI come requisito prioritario.
Compose Multiplatform modifica il posizionamento di Kotlin Multiplatform
Negli ultimi anni la situazione è però cambiata con la crescita di Compose Multiplatform.
Nel 2026 JetBrains considera stabile Compose Multiplatform per Android, iOS e desktop, mentre il target web basato su WebAssembly rimane in Beta. Questo significa che Kotlin Multiplatform non deve più essere valutato esclusivamente come soluzione di shared business logic: può essere utilizzato in produzione anche per condividere una parte significativa dell’interfaccia tra Android e iOS.
Compose Multiplatform 1.11, rilasciato nel maggio 2026, ha continuato a lavorare sull’esperienza iOS e sul tooling, introducendo tra le altre cose un’implementazione sperimentale di native text input basata su UIView.
Questa evoluzione rende la scelta più granulare.
Un team può utilizzare Kotlin Multiplatform soltanto per la business logic, condividere anche alcuni componenti UI oppure adottare Compose Multiplatform in misura molto più estesa.
Kotlin Multiplatform e interoperabilità con iOS
L’integrazione con l’ecosistema Apple rimane uno dei punti più importanti nella valutazione di Kotlin Multiplatform.
Il codice condiviso viene compilato in un framework utilizzabile dal progetto iOS e può essere integrato localmente o come dipendenza separata. L’applicazione mantiene quindi un progetto iOS effettivo e può continuare a utilizzare Xcode e codice Swift quando necessario.
Questo modello può essere interessante nei prodotti nei quali il team desidera preservare una forte ownership nativa dell’esperienza Apple.
D’altra parte, implica una struttura di progetto potenzialmente più articolata rispetto a un framework che cerca di centralizzare l’intera UI.
La complessità non scompare, ma viene distribuita in modo differente.
Flutter, React Native e Kotlin Multiplatform condividono codice in modi diversi
Parlare genericamente di “code sharing” può quindi essere fuorviante.
Flutter tende a massimizzare la condivisione attraverso Dart e una UI comune.
React Native condivide la struttura applicativa e l’interfaccia attraverso React, mantenendo possibilità di interazione con componenti nativi.
Kotlin Multiplatform consente invece di scegliere con maggiore granularità quali layer condividere.
La percentuale teorica di codice comune non dovrebbe essere utilizzata come unico KPI.
Un 95% di codice condiviso può sembrare preferibile a un 70%, ma se il restante 5% contiene le parti più complesse e costose dell’applicazione il vantaggio può essere inferiore alle aspettative.
È più utile misurare quali componenti richiedano manutenzione separata e quale capacità specifica serva per gestirle.
Performance: il framework non determina da solo il comportamento dell’applicazione
Le performance vengono spesso utilizzate per distinguere sviluppo nativo e cross-platform, ma un confronto astratto produce conclusioni limitate.
Flutter utilizza un proprio rendering engine, React Native opera attraverso un'architettura che integra JavaScript con componenti nativi, mentre Kotlin Multiplatform compila il codice condiviso in artefatti nativi per i target supportati.
Queste differenze influenzano il comportamento dell’applicazione, ma le performance finali dipendono anche da architettura, gestione dello stato, networking, database locale, rendering, immagini e quantità di lavoro eseguito sul main thread.
Per molte applicazioni business tradizionali, le differenze prestazionali tra framework possono essere poco significative rispetto ad altri fattori.
Per applicazioni caratterizzate da animazioni particolarmente complesse, elaborazione video, grafica avanzata o interazioni hardware intensive, la valutazione dovrebbe invece essere condotta attraverso proof of concept e benchmark sul workload reale.
Native API access: il costo emerge nei casi meno standard
Autenticazione biometrica, GPS, notifiche push e fotocamera sono supportati attraverso librerie mature in tutti i principali ecosistemi.
Le difficoltà tendono ad emergere quando il prodotto utilizza funzionalità più specifiche.
SDK proprietari, periferiche industriali, Bluetooth Low Energy avanzato, HealthKit, CarPlay o capability introdotte recentemente dai sistemi operativi possono richiedere integrazioni native.
In questi casi diventa importante valutare non soltanto se il framework permetta tecnicamente l’accesso all’API, ma anche quanta competenza nativa debba essere mantenuta all’interno del team.
Un’applicazione fortemente dipendente da API specifiche della piattaforma può ridurre progressivamente il vantaggio economico della condivisione.
UX consistency e platform conventions non sono la stessa cosa
Una UI identica su Android e iOS non è necessariamente una UI migliore.
Le due piattaforme utilizzano convenzioni differenti per navigazione, gesture, componenti, feedback e comportamento del sistema.
Flutter permette di mantenere una forte coerenza visuale, ma può anche utilizzare widget e comportamenti adattivi.
React Native tende ad avere un rapporto più diretto con il modello nativo, mentre Kotlin Multiplatform consente, quando viene utilizzato con UI separate, di mantenere completamente distinti i presentation layer.
La scelta dipende dall’identità del prodotto.
Una piattaforma B2B potrebbe privilegiare uniformità e riduzione dei costi.
Un prodotto consumer ad alta competizione potrebbe attribuire maggiore valore alla capacità di aderire perfettamente alle convenzioni specifiche di iOS e Android.
Design system: il cross-platform non elimina la necessità di progettare la UI
Un framework condiviso può semplificare l’implementazione di un design system, ma non elimina il lavoro necessario a definirlo.
Colori, typography, spacing, componenti, accessibility e interaction pattern devono comunque essere progettati.
Quando la UI viene condivisa, una parte maggiore di queste regole può essere codificata in un singolo component library.
Con UI native separate, il design system deve essere implementato su entrambe le piattaforme, anche se specifiche e token possono essere condivisi.
La scelta architetturale dovrebbe quindi essere coerente anche con il modello di design governance utilizzato dall’organizzazione.
Testing: una codebase condivisa non elimina il testing multipiattaforma
Un altro equivoco consiste nell’associare la condivisione del codice alla riduzione proporzionale dei test.
Lo stesso codice può comportarsi in modo differente su piattaforme differenti a causa di lifecycle, permission, networking, sistema operativo o hardware.
Unit test sulla logica condivisa possono naturalmente essere riutilizzati, ma UI test, integration test e test sui dispositivi devono continuare a coprire i diversi target.
Le differenze diventano ancora più rilevanti considerando la frammentazione Android e la varietà delle versioni iOS supportate.
Il cross-platform riduce parte della duplicazione del codice, non la necessità di verificare il comportamento reale su ogni piattaforma.
CI/CD mobile: la pipeline continua a essere specifica per ecosistema
Anche il processo di delivery rimane parzialmente dipendente dalle piattaforme.
Android richiede build, signing e pubblicazione attraverso Google Play, mentre iOS continua a dipendere dall’ecosistema Apple, da Xcode e da App Store Connect.
Kotlin Multiplatform richiede Xcode quando il progetto targetizza iOS, e la documentazione JetBrains indica esplicitamente la necessità di disporre dell’ambiente Apple per scrivere codice iOS-specific e distribuire l’applicazione.
Flutter e React Native automatizzano parte del processo attraverso tooling specifico, ma non eliminano i requisiti imposti dai due ecosistemi.
Il beneficio cross-platform riguarda soprattutto la codebase e il workflow di sviluppo, meno la completa unificazione del processo di distribuzione.
Dependency risk: la maturità dell’ecosistema conta quanto il framework
Le applicazioni mobile moderne dipendono frequentemente da package di terze parti.
Questo rende importante valutare non soltanto il framework, ma la qualità dell’ecosistema.
Una libreria critica dovrebbe essere valutata rispetto a manutenzione, frequenza degli aggiornamenti, compatibilità con le nuove versioni di Android e iOS e disponibilità di alternative.
Il rischio aumenta quando una funzionalità fondamentale dipende da un plugin mantenuto da pochi contributor.
Questo elemento deve essere considerato soprattutto nei progetti con ciclo di vita lungo.
Una libreria che riduce il tempo di sviluppo iniziale può trasformarsi in un costo significativo se viene abbandonata durante la vita del prodotto.
Lifecycle delle piattaforme: gli aggiornamenti mobile arrivano dall’esterno
Il mobile presenta una caratteristica che distingue questi progetti da molte applicazioni enterprise backend: una parte significativa del ciclo di aggiornamento viene determinata da Apple e Google.
Nuove versioni di iOS e Android, modifiche delle API, requisiti di privacy e aggiornamenti degli store possono richiedere interventi anche quando il prodotto non introduce nuove funzionalità.
La sostenibilità del framework dipende quindi anche dalla velocità con cui l’ecosistema recepisce queste evoluzioni.
La storia di Xamarin è un esempio utile del perché il lifecycle tecnologico faccia parte della decisione: Microsoft ha terminato il supporto di Xamarin nel 2024 e indirizza oggi i progetti esistenti verso .NET e .NET MAUI.
Una piattaforma mobile deve essere valutata non soltanto per quello che offre oggi, ma per la capacità del progetto e del vendor di mantenerla allineata agli ecosistemi sottostanti.
Cordova non è scomparso, ma occupa una posizione differente
Anche alcuni aspetti del precedente panorama cross-platform richiedono una lettura più precisa.
Apache Cordova continua a essere sviluppato: nel luglio 2026 il progetto ha pubblicato Cordova iOS 8.1.1.
Questo significa che non è corretto considerare Cordova una tecnologia formalmente dismessa.
Il suo modello, basato prevalentemente su tecnologie web eseguite all’interno di WebView con plugin per accedere alle API native, appartiene però a una generazione architetturale diversa rispetto a Flutter, React Native e Kotlin Multiplatform.
Può continuare a essere appropriato in determinati contesti, soprattutto per applicazioni web-centric o per la manutenzione di sistemi esistenti, ma non rappresenta necessariamente il riferimento principale per nuovi prodotti mobile enterprise nel 2026.
PhoneGap, invece, non rappresenta più un prodotto attivo distinto da utilizzare come alternativa contemporanea.
Xamarin e .NET MAUI: il percorso Microsoft continua con un altro stack
Per organizzazioni fortemente basate sull’ecosistema .NET, il termine del supporto Xamarin non implica l’uscita di Microsoft dal cross-platform.
.NET MAUI rappresenta l’evoluzione del modello Xamarin.Forms e permette di costruire applicazioni native multipiattaforma attraverso C# e .NET.
Microsoft fornisce inoltre percorsi ufficiali di migrazione per Xamarin.Android, Xamarin.iOS e Xamarin.Forms verso i corrispondenti modelli .NET.
In aziende che possiedono già forti competenze C# e .NET, MAUI può quindi rappresentare un’opzione da confrontare con Flutter, React Native e Kotlin Multiplatform.
La scelta deve essere letta nel contesto del portfolio tecnologico esistente, non come confronto puramente isolato tra framework mobile.
Team structure: il framework modifica il tipo di organizzazione necessaria
Uno degli elementi spesso meno considerati riguarda la struttura del team.
Con sviluppo completamente nativo possono essere necessari team Android e iOS distinti o, almeno, sviluppatori con competenze specializzate su entrambe le piattaforme.
Flutter può favorire un singolo team fortemente concentrato su Dart e sul framework.
React Native permette di costruire team partendo da competenze React e TypeScript, mantenendo una quota di expertise nativa per le integrazioni.
Kotlin Multiplatform può invece favorire un modello nel quale team Android e iOS rimangono presenti ma condividono una parte crescente del dominio e dell’infrastruttura.
Non esiste una struttura universalmente più efficiente.
Il vantaggio dipende anche dalle competenze che l’organizzazione possiede già.
Time-to-market: il vantaggio cresce quando le piattaforme condividono la roadmap
Il cross-platform tende a offrire un vantaggio maggiore quando Android e iOS devono rilasciare sostanzialmente le stesse funzionalità nello stesso periodo.
La condivisione permette di implementare la logica una volta e riduce la possibilità che le due versioni divergano.
Il beneficio diminuisce quando le roadmap sono differenti o quando le piattaforme utilizzano capability molto specifiche.
Anche la velocità iniziale deve essere distinta dal costo nel tempo.
Un framework può consentire di raggiungere rapidamente il primo rilascio, ma richiedere più lavoro negli anni successivi se l’applicazione accumula numerose integrazioni native.
Il time to market dovrebbe quindi essere valutato insieme al total cost of ownership.
Total cost of ownership: una codebase non equivale automaticamente a metà dei costi
L’idea secondo cui una codebase condivisa riduca automaticamente del 50% il costo rispetto a due applicazioni native è poco realistica.
Una parte del lavoro viene effettivamente condivisa, ma rimangono testing, store management, QA sui dispositivi, integrazioni native e gestione delle differenze di piattaforma.
Il risparmio dipende dal tipo di applicazione.
Più la business logic e l’interfaccia sono simili tra le piattaforme, maggiore tende a essere il beneficio.
Più il prodotto utilizza funzionalità specifiche del dispositivo o richiede esperienze fortemente differenziate, minore può diventare il vantaggio.
Il TCO dovrebbe quindi includere sviluppo, manutenzione, aggiornamenti, competenze, dipendenze e costi di migrazione futuri.
Quando Flutter può risultare coerente con il progetto
Flutter tende a essere particolarmente interessante quando l’obiettivo è condividere una parte molto ampia dell’interfaccia, mantenere coerenza visuale elevata e sviluppare attraverso un unico team.
Può risultare adatto a prodotti B2B, consumer application fortemente brandizzate, startup e piattaforme nelle quali velocità di sviluppo multipiattaforma rappresenta un requisito importante.
La scelta implica però l’adozione di Dart e di un rendering model specifico del framework.
Per un’organizzazione che possiede già una forte capability Flutter, questo costo può diventare marginale; per chi parte da un ecosistema completamente differente, deve essere incluso nella valutazione.
Quando React Native può risultare coerente con il progetto
React Native presenta un vantaggio significativo quando l’organizzazione dispone già di competenze React, JavaScript o TypeScript.
È particolarmente interessante quando web e mobile fanno parte dello stesso ecosistema di prodotto e si desidera ridurre la distanza tra le competenze dei rispettivi team.
La New Architecture ha inoltre modernizzato in modo sostanziale l’interazione tra JavaScript e componenti nativi, eliminando una parte dei limiti storici associati al framework.
La maggiore dipendenza dall’ecosistema di librerie richiede però una governance attenta delle dipendenze e delle scelte architetturali.
Quando Kotlin Multiplatform può risultare coerente con il progetto
Kotlin Multiplatform è particolarmente interessante quando l’organizzazione vuole condividere logica e dominio senza rinunciare necessariamente allo sviluppo nativo dell’interfaccia.
Può essere una scelta naturale per aziende che dispongono già di competenze Kotlin e applicazioni Android mature, soprattutto quando il team iOS deve mantenere pieno controllo dell’esperienza Apple.
La maturità raggiunta da Compose Multiplatform permette oggi anche strategie di condivisione della UI più estese: Android, iOS e desktop sono considerati target stabili, mentre il web basato su Wasm è ancora in Beta.
La caratteristica principale rimane quindi la gradualità: non è necessario decidere a priori di condividere tutto.
Una matrice decisionale è più utile di una classifica
Flutter, React Native e Kotlin Multiplatform non rispondono esattamente allo stesso problema.
Confrontarli attraverso una classifica unica rischia quindi di produrre una semplificazione.
Per un’applicazione con UI fortemente custom e necessità di condividere quasi tutta la codebase, Flutter può risultare particolarmente coerente.
Per un’organizzazione con forte presenza React e TypeScript, React Native può ridurre significativamente il costo di creazione delle competenze.
Per un prodotto che richiede esperienze profondamente native mantenendo però business logic comune, Kotlin Multiplatform può offrire un compromesso differente.
Se il progetto dipende fortemente da API specifiche di piattaforma, lo sviluppo nativo può continuare a rappresentare la soluzione più lineare.
Il criterio rilevante non è quindi quale framework sia migliore in assoluto, ma quale distribuzione della complessità sia più appropriata.
Cross-platform nel 2026: scegliere cosa condividere prima di scegliere il framework
Lo sviluppo cross-platform rimane una delle strategie più interessanti per ridurre la duplicazione nello sviluppo mobile, ma nel 2026 è diventato un concetto molto più articolato rispetto alla formula “un codice per tutte le piattaforme”.
Flutter, React Native e Kotlin Multiplatform rappresentano tre differenti interpretazioni della stessa esigenza.
Flutter propone un ambiente altamente integrato nel quale logica e UI possono essere ampiamente condivise.
React Native porta il modello React nel mobile mantenendo una forte capacità di interoperare con l’ecosistema nativo.
Kotlin Multiplatform permette di decidere con maggiore granularità quali livelli dell’applicazione condividere e oggi, grazie alla maturità di Compose Multiplatform, consente anche di estendere questa strategia all’interfaccia.
Parallelamente, .NET MAUI rimane un’opzione rilevante nelle organizzazioni basate sull’ecosistema Microsoft, mentre tecnologie come Apache Cordova continuano a esistere ma rispondono a un modello architetturale differente rispetto agli stack oggi più frequentemente valutati per nuovi progetti.
La scelta dovrebbe quindi partire dall’architettura del prodotto, dalle competenze esistenti, dal livello di integrazione nativa richiesto e dalla durata prevista dell’applicazione.
Per Tech Leader e partner IT la domanda più utile non è quale framework permetta di condividere la percentuale maggiore di codice, ma quale parte della codebase abbia realmente senso condividere senza ridurre qualità, governabilità ed evoluzione del prodotto.
In alcuni progetti la risposta può essere quasi tutto.
In altri può essere soltanto il dominio applicativo.
Ed è proprio questa capacità di distinguere tra condivisione utile e condivisione forzata a rendere sostenibile una strategia cross-platform nel lungo periodo.
Fonti citate:
- Apache Software Foundation. (2026). Cordova iOS 8.1.1 Released. Apache Cordova.
- Flutter. (2026). Flutter documentation. Google.
- Flutter. (2026). Flutter & Dart’s 2026 roadmap. Google.
- Flutter. (2026). What’s new in Flutter documentation. Google.
- JetBrains. (2026). Compose Multiplatform 1.11.0 Is Now Available. JetBrains.
- JetBrains. (2026). Kotlin Multiplatform: Frequently Asked Questions. JetBrains.
- JetBrains. (2026). Kotlin Multiplatform Documentation. JetBrains.
- Meta Open Source. (2026). About the New Architecture. React Native.
- Meta Open Source. (2026). React Native Blog. Meta.
- Microsoft. (2024). Ending Support in 2024. Microsoft Lifecycle.
- Microsoft. (2026). Upgrade from Xamarin to .NET. Microsoft Learn.
Autore: Martina Pegoraro
