.NET MAUI: una sola codebase C# per desktop e mobile multipiattaforma, quando conviene davvero

Paolo guida un team .NET da dieci anni, e di .NET MAUI non ha mai avuto motivo di occuparsi.

Il suo gestionale Windows gira liscio su duecento clienti.

Poi, a marzo, la direzione cambia le carte in tavola: serve il mobile.

Tablet per i venditori, telefono per i tecnici sul campo e, già che ci siamo, anche i Mac dell'ufficio marketing.

Paolo dice di sì.

Del resto, cosa doveva rispondere?

Che il suo team non ce la fa?

E fa la cosa più sensata per chi vive di .NET: mette sul tavolo .NET MAUI per lo sviluppo desktop e mobile con C#, il framework creato ad hoc da Microsoft.

Un solo linguaggio per il computer e per il telefono.

Il ragionamento non fa una piega.

Il team mastica già C# e XAML, quindi MAUI sarà un WPF più moderno, col mobile incluso nel pacchetto.

Quattro mesi dopo, la musica è un'altra.

La versione per Mac non si comporta come quella per Windows.

Per creare l'app dell'iPhone serve per forza un Mac acceso dentro la catena di produzione, e nel preventivo non l'aveva previsto nessuno.

Due funzioni del vecchio gestionale, nel mondo nuovo, semplicemente non ci sono: vanno riscritte da capo.

E un lunedì mattina Paolo deve entrare in una stanza e spiegare alla direzione perché la data slitta.

Per quel momento lì non esiste una slide che tenga.

Il punto è che Paolo non ha sbagliato per incompetenza.

Ha sbagliato perché si è fidato di una frase: è un "WPF moderno, col mobile incluso".

.NET MAUI viene presentato così da quasi tutti.

È una frase che promette il trasloco indolore: prendi quello che sai del computer e lo sposti sul telefono, tale e quale.

E si dimentica di dirti dove quel trasloco si inceppa.

Che poi è l'unica parte che decide se il progetto arriva in fondo o si pianta a metà.

Te lo dico fuori dai denti: MAUI è un buon strumento raccontato male.

Chi lo racconta dal palco, in genere, ha quaranta minuti da riempire, mica un progetto da consegnare per marzo.

In 27 anni dentro ai sistemi ho visto sfilare ogni generazione di strumenti "scrivi una volta, funziona ovunque".

La promessa regge, ma solo per chi si è letto le righe in piccolo prima di firmare.

Questo articolo è quelle righe in piccolo.

Più tutto il resto.

Ti spiego cos'è davvero MAUI e com'è fatto sotto il cofano.

Poi cosa puoi riusare pari pari tra Windows, Mac, iPhone e Android, e cosa invece no.

E infine ti porto dove i tutorial non ti accompagnano: il computer da ufficio, i tre errori che mandano a fondo i progetti, i limiti da mettere in conto prima di partire.

Così la prossima scelta la fai con in mano i numeri che Paolo ha scoperto dopo.

Non con le aspettative che aveva prima.

Cos'è .NET MAUI e a quale problema risponde davvero

MAUI sta per Multi-platform App UI.

È lo strumento ufficiale di Microsoft per costruire app vere, "native", partendo da un solo progetto scritto in C# e XAML.

Le piattaforme che copre sono quattro: Windows, Mac, iPhone e Android.

La parola che conta è "native".

MAUI non prende una pagina web e la infila dentro un guscio travestito da app.

Traduce tutto nei componenti reali di ogni sistema.

Un pulsante, sull'iPhone, diventa un vero pulsante iPhone.

Su Android, un pulsante Android.

Su Windows, un pulsante Windows.

Fin qui la definizione da manuale.

Che serve a poco.

La parte che ti interessa è un'altra: qual è il problema che MAUI ti toglie dal tavolo?

Senza uno strumento del genere, coprire computer e telefono vuol dire tenere in piedi progetti separati.

Swift per il mondo Apple, Kotlin per Android, WPF o WinUI per Windows.

Tre mondi, tre linguaggi.

E ogni funzione la scrivi e la collaudi tre volte.

Tradotto nella vita di tutti i giorni: la stessa correzione fatta tre volte, tre collaudi, tre occasioni per sbagliare.

Il costo maggiore non è nemmeno lo sviluppo iniziale.

