.NET MAUI: one C# codebase for cross-platform desktop and mobile, when it really pays off

Hai un'applicazione gestionale che gira su Windows, scritta in C# con tutta la logica di business che funziona bene da anni. Poi arriva la richiesta che prima o poi arriva a tutti: "Ci serve anche su tablet. E sul telefono dei venditori. Possibilmente anche sui Mac dell'ufficio marketing". A quel punto la domanda non è più tecnica, è strategica. Riscrivi tutto tre volte, una per ogni piattaforma, con tre team e tre linguaggi diversi? Oppure esiste un modo per riusare il C# che hai già scritto e raggiungere tutti quei dispositivi con una sola codebase?

Questa è esattamente la domanda a cui risponde .NET MAUI. È il framework con cui Microsoft permette a un team .NET di costruire app native per desktop e mobile multipiattaforma partendo da un unico progetto C#. Non un wrapper web travestito da app, non un compromesso a metà, ma binari nativi veri per Windows, macOS, iOS e Android, con accesso completo alle API del dispositivo e prestazioni adeguate alla maggior parte degli scenari aziendali.

In questo articolo non ti vendo la favola del "scrivi una volta, gira ovunque" senza riserve, perché non sarebbe onesto. Ti spiego cos'è davvero .NET MAUI, come è fatta la sua architettura, cosa significa in pratica condividere una codebase, cos'è Blazor Hybrid e perché cambia le carte in tavola, e soprattutto quando MAUI conviene rispetto allo sviluppo nativo o a Flutter, e quando invece non è la scelta giusta. Lo faccio dal punto di vista di chi vive l'ecosistema .NET tutti i giorni e ha visto progetti MAUI andare bene e altri andare male, per ragioni precise.

Cos'è .NET MAUI e perché Microsoft lo ha creato

.NET MAUI sta per Multi-platform App UI. È il framework ufficiale di Microsoft per costruire, da una sola codebase C# e XAML, applicazioni native per Windows, macOS, iOS e Android. "Native" è la parola chiave: MAUI non incapsula una pagina web in un contenitore, ma compila la tua app verso i controlli reali di ogni sistema operativo. Un pulsante MAUI su iOS diventa un pulsante UIKit, su Android un widget Material, su Windows un controllo WinUI.

Il motivo per cui esiste è la frammentazione che ogni team prodotto conosce bene. Senza un framework multipiattaforma, raggiungere desktop e mobile significa mantenere codebase separate: Swift/SwiftUI per Apple, Kotlin per Android, WPF o WinUI per Windows. Tre o quattro mondi diversi, tre team o un team che salta continuamente tra linguaggi e tooling differenti, e ogni feature da implementare e testare tre volte. Il costo non è solo lo sviluppo iniziale, è la manutenzione che si moltiplica per il numero di piattaforme per sempre.

MAUI nasce per riportare tutto questo dentro un solo linguaggio e un solo runtime. La logica di business, l'accesso ai dati, le chiamate alle API, la validazione, i modelli: tutto questo si scrive una volta in C# e si condivide al 100% tra le piattaforme. La parte di interfaccia si condivide in larga misura, con la possibilità di personalizzare i dettagli per piattaforma dove serve. Per un'azienda con un team .NET già formato, questo significa capitalizzare le competenze esistenti invece di assumere specialisti iOS e Android.

Da Xamarin a MAUI: cosa è cambiato davvero

MAUI non è un progetto nato dal nulla. È l'evoluzione diretta di Xamarin.Forms, la tecnologia con cui Microsoft offriva sviluppo multipiattaforma .NET prima del 2022. Chi ha lavorato con Xamarin riconoscera' molti concetti, ma le differenze architetturali sono sostanziali e tutte nella direzione giusta.

La prima differenza è il Single Project. In Xamarin avevi un progetto condiviso più un progetto per ogni piattaforma, con configurazioni, risorse e file di avvio duplicati. In MAUI c'è un unico progetto che dichiara i target tramite la proprietà TargetFrameworks, gestisce risorse, icone e splash screen in modo unificato, e ti permette di mettere codice specifico per piattaforma in cartelle dedicate quando serve. La seconda differenza è il runtime: MAUI gira sul .NET unificato (.NET 8 e successivi), lo stesso runtime di ASP.NET Core e delle console app, invece che su un Mono separato. La terza, più tecnica ma importante, è il passaggio dai Renderer agli Handler, di cui parlo nella sezione sull'architettura.

