Per anni la community .NET ha guardato con una certa invidia i colleghi che sviluppano su Avalonia UI o Uno Platform: framework UI nativi per Windows, ma con il codice sorgente completamente aperto e contribuibile da chiunque. WinUI, il toolkit di interfaccia moderno di Microsoft per applicazioni desktop Windows, è invece rimasto per anni uno sviluppo “a porte chiuse”, con un repository pubblico più che altro simbolico e la vera attività di sviluppo confinata ad Azure DevOps interno. Questo sta cambiando, ma con una tabella di marcia più articolata di quanto il titolo delle notizie di questi giorni lasci intendere.

Cos’è WinUI e perché la sua apertura conta

WinUI 3 è il motore di rendering e la libreria di controlli su cui si basa il Windows App SDK, l’evoluzione moderna dello stack UI di Windows che ha sostituito (o affiancato, a seconda dei casi) UWP, WPF e Windows Forms per le applicazioni desktop native più recenti. È il framework consigliato da Microsoft per chi scrive nuove applicazioni Windows in C#/.NET con un’interfaccia utente moderna, fluida e coerente con il design system di Windows 11.

Il problema storico è che, pur essendo distribuito come pacchetto NuGet open source, lo sviluppo effettivo del codice avveniva internamente. Il repository GitHub microsoft/microsoft-ui-xaml serviva principalmente per il tracciamento delle issue, non per contributi di codice reali. Questo ha generato negli anni frustrazione attorno a problemi noti e mai risolti: supporto incompleto per i valori decimali nel controllo NumberBox, finestre di dialogo modali poco affidabili, gap nella validazione degli input, l’assenza di un designer visuale integrato in Visual Studio e prestazioni non sempre all’altezza rispetto alla vecchia UWP.

Il piano a quattro fasi

Microsoft ha pubblicato la roadmap dell’apertura in una discussion ufficiale sul repository, ed è organizzata in quattro fasi progressive, non in un singolo “flip the switch”:

Fase 1 (completata, ott. 2025)
  → aumento della frequenza di mirroring da Azure DevOps a GitHub:
    i commit interni diventano visibili quasi in tempo reale

Fase 2 (completata, dic. 2025)
  → gli sviluppatori esterni possono clonare il repository e
    compilarlo in locale, con documentazione sulle dipendenze

Fase 3 (completata, mag. 2026)
  → i contributor possono aprire pull request (mirrorate
    internamente) ed eseguire la test suite in locale;
    il team ha districato le dipendenze private e reso
    pubblica l'infrastruttura di test

Fase 4 (in corso, target set. 2026)
  → GitHub diventa l'hub di sviluppo primario, eliminando
    il mirroring interno come centro di gravità del progetto

Ad oggi ci troviamo quindi tra la fase 3 e la fase 4: il codice è realmente visibile e buildabile, ma il flusso di contribuzione della community non è ancora quello “GitHub-native” a cui si è abituati con altri progetti open source Microsoft come .NET stesso o VS Code.

Cosa si può fare concretamente oggi

Per chi vuole già mettere le mani sul codice, i requisiti pratici per compilare WinUI in locale sono non banali: circa 80 GB di spazio disco libero e almeno 32 GB di RAM per una build confermata funzionante. Non è un progetto leggero da compilare su un laptop di fascia media.

git clone https://github.com/microsoft/microsoft-ui-xaml.git
cd microsoft-ui-xaml
# seguire la documentazione del repository per le
# dipendenze del toolchain e i target di build supportati

Il branch principale (winui3/main) riceve tuttora sincronizzazioni dirette da Azure DevOps, quindi è aggiornato ma non ancora il punto di partenza esclusivo dello sviluppo. La test suite è ora eseguibile pubblicamente, il che permette di verificare in autonomia se una patch personalizzata introduce regressioni prima di proporla come contributo.

Cosa resta chiuso, e perché

Non tutto lo stack diventerà pubblico nel breve termine. WinUI ha “radici profonde” in componenti proprietari del sistema operativo, e alcune aree restano fuori dal perimetro di apertura, almeno per ora:

• Il compilatore XAML: è il focus dichiarato della fase 4, ma resta per ora un componente interno.
• La compilazione dei pacchetti MSIX: strettamente legata alla toolchain di packaging di Windows.
• Alcuni layer di gestione input: in particolare Microsoft.UI.Input.dll è indicato esplicitamente come area problematica da aprire, per via delle dipendenze con sottosistemi Windows non pubblici.

Beth Pan, una delle maintainer del progetto, ha descritto il processo con una frase che vale la pena riportare: non è “un interruttore da girare”, ma un percorso deliberato. È un’aspettativa realistica da tenere a mente prima di proporre la prima pull request pensando di vederla mergeata in tempi brevi.

Come si posiziona rispetto alle alternative

Per chi sta scegliendo oggi un framework UI desktop per .NET, un confronto rapido aiuta a inquadrare la novità:

• WinUI 3 / Windows App SDK: nativo Windows, massima integrazione col design system Windows 11, ora in fase di apertura ma sviluppo ancora a trazione Microsoft; solo Windows.
• Avalonia UI: completamente open source da anni, cross-platform (Windows, Linux, macOS), community di contributor esterni consolidata, look and feel personalizzabile via XAML-like styling.
• Uno Platform: nato come porting di UWP/WinUI verso altre piattaforme (inclusi WebAssembly e mobile), open source, spesso scelto proprio da chi vuole la sintassi WinUI ma con vera portabilità multipiattaforma.
• .NET MAUI: soluzione ufficiale Microsoft per mobile e desktop cross-platform, con un modello a controlli nativi per piattaforma anziché un motore di rendering condiviso come Avalonia.

L’apertura di WinUI non cambia immediatamente questo quadro competitivo, ma riduce un differenziale reale: la trasparenza sullo sviluppo. Poter vedere le pull request in corso, le decisioni di design discusse pubblicamente e i problemi di performance affrontati in tempo reale è un beneficio concreto anche per chi non contribuirà mai una riga di codice, perché permette di valutare con più cognizione di causa se e quando un problema noto (penso al supporto NumberBox o alla stabilità dei dialoghi modali) verrà effettivamente risolto.

Conclusione

Chi sviluppa applicazioni desktop Windows in .NET dovrebbe iniziare a seguire da vicino il repository microsoft/microsoft-ui-xaml, non tanto per proporre subito una pull request quanto per avere finalmente visibilità reale sulla roadmap tecnica del framework che probabilmente sta già usando in produzione. La fase 4, attesa per settembre 2026, sarà il vero banco di prova: se GitHub diventerà davvero il centro di sviluppo primario, WinUI potrà iniziare a colmare il gap di fiducia accumulato in anni di sviluppo chiuso rispetto a progetti come Avalonia. Fino ad allora, vale la pena testare la build locale e valutare in autonomia lo stato di salute del progetto, invece di affidarsi solo agli annunci ufficiali.

Fonte: 4sysops.com. Dettagli tecnici sulla roadmap: GitHub Discussion #10700. Documentazione ufficiale: Microsoft Learn — WinUI 3.