È la manutenzione, che si moltiplica per il numero di piattaforme.

La paghi a ogni modifica e a ogni aggiornamento di sistema, per sempre.

E la paghi in serate e reperibilità: voci che nel preventivo non compaiono, ma che il tuo team conosce molto bene.

MAUI riporta tutto dentro un solo linguaggio e un solo motore.

La logica dell'applicazione, l'accesso ai dati, le chiamate ai servizi, i controlli sui dati: scrivi una volta in C#, e gira uguale dappertutto.

Per un'azienda italiana che ha già un team .NET, il conto è concreto.

Ti tieni le persone che hai, invece di rincorrere specialisti iPhone e Android, che da noi sono rari e trattenerli costa caro.

In pratica, i dieci anni di C# del tuo team smettono di essere un peso del passato e tornano a essere un vantaggio.

Cosa è cambiato da Xamarin a MAUI?

MAUI non è nato dal nulla.

È il figlio diretto di Xamarin.Forms, lo strumento che Microsoft ha usato fino al 2022.

Le differenze sono tre, e vanno tutte nella direzione giusta.

• Un progetto solo: basta con i doppioni, uno per piattaforma. Adesso un unico progetto dichiara dove vuoi arrivare e tiene insieme icone, risorse e avvio.
• Il motore è il .NET di oggi, lo stesso di ASP.NET Core: non più un motore separato che viveva per conto suo.
• La terza è più tecnica, e te la spiego tra poco: al posto dei vecchi Renderer ci sono gli Handler, più leggeri e più facili da modellare sulle tue esigenze.

Ma il dettaglio che decide davvero è un altro: Xamarin non è più supportato da maggio 2024.

Niente più aggiornamenti, niente più correzioni di sicurezza.

Ogni app Xamarin ancora in circolazione è una bomba a orologeria che, prima o poi, andrà disinnescata.

Basta un aggiornamento di iPhone che manda in crisi l'app, o una verifica di sicurezza richiesta dal cliente, perché non si parli più soltanto di codice, ma anche di obblighi e responsabilità.

Morale: qualsiasi progetto multipiattaforma .NET nuovo parte da MAUI.

E i progetti Xamarin ancora vivi vanno messi in agenda per la migrazione.

Meglio adesso, coi tempi che decidi tu, che tra sei mesi coi tempi che ti detta il cliente.

Se prima di entrare nei dettagli vuoi il quadro d'insieme, parti dalla pagina su cos'è .NET MAUI.

Il valore di MAUI non è lo slogan del codice unico: è far fruttare il C# che il tuo team ha già in casa.

Il Corso Maui di Sviluppatore Migliore parte esattamente da qui, e ti porta dove i tutorial si fermano: architettura, riuso della logica e le trappole che a Paolo sono costate quattro mesi.

Come funziona .NET MAUI: l'architettura spiegata senza gergo

Non ti serve conoscere ogni ingranaggio per usare MAUI bene.

Ti servono tre idee chiare.

Sono le tre idee che separano un'app che va d'accordo con lo strumento da una che ci litiga tutti i giorni.

E litigare con lo strumento ha un prezzo preciso: si chiama venerdì sera in ufficio a chiederti perché una lista si comporta diversamente su Android.

• Un progetto unico che sforna più app native. Nel progetto dichiari le piattaforme che vuoi raggiungere, e la compilazione ti prepara un'app vera per ognuna. La logica che condividi vive in normali classi C#, uguali a quelle di qualsiasi altro progetto .NET. Quando ti serve qualcosa di specifico per una piattaforma, c'è una cartella apposta: quello che ci metti finisce solo lì, senza sporcare il resto.
• Gli Handler, cioè il ponte tra i tuoi comandi e quelli veri del sistema. Ogni elemento che usi in MAUI, un campo di testo, un pulsante, una lista, è una specie di segnaposto che al momento giusto viene tradotto nel componente reale della piattaforma. Rispetto ai vecchi Renderer di Xamarin, gli Handler sono più leggeri e molto più semplici da personalizzare. Vuoi cambiare come si comportano tutti i campi di testo su Android? Metti mano al punto di traduzione, poche righe, e hai finito. Con Xamarin, la stessa cosa voleva una classe dedicata per ogni piattaforma. È il tipo di scelta che in una demo da venti minuti non noti, e che dopo tre settimane di lavoro vero ti salva il progetto.
• Il modello MVVM con il collegamento automatico dei dati. In parole povere: l'aspetto delle schermate lo descrivi in XAML, la logica che le muove sta in una classe a parte, e un meccanismo tiene i due lati sincronizzati da solo, senza che tu scriva codice per farlo a mano. Una libreria, CommunityToolkit.Mvvm, ti toglie di torno gran parte del lavoro ripetitivo: dichiari una proprietà o un comando con una piccola etichetta, e il resto lo scrive la macchina al posto tuo.

