WinUI development has fully moved to GitHub: Microsoft finally lets you watch it change code. Today, Microsoft migrated the entire mainline development process of WinUI to GitHub. This isn't "Microsoft open-sourcing WinUI"—that news broke back in 2018, with the first commit to the microsoft-ui-xaml repository happening eight years ago under the MIT license, and the source code has always been

💡 What You Will Learn

WinUI development has fully moved to GitHub: Microsoft finally lets you watch it change code. Today, Microsoft migrated the entire mainline development process of WinUI to GitHub. This isn't "Microsof

📜 Table of Contents

• Four Years to Get Here
• Why Now
• What It Means for Regular Developers
• But Don't Expect Too Much
• My Take

WinUI Development Has Fully Moved to GitHub: Microsoft Finally Lets You Watch It Write Code

Today, Microsoft has fully migrated WinUI's mainline development workflow to GitHub.

This isn't "Microsoft open-sourcing WinUI" — that news broke back in 2018, and the first commit to the microsoft-ui-xaml repository was eight years ago, under the MIT license, with source code always visible.

What's changed this time is the development process itself. Previously, code was dumped on GitHub for you to read, but the actual writing, reviewing, and merging all happened inside Microsoft's internal systems — outsiders could only see the final result. Now, creating branches, submitting PRs, and code reviews all happen directly in the public repository. You can see Microsoft engineers arguing over a control bug, how many revisions they went through, and who made the final call.

Four Years to Get Here

This wasn't a spur-of-the-moment decision. In August 2025, Microsoft posted a phased plan in GitHub Discussions called "Phased Rollout Toward Open Collaboration," broken into four steps:

• Phase 1: Source code made public — done eight years ago
• Phase 2: Third parties can build WinUI product binaries from source — fully completed this August, with all 12 sub-items closed
• Phase 3: Test code made public, developers can run tests locally — completed
• Phase 4: Mainline development fully on GitHub — that's today's news, with 20 of 25 sub-items done

For a UI framework, going from open source code to an open development process took nearly four years. Along the way, they had to strip out internal dependencies, replace private platform APIs, and modernize compiler code — a bigger workload than most people imagine.

Why Now

Two things are converging.

First, at Build 2026 this year, Microsoft formally established WinUI as Windows' only native UI framework — even dropping the "3" from its name, calling it just "WinUI." Previously, UWP, WPF, and WinForms each went their own way; now native development has a single path.

Second, Microsoft is pushing Project K2, which aims to rewrite Windows system components using WinUI, reducing reliance on legacy frameworks and making Windows 11 faster and lighter. WinUI is no longer just a control library for third-party developers — it's becoming Windows' own UI infrastructure.

When a framework's stakes change, the transparency of its development process has to keep up. If a UI framework carrying system components still has a black-box development process, developers will struggle to build trust.

What It Means for Regular Developers

The most immediate change is a smaller information gap.

Previously, when you reported a WinUI bug, you could only write in Issues and then wait. Now you can see whether Microsoft's internal PRs are fixing the issue, how far along they are, and whether other changes have broken things. No more guessing when tracking progress.

Looking further ahead, once the development process is public, the barrier for external contributors to submit PRs will drop. Microsoft is still internally testing the PR acceptance pipeline and hasn't fully opened external submissions, but the direction is clear — moving from "we show you the code" to "we let you touch the code."

For developers building apps with WinUI, there's also a hidden benefit: with Microsoft's own engineers writing code in a public repository, code quality and comment standards are under scrutiny, and the cost of sloppy work just went up.

But Don't Expect Too Much

A few practical boundaries need to be stated clearly.

First, this isn't fully open contribution yet. Phase 4 has only 20 of 25 sub-items completed, and the external PR acceptance pipeline is still being tested. You can watch, fork, and build right now, but there's no formal channel for whether code you submit will actually be merged.

Second, WinUI's core compiler (XAML Compiler) code is still undergoing modernization — this is the most complex part, and Microsoft itself admits there's no clear timeline. Until the compiler is fully opened up, external developers who want deep involvement in framework development still face a barrier.

Third, an open development process doesn't mean open decision-making. Which technical direction to take, which controls to cut, how to prioritize — those are still decided internally at Microsoft. On GitHub, you can see the execution process, but not the decision meetings.

My Take

This change in WinUI is, at its core, Microsoft rebuilding confidence in Windows native development.

Over the past few years, Windows developers haven't had it great — UWP got sidelined, WinUI 3 was buggy, and the framework roadmap kept flip-flopping, pushing many people toward Electron, Tauri, or even the web. Now Microsoft is laying its only native framework's development process bare for you to see, paired with Project K2 rewriting the system using that very framework. The signal is clear: this is a path Microsoft itself is walking, and it wants you to believe it can get there.

Whether it's worth following depends on whether you build Windows native apps. If you do, watching this repository's PRs and Issues from now on will serve you far better than waiting for official blog posts. If you don't, this news is nice to skim — it doesn't affect you writing desktop apps with Electron.