Il punto pratico che conta per le decisioni: Xamarin è uscito dal supporto a maggio 2024. Non riceve più aggiornamenti né patch di sicurezza. Qualsiasi nuovo progetto multipiattaforma .NET deve partire da MAUI, e i progetti Xamarin esistenti vanno pianificati per la migrazione. Se vuoi un quadro completo prima di scendere nel dettaglio, abbiamo una pagina dedicata che spiega cos'è .NET MAUI in modo introduttivo.

Come funziona l'architettura di .NET MAUI

Per usare bene MAUI, e per spiegare a un decisore tecnico perché è una scelta solida, bisogna capire come è fatto sotto il cofano. Non serve conoscere ogni dettaglio interno, ma i tre pilastri architetturali fanno la differenza tra un'app che funziona e una che combatte continuamente con il framework.

Single Project e codice condiviso

Il cuore di MAUI è il progetto singolo che produce più binari. Nel file di progetto dichiari i target che vuoi raggiungere, per esempio Android, iOS, Windows e macOS via Mac Catalyst. La compilazione genera un artefatto nativo per ciascuno. La logica condivisa vive in classi C# normali, identiche a quelle che scriveresti in qualsiasi altro progetto .NET. Quando ti serve qualcosa di specifico per una piattaforma, MAUI offre la compilazione condizionale e una struttura di cartelle (Platforms/Android, Platforms/iOS e così via) dove il codice viene incluso solo per il target corrispondente.

Gli Handler: il ponte verso i controlli nativi

Qui sta l'innovazione tecnica più rilevante rispetto a Xamarin. Ogni controllo MAUI (un Entry, un Button, una CollectionView) è un'astrazione che, a runtime, viene mappata sul controllo nativo della piattaforma tramite un componente chiamato Handler. Gli Handler hanno sostituito i vecchi Renderer di Xamarin, che erano pesanti e fortemente accoppiati. La nuova architettura è basata su un'interfaccia leggera e su un sistema di mapping che disaccoppia il controllo virtuale dalla sua rappresentazione nativa.

Il vantaggio concreto è duplice: prestazioni migliori, perché c'è meno overhead tra il tuo controllo e quello nativo, e personalizzazione più semplice. Se vuoi modificare il comportamento di tutti gli Entry dell'app su Android, intervieni sul mapper dell'Handler con poche righe, senza dover ereditare classi complesse. È una di quelle decisioni di design che si apprezzano dopo qualche settimana di lavoro reale.

// Personalizza l'aspetto di tutti gli Entry su tutte le piattaforme
Microsoft.Maui.Handlers.EntryHandler.Mapper.AppendToMapping("NoBorder", (handler, view) =>
{
#if ANDROID
    handler.PlatformView.Background = null;
#endif
});

MVVM e data binding come modello di riferimento

MAUI adotta XAML per definire le interfacce e il pattern MVVM (Model-View-ViewModel) come modo idiomatico di separare la logica di presentazione dalla UI. Il data binding collega le proprietà dei ViewModel ai controlli XAML in modo dichiarativo, e la libreria CommunityToolkit.Mvvm riduce drasticamente il codice ripetitivo con i source generator: dichiari una proprietà osservabile o un comando con un attributo, e il codice di supporto viene generato in compilazione. Chi arriva da WPF si trovera' immediatamente a casa, perché XAML, binding e MVVM sono gli stessi concetti.

Una sola codebase per Windows, macOS, iOS e Android: cosa significa davvero

La promessa di "una sola codebase" è seducente ma va capita con precisione, perché la verità è più sfumata dello slogan. Quello che condividi al 100% e quello che condividi parzialmente sono cose diverse, e confonderle porta a stime sbagliate e delusioni.

La logica di business si condivide integralmente. I servizi, i repository, i modelli di dominio, la validazione, le chiamate HTTP alle tue API, la serializzazione, la gestione dello stato: tutto questo è C# puro che gira identico su ogni piattaforma. Se hai già una libreria di dominio in un progetto .NET Standard o .NET, la riusi tale e quale. Questa è la parte dove il risparmio è reale e immediato, e spesso è anche la parte più costosa da scrivere e testare. Condividerla una volta sola è il vero valore economico di MAUI.