Chi arriva da WPF qui si sente subito a casa: XAML, collegamento dei dati e MVVM sono gli stessi concetti di sempre.

Ed è proprio quest'aria di casa il terreno su cui cresce l'equivoco da cui siamo partiti.

I concetti si spostano, il contesto no.

Quindi no, quello che sai non è roba vecchia.

È incompleto in un punto solo.

E quel punto costa quattro mesi, se lo scopri sul campo invece che prima.

Una sola base di codice per quattro piattaforme: cosa condividi al 100% e cosa no

La promessa del "codice scritto una volta" è seducente.

Ma va interpretata nel modo giusto.

Una cosa è quello che condividi per intero, un'altra è quello che condividi solo in parte.

Confonderle porta a stime sbagliate e a progetti che deragliano a metà strada.

Partiamo da quello che condividi tutto, senza sconti: la logica dell'applicazione.

Servizi, modelli, controlli sui dati, chiamate ai tuoi servizi, gestione dello stato.

È C# puro, gira identico su ogni piattaforma.

Se hai già una libreria .NET che fa questo lavoro, la riusi com'è.

E di solito è proprio la parte più costosa da costruire e da testare.

Condividerla è il risparmio che conta.

L'interfaccia, invece, la condividi in buona parte.

Non sempre tutta.

Una schermata con liste, moduli e navigazione funziona ovunque con lo stesso codice.

Ma i dettagli cambiano.

Quello che sul monitor sta comodo su tre colonne, sul telefono ne vuole una sola.

Il modo di spostarsi tra le schermate, su iPhone e su Android, segue abitudini diverse.

Notifiche, impronta digitale e fotocamera vogliono un po' di codice su misura per ogni sistema, anche se poi lo nascondi dietro un'unica porta comune.

MAUI ti dà gli attrezzi per gestire queste differenze con ordine.

Ma quel lavoro di adattamento esiste, e va messo nel preventivo dalla prima stima.

Sull'accesso al dispositivo, la domanda di chi arriva dal computer o dal web è sempre la stessa: perdo le funzioni native?

Risposta secca: no.

Ci sono le Essentials, un insieme di funzioni pronte: GPS con Geolocation, fotocamera con MediaPicker, file con FilePicker, stato della rete con Connectivity, preferenze con Preferences e archiviazione sicura con SecureStorage.

Una riga di C# ciascuna, identica sulle quattro piattaforme.

E quando ti serve qualcosa che le Essentials non coprono, scendi al codice della singola piattaforma, tenendo pulita la parte condivisa.

Ecco il quadro completo, componente per componente:

Un'ultima cosa, e non è un dettaglio da poco: per MAUI il computer da ufficio è un cittadino di serie A.

Windows con WinUI 3 e Mac con Mac Catalyst non sono ripensamenti forzati di uno strumento nato per il telefono, come invece era Xamarin.

Proprio per questo, però, il desktop merita un discorso a parte.

È lì che l'equivoco di Paolo ha presentato il conto.

MAUI sul desktop Windows e Mac: dove l'illusione del "WPF moderno" presenta il conto

Questa parte nei tutorial non la trovi.

Non perché sia un segreto: perché non sta in dieci minuti di video, e un video sui certificati Apple non se lo guarda nessuno.

Eppure, è proprio la parte che separa un progetto partito col piede giusto da uno che accumula guai dalla prima settimana.

Se vieni da WPF e sei convinto che MAUI sia WPF col mobile aggiunto, leggi questa prima di tutte le altre.

Il layout del desktop non è quello del telefono ingrandito

Su WPF disegni schermate a tutta larghezza, pannelli laterali, barre di strumenti, menu col tasto destro, colonne che allarghi come vuoi.

Su MAUI la stessa schermata deve stare bene su un telefono da sei pollici e su un monitor da ventisette.

Non è questione di aggiustare le larghezze.

Cambiano i modi di spostarsi, cambia cosa si aspetta il dito rispetto al mouse, cambia l'ordine con cui mostri le informazioni.

Gli strumenti di MAUI ti aiutano, ma pensare insieme computer e telefono è una decisione di progetto, non una limatura all'ultimo minuto.

Chi la salta si ritrova un gestionale che sembra un'app da telefono gonfiata a tutto schermo.

E gli utenti se ne accorgono al primo clic.

Mac Catalyst non è un vero programma per Mac

Sul Mac, MAUI usa Mac Catalyst: la tecnologia con cui Apple fa girare sul Mac le app pensate per l'iPad.

Il risultato funziona, ma l'esperienza è un filo diversa da quella di un programma scritto apposta per Mac.

Menu di sistema, gesti del trackpad, scorciatoie: è lì che la differenza si sente.

Per la stragrande maggioranza dei gestionali e degli strumenti aziendali non è un problema.

Ma se qualcuno si aspetta l'esperienza Mac curata al pixel, rimarrà deluso.

Meglio specificarlo alla firma del contratto.

L'app per iPhone e Mac passa per forza da un Mac

Apple pretende che la creazione finale dell'app per iPhone e Mac avvenga su un Mac con Xcode installato.

Non è un capriccio di MAUI: vale identico per Flutter e per lo sviluppo nativo.

In pratica, se la tua catena di produzione gira su Windows o Linux, devi aggiungerci un Mac.

Oppure ne noleggi uno da un servizio in cloud, con un costo in più.

È la voce che il team di Paolo ha scoperto a lavoro già iniziato.

Mettila in conto prima.

Per un'app MAUI destinata solo a Windows e Android, questo vincolo non esiste.

Se invece il dubbio è "resto su WPF o passo a MAUI su Windows?", il confronto è tutto nell'articolo su WPF nel 2026.

Lì trovi quando WPF resta la scelta giusta e quando MAUI è il passo sensato.

Paolo ci ha messo quattro mesi a rimettere in ordine il progetto.

Un conto che nessun tutorial mette in preventivo.

Leggere questo articolo ti fa risparmiare il tempo, ma non ti dà la pratica.

Lo so cosa stai pensando: "questa roba la trovo gratis in rete".

Verissimo.

Come trovi gratis tutto quello che serve per operare un'appendicite.

Poi però nessuno si opera guardando i video.

Quello che gratis non trovi è qualcuno che guarda il tuo progetto e ti dice: questa scelta, tra tre mesi, la paghi il doppio.

Le decisioni sul layout, la disciplina del codice condiviso, la trafila per Apple: si imparano costruendo, con qualcuno che ti raddrizza l'impostazione prima che diventi un problema.

Il Corso Maui di Sviluppatore Migliore serve esattamente a questo: un percorso su XAML, MVVM, Blazor Hybrid e pubblicazione, costruito su esempi che rispecchiano le esigenze del mercato.

Il risultato non è "sapere MAUI".

È diventare la persona a cui, in azienda, il progetto multipiattaforma lo affidano.

Quella che sceglie con criterio.

E quel tipo di persona non la sostituisci con un preventivo più basso.

Fai il conto giusto, poi decidi: mesi impostati male costano più di qualsiasi corso (compreso il nostro).

E li paghi senza portarti a casa niente.

Blazor Hybrid: pezzi di web dentro un'app vera, senza browser

Se c'è una cosa di MAUI che allarga il ventaglio delle scelte, è Blazor Hybrid.

Invece di costruire le schermate in XAML, le costruisci con i componenti di Blazor: file con dentro HTML, CSS e logica in C#, mostrati dentro l'app da un elemento che si chiama BlazorWebView.

La parola "web" qui inganna.

Non è un sito caricato in un browser.

Non gira sul web, non ha bisogno di un server.

Il codice C# di questi componenti gira dentro l'app in modo nativo, con accesso pieno alle funzioni del dispositivo.

Il BlazorWebView è solo il motore che disegna l'HTML e il CSS.

Il risultato: un'app vera, per computer e telefono, la cui interfaccia è costruita coi mattoncini del web.