L'interfaccia si condivide in larga misura, non sempre al 100%. Una pagina XAML con liste, form, navigazione e layout responsivo funziona su tutte le piattaforme con lo stesso codice. Ma ci sono dettagli che cambiano: una schermata desktop ha senso a tre colonne, su un telefono diventa a una colonna; le convenzioni di navigazione di iOS e Android sono diverse; alcune funzionalità di sistema (notifiche, biometria, fotocamera) richiedono codice specifico per piattaforma anche se incapsulato dietro un'interfaccia comune. MAUI offre gli strumenti per gestire queste differenze con eleganza, ma il lavoro di adattamento esiste e va messo a budget.

Accesso alle API native del dispositivo

Un dubbio frequente di chi viene da WPF o dal web: "Se condivido il codice, perdo l'accesso alle funzionalità del dispositivo?". No. MAUI include le Essentials, un insieme di API multipiattaforma che espongono in modo unificato GPS, accelerometro, fotocamera, file system, connettività, preferenze, sicurezza. Scrivi Geolocation.GetLocationAsync() una volta e funziona su tutte le piattaforme. Quando ti serve una funzionalità che le Essentials non coprono, puoi sempre scendere al codice nativo della singola piattaforma tramite i progetti Platforms, mantenendo l'interfaccia condivisa pulita.

Desktop di prima classe, non un ripensamento

Una differenza importante rispetto a Xamarin.Forms, che era nato mobile-first, è che MAUI tratta il desktop come target di prima classe. Windows tramite WinUI 3 e macOS tramite Mac Catalyst non sono adattamenti forzati di un framework mobile, ma destinazioni supportate nativamente. Questo apre scenari interessanti per chi oggi mantiene applicazioni WPF e vuole una strada per arrivare anche a mobile e Mac. Se stai valutando il futuro di un'app desktop esistente, ti può interessare anche il nostro corso MAUI che affronta proprio la transizione da desktop classico a multipiattaforma.

Blazor Hybrid: riusare componenti web dentro un'app nativa

Se c'è una funzionalità di MAUI che vale la pena capire bene, è Blazor Hybrid. Cambia profondamente il ventaglio di scelte per chi ha già competenze web o componenti Blazor da riusare.

L'idea è questa: invece di costruire l'interfaccia in XAML, puoi costruirla con componenti Blazor, cioè file Razor con HTML, CSS e logica C#. Questi componenti vengono renderizzati dentro l'app MAUI tramite un controllo BlazorWebView. La parola "Web" può trarre in inganno: Blazor Hybrid non è un sito web caricato in un browser, e non usa WebAssembly né un server. Il codice C# dei componenti gira nativamente nel processo dell'app, ha accesso completo alle API native del dispositivo, e il BlazorWebView è solo il motore di rendering per l'HTML e il CSS.

Il risultato è che puoi avere un'app desktop e mobile nativa, con accesso pieno all'hardware, la cui interfaccia è costruita con il modello a componenti web. Per molti team questo è un punto di svolta. Se hai già un'app Blazor o componenti Razor condivisi, puoi riusarli dentro MAUI con modifiche minime, ottenendo un'app installabile che condivide UI con il tuo prodotto web.

XAML o Blazor Hybrid: come scegliere

Non è una guerra di religione, ed entrambi possono coesistere nella stessa app. La scelta dipende dal contesto del team e dal tipo di interfaccia. XAML conviene quando il team ha background WPF o Xamarin, quando vuoi il look-and-feel più vicino possibile al nativo di ogni piattaforma, e quando l'interfaccia ha molti controlli specifici del mobile. Blazor Hybrid conviene quando il team ha forti competenze web, quando esistono componenti Blazor da riusare, e quando l'interfaccia è densa di dati, tabellare o gestionale, dove il modello HTML/CSS è spesso più rapido e flessibile.