Per molti team è la svolta.

Se hai già un portale Blazor o dei componenti Razor da riusare, li porti dentro MAUI con ritocchi minimi.

Ti ritrovi un'app installabile che condivide l'interfaccia col tuo prodotto web, senza mantenere due volte la stessa schermata.

E mantenere due volte la stessa schermata vuol dire ogni modifica fatta due volte, ogni errore corretto due volte: la sensazione di correre restando fermi.

XAML o Blazor Hybrid: come scegliere

Non è una guerra di religione.

I due approcci convivono nella stessa app.

XAML conviene quando il team ha un passato in WPF o Xamarin, e quando vuoi l'aspetto più vicino possibile al nativo di ogni sistema.

Conviene anche dove l'interfaccia è piena di gesti tipici del telefono.

Blazor Hybrid conviene quando il team conosce bene lo sviluppo web, e quando ci sono già componenti da riusare.

E conviene dove le schermate sono dense di dati e tabelle, il terreno su cui HTML e CSS restano più rapidi e flessibili.

Nella pratica, lo schema che funziona è questo: Blazor Hybrid per le schermate complicate e piene di dati, XAML per la navigazione e per gli elementi che devono sembrare nativi al tatto.

La scelta sbagliata non si vede il primo mese.

Si vede il giorno in cui devi cambiare qualcosa e scopri quanto ti costa.

MAUI, nativo o Flutter: la scelta si fa sul contesto, non sull'entusiasmo

Questa è la domanda che separa una decisione matura da una moda.

E nel software le mode le pagano sempre le stesse persone: quelle che restano a tenere in piedi il progetto quando chi l'ha scelto è già passato ad altro.

Lo sviluppo nativo, Swift per Apple e Kotlin per Android, non è morto.

Flutter, lo strumento di Google, è il concorrente più serio.

La risposta giusta dipende dal contesto.

E il contesto si misura su tre cose: il team che hai, il codice che hai, il tipo di app che devi fare.

Quando MAUI è la scelta di testa

MAUI vince quando il team conosce già C# e .NET.

Riusare le persone che hai, invece di assumere specialisti, è un risparmio importante.

Se hai passato dieci anni su C#, è qui che quei dieci anni valgono il doppio invece della metà.

Vince quando c'è un server o una logica .NET da riusare, perché la condivisione diventa concreta e non teorica.

Vince quando devi coprire computer e telefono insieme, perché poche tecnologie fanno bene tutte e due le cose.

E vince per la famiglia più ampia di applicazioni aziendali: gestionali, app per la forza vendita, strumenti interni, cruscotti di dati.

Posti dove contano la velocità di sviluppo e la facilità di manutenzione, più dell'ultimo effetto grafico.

Quando il nativo resta avanti

Il nativo vince quando servono prestazioni al limite o grafica spinta: giochi, montaggio video dal vivo, animazioni in tre dimensioni.

Vince quando ti servono le ultimissime funzioni del sistema il giorno stesso in cui Apple o Google le rilasciano.

Ogni strato multipiattaforma introduce un piccolo ritardo fisiologico.

E vince quando l'app è la vetrina del prodotto, ogni minimo movimento è curato al pixel, e l'azienda ha il budget per due team specializzati.

Se sei in uno di questi casi, MAUI non è la tua risposta.

E preferisco dirtelo qui che dopo.

Ma per la gran parte delle aziende italiane, questi non sono i vincoli veri.

MAUI o Flutter: la differenza che decide

La differenza più profonda è nel modo di disegnare le schermate.

Flutter disegna ogni pixel col suo motore grafico: i comandi non sono nativi, sono ricreati per assomigliare al nativo.

Questo dà una coerenza assoluta tra le piattaforme, ed è al suo meglio nelle interfacce molto animate.

MAUI usa i comandi nativi veri, attraverso gli Handler: l'app si sente più integrata nel sistema, in cambio di un po' meno controllo assoluto sul disegno.

La seconda differenza è il linguaggio.

Flutter usa Dart, che la maggior parte dei team .NET non conosce.

MAUI usa lo stesso C# del tuo server, dei tuoi servizi, dei tuoi test.

La tua esperienza in C# non è una zavorra da superare per stare al passo.

È la ragione per cui, su questa scelta, parti un passo avanti agli altri.

Va detto anche il rovescio: l'offerta di componenti pronti attorno a Flutter oggi è un po' più ricca.

MAUI in cambio si incastra alla perfezione con Visual Studio, Azure e gli strumenti che un team .NET usa già ogni giorno.

Il confronto, ridotto a quello che conta davvero:

I tre errori che mandano a fondo un progetto MAUI in produzione

I progetti MAUI che ho visto fallire non sono affondati per colpa dello strumento.

Sono affondati per tre errori, sempre gli stessi, tutti evitabili, tutti figli della stessa radice: partire con la testa del "WPF moderno col mobile incluso" invece che con la disciplina del multipiattaforma:

• Mettere la logica dentro il codice della schermata invece che nella classe separata. Chi impara a pezzi dai tutorial carica i dati dritti nel file della pagina, perché è il modo più veloce per vedere qualcosa muoversi. Peccato che regga malissimo alla crescita: la schermata diventa impossibile da collaudare da sola, la navigazione si ingarbuglia, e ogni ritocco grafico si trascina dietro pezzi di logica da spostare. Il finale lo sai già: c'è una persona sola, in azienda, che se la sente di toccare quella schermata. Se quella persona sei tu, non è un complimento. È una gabbia. Il modello MVVM, con la libreria CommunityToolkit.Mvvm, taglia il problema alla radice. Ma va adottato dal primo giorno, non dopo il primo brutto risveglio.
• Gestire le differenze tra piattaforme senza uno schema chiaro. Prima o poi ogni app vera ha bisogno di un comportamento su misura: una notifica su Android, un permesso su iPhone. La tentazione è riempire il codice condiviso di piccole eccezioni sparse, un pezzetto qui e uno là. Dopo sei mesi quel codice non lo legge più nessuno. E quello che non si legge, chi entra nuovo non lo tocca: torna tutto sulle spalle di sempre. La strada giusta è definire una porta unica per ogni servizio che cambia, realizzarla nelle cartelle di piattaforma e collegarla. Il codice condiviso parla con la porta e non sa nemmeno su quale sistema sta girando.
• Sottovalutare la trafila di firme e permessi di Apple in fase di pianificazione. Certificati, profili, autorizzazioni, App Store Connect: ogni passaggio ha i suoi tranelli. Scoprirli tutti nell'ultima settimana prima del rilascio è il finale che nessuno vuole. I rilasci non saltano quasi mai per un problema difficile. Saltano per tre giorni di certificati. La soluzione è semplice, e quasi nessuno la applica: pubblica in un ambiente di prova il prima possibile, anche quando l'app è ancora uno scheletro.

La prima pubblicazione è la più dolorosa.

Falla quando il calendario non brucia.

Tre situazioni vere in cui MAUI porta valore concreto

Questi tre li vedo funzionare nel mercato italiano.

Il primo: l'app per chi vende e per i tecnici sul territorio.

Serve su tablet e telefono, deve funzionare anche senza rete e allinearsi col sistema centrale quando la connessione torna.

Qui MAUI lavora nelle condizioni per cui è stato pensato.

La logica di allineamento e i modelli li condividi col tuo sistema .NET, l'app gira sui dispositivi aziendali iPhone e Android, e una versione desktop copre chi lavora dall'ufficio.

Tutto con un solo team C#, che parla la stessa lingua dal database allo schermo del tablet.

Nessuna assunzione da giustificare, nessun fornitore esterno da rincorrere.

Il secondo: gli strumenti interni e le app di produttività.

Cruscotti di dati, richieste da approvare, documenti da consultare.

Qui MAUI con Blazor Hybrid è particolarmente efficace, perché riusi i componenti del portale web che hai già.

Ti ritrovi un'app installabile su computer e telefono in poco tempo, con tecnologie che il team padroneggia.

In un'azienda italiana di medie dimensioni, spesso è la differenza tra il progetto approvato e il progetto rimandato all'anno prossimo.

Il terzo: l'applicazione Windows storica che deve aggiungere il mobile senza mollare il desktop.

È la situazione di Paolo: non buttare il gestionale, allargarlo.

Parti dall'app Windows e aggiungi Android per chi è in giro.

Il lavoro su XAML e MVVM già fatto sul computer lo riusi di peso, con le accortezze viste sopra.