Un pattern che funziona bene nella pratica: usare Blazor Hybrid per le schermate complesse e dense di dati, e XAML per la shell di navigazione e gli elementi che devono sentirsi nativi. Se vuoi approfondire il lato Blazor in sé, dalle pagine ai componenti fino al rendering, il nostro corso Blazor copre i fondamenti che poi si riusano in MAUI Hybrid.

Quando conviene .NET MAUI rispetto allo sviluppo nativo

Questa è la domanda che separa una scelta tecnologica matura da una moda. Lo sviluppo nativo, Swift e SwiftUI per Apple, Kotlin e Jetpack Compose per Android, non è morto e in alcuni scenari resta la scelta giusta. Vediamo quando MAUI vince e quando perde.

I casi in cui MAUI è la scelta migliore

MAUI conviene chiaramente quando il team ha già competenze C# e .NET. Riusare le persone che hai già, invece di assumere specialisti iOS e Android (rari e costosi sul mercato italiano), è un vantaggio economico enorme. Conviene quando esiste un backend o una logica di dominio in .NET da riusare: la condivisione del codice diventa concreta, non teorica. Conviene quando devi coprire desktop e mobile insieme: poche tecnologie fanno entrambi bene, e MAUI è tra queste. E conviene per la categoria più ampia di applicazioni aziendali: gestionali, app per la forza vendita, strumenti interni, applicazioni di produttività, dashboard. Sono app dove la velocità di sviluppo e la manutenibilità contano più dell'ultimo effetto grafico.

I casi in cui il nativo resta superiore

Lo sviluppo nativo vince quando servono prestazioni estreme o grafica avanzata: giochi, app di editing video o foto in tempo reale, applicazioni con animazioni 3D complesse. Vince quando ti serve accesso immediato alle ultimissime API di sistema nel giorno in cui Apple o Google le rilasciano, perché i framework multipiattaforma hanno per natura un piccolo ritardo nell'esporre le novità. E vince quando l'app deve essere la vetrina tecnologica del prodotto, dove ogni microinterazione è curata al pixel e l'azienda ha il budget per due team specializzati. Per la maggior parte delle aziende, però, questi non sono i vincoli reali.

.NET MAUI vs Flutter: il confronto onesto

Flutter, il framework di Google basato su Dart, è il principale concorrente diretto di MAUI nel mondo del multipiattaforma. Confrontarli onestamente aiuta a fare la scelta giusta, senza tifoseria.

La differenza più profonda è nell'approccio al rendering. Flutter disegna ogni pixel dell'interfaccia con il proprio motore grafico (Skia/Impeller): i controlli non sono nativi, sono ridisegnati da Flutter per assomigliare al nativo. Questo dà un controllo totale sull'aspetto e una coerenza pixel-perfect tra piattaforme, ed è il motivo per cui Flutter eccelle nelle UI molto personalizzate e fortemente animate. MAUI invece usa i controlli nativi veri tramite gli Handler: l'app si sente più integrata con la piattaforma, ma hai meno controllo assoluto sul rendering.

La seconda differenza decisiva è il linguaggio e l'ecosistema. Flutter usa Dart, un linguaggio che la maggior parte dei team .NET non conosce. MAUI usa C#, lo stesso linguaggio del tuo backend, dei tuoi servizi, dei tuoi test. Per un team .NET, la scelta di MAUI azzera il costo di apprendimento di un nuovo linguaggio e permette di condividere codice con il backend. Per un team senza background .NET, questo vantaggio non esiste e Flutter parte alla pari.

Come decidere tra i due

La sintesi pratica: se il tuo team è .NET e hai logica da riusare, MAUI è quasi sempre la scelta razionale, soprattutto se ti serve anche il desktop. Se parti da zero, il team non ha background .NET e l'app è consumer con UI molto curata e animata, Flutter è un'ottima opzione. La maturità dell'ecosistema Flutter sui pacchetti di terze parti è oggi leggermente superiore, mentre MAUI ha il vantaggio dell'integrazione totale con il mondo .NET, Visual Studio, Azure e gli strumenti che il team già usa. Non esiste un vincitore assoluto, esiste la scelta giusta per il tuo contesto, ed è esattamente il tipo di valutazione che insegniamo nel nostro corso MAUI.

Casi reali: dove .NET MAUI funziona meglio