Non è un salto nel vuoto.

È allargare quello che il team sa già fare.

Il filo è sempre lo stesso: MAUI dà il meglio quando c'è un investimento .NET da far fruttare, e quando l'app è di famiglia gestionale, non un prodotto di largo consumo tutto giocato sulla grafica.

Se in uno di questi tre scenari hai riconosciuto la tua azienda, quello che manca non è capire se MAUI serve: è saperlo portare in produzione.

Il Corso Maui di Sviluppatore Migliore ti accompagna dal primo progetto alla pubblicazione sugli store, su casi che rispecchiano il mercato in cui lavori.

Dal primo progetto MAUI alla pubblicazione sugli store

Veniamo al pratico: cosa ti serve per scrivere la prima riga e arrivare fino agli utenti.

Cosa preparare e in che ordine imparare

Ti serve .NET 10, o come minimo .NET 8, e Visual Studio 2026 con il pacchetto dedicato a MAUI.

In alternativa, per chi preferisce leggero, VS Code con l'estensione ufficiale.

Non stare a cercare un C# da scaricare a parte: il linguaggio è già dentro .NET, qualunque editor tu scelga.

Per creare l'app di iPhone e Mac ti serve un Mac con Xcode, il vincolo Apple di cui abbiamo già parlato.

Il progetto MAUI che ti trovi davanti ha una forma riconoscibile: file di avvio e navigazione, risorse, cartelle per il codice specifico di ogni piattaforma.

E un punto in cui colleghi servizi e classi, esattamente come faresti in un'app ASP.NET Core.

Se conosci già C#, la salita è dolce.

L'ordine giusto è questo:

• XAML e disposizione delle pagine, per capire come si costruiscono le schermate
• MVVM e collegamento dei dati, per tenere separate logica e interfaccia
• navigazione tra le pagine
• funzioni del dispositivo con le Essentials
• preparazione e pubblicazione sugli store

Scritto così sembra banale.

Ricostruirlo da solo, saltando da un video all'altro, ti porta via mesi.

E per tutti quei mesi non sai se stai avanzando o girando a vuoto, che poi è la parte che logora sul serio.

L'errore tipico di chi impara da tutorial sparsi è saltare l'ordine e ritrovarsi con un'app che funziona ma non si riesce a mantenere.

La documentazione ufficiale di MAUI è ottima da consultare, meno da usare come mappa: l'ordine te lo devi dare tu.

Pubblicare su App Store, Google Play e Microsoft Store

Scrivere l'app è metà del lavoro.

L'altra metà è farla arrivare alle persone.

• Per Android prepari il pacchetto per Google Play o per la consegna diretta, firmato con la tua chiave.
• Per iPhone prepari il pacchetto firmato coi certificati del tuo account Apple e lo pubblichi tramite App Store Connect.
• Per Windows crei il pacchetto per il Microsoft Store o per la distribuzione interna.
• Per Mac serve un pacchetto firmato e autenticato secondo le regole di Apple.

Il punto che conta, se pensi al lungo periodo, è l'automazione.

Tutto il giro, cioè compilazione, firma e pubblicazione, lo puoi comandare da riga di comando e orchestrare in una catena su Azure DevOps o GitHub Actions, come faresti per un normale servizio sul server.

Rilasci ripetibili, nessun passaggio manuale traballante, distribuzione su tutte le piattaforme con lo stesso flusso.

La differenza rispetto a tre progetti nativi separati è che qui la pipeline è una sola: stesso repository, stesso file di build, quattro artefatti in uscita.

Un team che automatizza il rilascio smette di avere paura del rilascio.

E un team che non ha paura di rilasciare consegna più spesso.

I limiti di MAUI da mettere in conto prima di partire

Sarei poco credibile se ti raccontassi solo i pregi.

Chi ti presenta una tecnologia senza difetti non ti sta spiegando una tecnologia. Ti sta vendendo un biglietto.

I limiti veri sono quattro, e nessuno dei quattro compari negli slogan.

• Il primo: i componenti pronti di altri produttori. Syncfusion, Telerik e DevExpress hanno suite MAUI mature, ma fuori da quei tre il catalogo si assottiglia in fretta, mentre su Flutter trovi pacchetti di comunità per quasi tutto. Per esigenze molto particolari puoi trovarti a scrivere un collegamento al codice nativo invece di scaricare una libreria già fatta.
• Il secondo: i tempi di compilazione e la fluidità della ricarica a caldo del codice. Su un progetto medio la compilazione completa per Android sta nell'ordine dei minuti, non dei secondi, e la ricarica a caldo cade più spesso che in WPF: metti in conto qualche riavvio in più nella giornata.
• Il terzo: capire i problemi che saltano fuori solo su una piattaforma richiede competenza. Quando un difetto compare solo sull'iPhone, devi saperne abbastanza di iPhone per venirne a capo. Lo strato di MAUI non ti dispensa dal conoscere le piattaforme che ci stanno sotto.
• Il quarto è quello che quasi nessuno mette in conto: le prove si moltiplicano per le piattaforme. Il codice è uno, ma i comportamenti da verificare sono quattro, su dispositivi con schermi, versioni e permessi diversi.

"Una sola base di codice" non vuol dire "un solo giro di collaudi".

I piani di test e i dispositivi, veri o noleggiati in cloud, vanno previsti dall'inizio.

Nessuno di questi limiti è un muro, per il tipo di app a cui MAUI è pensato.

Ma la differenza tra un progetto che arriva in produzione e uno che si arena sta quasi sempre qui: scegliere MAUI per la situazione giusta, e mettere in conto i vincoli prima di partire, invece di scoprirli al quarto mese come Paolo.

Te li ho elencati adesso, gratis.

Così non te li elenca il cliente a settembre, con un tono che conosci.

Conoscere i limiti prima di partire è metà del lavoro; l'altra metà è gestirli senza scoprirli al quarto mese.

E quella metà si impara costruendo: nel Corso Maui di Sviluppatore Migliore lavori su progetti veri, con chi ti raddrizza l'impostazione prima che diventi un problema.

MAUI conviene quando l'investimento .NET c'è già

Torniamo alla richiesta di partenza: il gestionale Windows da portare su tablet, telefono e Mac.

Adesso la risposta ha i contorni giusti.

Non serve riscrivere tre volte.

Non servono specialisti di tre piattaforme.

E non serve nemmeno credere allo slogan.

Serve far fruttare il C# che c'è già e condividere la logica per intero.

E serve adattare l'interfaccia dove va adattata, mettendo in conto i vincoli di Apple e del computer da ufficio.

Questo è il lavoro per cui MAUI è nato.

Ed è un lavoro che ripaga.

Per chi vive su un computer che resta Windows e non ha bisogno di mobile, WPF rimane una scelta solida e matura.

Ma per la gran parte delle applicazioni aziendali italiane il discorso cambia.

Per i team con un investimento .NET da valorizzare su più piattaforme, oggi MAUI offre il miglior equilibrio tra velocità, copertura e manutenzione.

Il costo del non decidere, però, è preciso.

Ogni settimana costruita sull'aspettativa sbagliata è una settimana che qualcuno dovrà rifare.

E ogni mese passato a rimandare è un mese in cui i concorrenti consegnano sui dispositivi dove i tuoi clienti già lavorano.

La differenza tra chi paga il conto dell'illusione e chi lo evita non è il talento.

È il metodo con cui la scelta viene impostata.

C'è chi passa la carriera a eseguire scelte fatte da altri, e poi a raccoglierne i cocci.

E c'è chi le scelte le imposta, e viene chiamato quando ne arriva una difficile.

Da che parte stare lo decidi tu.

Nessuno lo decide al posto tuo.

Paolo, quello dell'inizio, sei mesi dopo aveva l'app su tablet Android e su computer Windows, in produzione.

La versione Mac era pianificata con criterio, non promessa a voce.

Non perché ha imparato più tecnologie: perché ha sostituito le aspettative con un metodo, e ha smesso di scoprire i vincoli a giochi fatti.

Il percorso non è per tutti, e si entra su candidatura.

Matteo Migliore, che guida il percorso, segue di persona ogni team; quindi, i posti non possono essere infiniti.

Se dalla chiacchierata viene fuori che per te non ha senso, te lo dico: preferisco un no chiaro oggi a una persona delusa tra tre mesi.

Quello che questo articolo non può darti, la lettura del tuo caso specifico, è esattamente il punto da cui parte una call.