Astrarre va bene, ma gli scenari concreti chiariscono dove MAUI brilla. Questi sono i casi che vedo funzionare bene nel mercato italiano.

Applicazioni per la forza vendita e il campo

Un'azienda con agenti e tecnici sul territorio ha bisogno di un'app che funzioni su tablet e telefono, online e offline, con sincronizzazione verso un backend .NET. MAUI è ideale: la logica di sincronizzazione e i modelli si condividono con il backend, l'app gira su iOS e Android dei dispositivi aziendali, e una versione desktop può servire chi lavora dall'ufficio. Tutto con un solo team C#.

Gestionali multipiattaforma e migrazione da WPF

Molte aziende italiane hanno gestionali WPF maturi e funzionanti che però sono inchiodati a Windows. Quando arriva la richiesta di mobilità o di supporto Mac, MAUI offre una strada: la conoscenza di XAML, MVVM e binding si trasferisce quasi interamente, gran parte della logica di dominio si riusa, e si aggiunge la copertura di mobile e macOS. Non è una migrazione gratuita, ma è molto più economica di riscrivere tre app native.

Strumenti interni e app di produttività

Per applicazioni interne, dashboard, strumenti di approvazione, app di consultazione dati, MAUI con Blazor Hybrid è particolarmente efficace: si riusano componenti del portale web aziendale, si ottiene un'app installabile su desktop e mobile, e il time-to-market è ridotto perché il team lavora con tecnologie che già padroneggia.

Il filo conduttore di tutti questi casi è lo stesso: MAUI rende massimo il suo valore quando esiste già un investimento .NET da capitalizzare e quando l'app appartiene alla categoria gestionale-aziendale piuttosto che a quella consumer ultra-grafica.

Come iniziare con .NET MAUI: strumenti e primo progetto

Passiamo al concreto. Cosa serve per scrivere la prima riga di codice MAUI e arrivare a un'app che gira.

Setup dell'ambiente

Gli ingredienti minimi sono: .NET 8 o superiore, Visual Studio 2022 con il workload ".NET Multi-platform App UI development" selezionato in fase di installazione, oppure in alternativa VS Code con l'estensione .NET MAUI per chi preferisce un ambiente più leggero. Per compilare verso iOS e macOS serve un Mac con Xcode, requisito imposto da Apple e comune anche a Flutter e al nativo: durante lo sviluppo puoi usare il pairing del Mac da Visual Studio su Windows, ma la build finale Apple passa sempre da un Mac.

La struttura del primo progetto

Creando una nuova soluzione MAUI ottieni il progetto singolo con una struttura riconoscibile: App.xaml e AppShell.xaml per l'avvio e la navigazione, una cartella per le pagine XAML, una cartella Resources per font, immagini e stili, e la cartella Platforms con le sottocartelle per Android, iOS, Windows e MacCatalyst dove vive l'eventuale codice specifico. Il file MauiProgram.cs è il punto di ingresso dove configuri il gestore delle dipendenze, esattamente come faresti in un'app ASP.NET Core.

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
            });

        // Registra servizi e viewmodel nel gestore delle dipendenze
        builder.Services.AddSingleton<IDataService, DataService>();
        builder.Services.AddTransient<MainViewModel>();

        return builder.Build();
    }
}

Il percorso di apprendimento sensato

Se conosci già C#, la curva è contenuta. L'ordine che consiglio: prima i fondamenti di XAML e del layout, poi MVVM e data binding con CommunityToolkit.Mvvm, quindi la navigazione con Shell, poi l'accesso alle API native con le Essentials, e infine il packaging e la pubblicazione. L'errore tipico di chi impara da tutorial sparsi è saltare l'ordine, mettere logica nelle code-behind delle pagine invece che nei ViewModel, e ritrovarsi con un'app che funziona ma è impossibile da mantenere. Un percorso strutturato evita esattamente questi vicoli ciechi.

Pubblicare un'app .NET MAUI sugli store

Scrivere l'app è metà del lavoro. Portarla agli utenti significa packaging, firma e pubblicazione, e MAUI produce qui veri artefatti nativi.

Per Android generi un .aab (Android App Bundle, formato richiesto da Google Play) o un .apk per distribuzione diretta, firmati con il tuo keystore. Per iOS produci un .ipa firmato con i certificati e i provisioning profile del tuo account Apple Developer, pubblicabile su App Store tramite App Store Connect. Per Windows generi un pacchetto .msix distribuibile sul Microsoft Store o direttamente. Per macOS ottieni un bundle firmato e notarizzato secondo le regole Apple.

Il punto importante per un team che pensa al lungo termine è l'automazione. Tutto il ciclo di build, firma e pubblicazione si comanda da CLI con dotnet publish e si orchestra in pipeline CI/CD su Azure DevOps o GitHub Actions, esattamente come faresti per un servizio backend. Questo significa release ripetibili, niente passaggi manuali fragili, e la possibilità di distribuire a tutte le piattaforme con lo stesso flusso. La maturità del tooling .NET su CI/CD è uno dei vantaggi meno pubblicizzati ma più apprezzati di MAUI in produzione.

I limiti di .NET MAUI da conoscere prima di partire

Sarei poco credibile se ti raccontassi solo i pregi. MAUI ha limiti reali, e conoscerli prima evita decisioni che si rimpiangono.

Il primo è la maturità dei pacchetti di terze parti: l'ecosistema MAUI è più giovane di quello Flutter, e per esigenze molto specifiche potresti dover scrivere tu un binding nativo invece di trovare una libreria pronta. Il secondo sono i tempi di build e l'esperienza di hot reload, storicamente meno fluidi del nativo puro, anche se ogni release di .NET li migliora sensibilmente. Il terzo è che il debug specifico per piattaforma richiede competenza: quando un problema si manifesta solo su iOS, devi sapere abbastanza di iOS per capirlo, e l'astrazione di MAUI non ti esime del tutto dal conoscere le piattaforme sottostanti.

Nessuno di questi limiti è bloccante per la categoria di app per cui MAUI è pensato, ma vanno messi a budget onestamente. La differenza tra un progetto MAUI di successo e uno fallito sta quasi sempre nell'aver scelto MAUI per lo scenario giusto e nell'aver formato il team sulle pratiche corrette fin dall'inizio, invece di scoprire i limiti a metà del progetto. Se ti interessa una panoramica neutra prima di impegnarti, parti dalla nostra pagina su cos'è .NET MAUI.

Conclusione: MAUI conviene quando l'investimento .NET esiste già

Torniamo all'azienda da cui siamo partiti, con il gestionale Windows e la richiesta di portarlo su tablet, telefono e Mac. La risposta, ora, è chiara: non serve riscrivere tre volte, e non serve assumere specialisti di tre piattaforme. Serve capitalizzare il C# e la logica .NET che esistono già, e raggiungere desktop e mobile con una sola codebase. Questo è esattamente il lavoro per cui .NET MAUI è stato costruito.

.NET MAUI non è una bacchetta magica e non è la scelta giusta per ogni app. Per il gioco mobile dell'anno o per l'app consumer che deve stupire al pixel, il nativo o Flutter restano in vantaggio. Ma per la stragrande maggioranza delle applicazioni aziendali, gestionali e di produttività che popolano il mercato italiano, e in particolare per i team che hanno già un investimento .NET da valorizzare, MAUI offre il miglior equilibrio tra velocità di sviluppo, copertura delle piattaforme e manutenibilità nel tempo.

La barriera all'ingresso è bassa per chi conosce C#, ma la differenza tra un'app MAUI scritta bene e una scritta male è enorme e si paga nella manutenzione. Imparare MVVM correttamente, gestire il codice condiviso e quello specifico per piattaforma con disciplina, padroneggiare la navigazione, l'accesso alle API native e la pubblicazione: sono competenze che si acquisiscono molto più in fretta con un percorso strutturato che per tentativi ed errori su tutorial frammentati.

Il nostro corso MAUI è pensato per developer .NET che vogliono diventare produttivi sul multipiattaforma in modo solido: partiamo dalle basi di XAML e MVVM, affrontiamo Blazor Hybrid, l'accesso alle API native, la navigazione e la pubblicazione sugli store, sempre con esempi concreti e casi reali del mercato italiano. Se vuoi trasformare le tue competenze C# in app desktop e mobile che girano ovunque, è il punto di partenza giusto.