Microsoft has moved the mainline development of WinUI, its native UI framework for Windows, to GitHub, and has begun conducting PR review, validation, and merging in the public repository. Until now, what was visible from outside was mostly the state after changes—made largely in-house—had already landed on GitHub. Going forward, it will also be possible to trace the decisions that lead up to a change shipping in the product.
That said, the PRs currently in the repository are from Microsoft developers, and the company has not disclosed when it will start accepting PRs from the general developer community. What this milestone has opened up is the development process itself; community participation awaits a further decision.
Four phases, from internal mirror to mainline development
On July 31, 2025, Microsoft announced a four-phase plan for opening up WinUI development. Phase 1 involved increasing the frequency of syncing internal commits to GitHub. Phase 2 aimed to get the repository to a state where external developers could clone it and build locally. Phase 3 covered running tests and preparing for contributions, and Phase 4 was meant to make GitHub the center of development, issue tracking, and community dialogue.
Microsoft cited WinUI's deep ties to non-public parts of Windows as the reason for splitting the work into phases. The company needed to separate code that could be made public from private layers, and also make the dependencies required for building and testing accessible from outside. Even when it reported the completion of Phase 3 on May 11, 2026, Microsoft could not give a precise timeline for Phase 4, citing the complexity of the XAML compiler.
Subsequently, on July 29, Microsoft had indicated a target of around September, but an August 27 update revealed that Phase 4 had been reached ahead of schedule. The progress indicators in the official Discussion thread were also updated by the following day, August 28, with all four items marked complete. In other words, the operating model has shifted from treating the internal repository as the source of truth and mirroring it outward, to treating work on GitHub itself as the source of truth.
The difference between "visible code" and "visible development"
The WinUI GitHub repository has carried an MIT License for some time, permitting use, modification, and redistribution of the code. So what's new here isn't the license. What has changed is that day-to-day branches and PRs are now created in the open, reviewed, validated, and then merged—meaning that, beyond the history of finished commits, the discussions leading up to adoption can now be examined as well.
This difference is not trivial for developers who build on WinUI. Rather than waiting until a fix lands in a release, they can follow which bugs are being investigated and which design proposals were rejected. It also gives them more material to gauge the progress of changes their own apps depend on. If needed, they can check out a published branch locally and share reproduction conditions or impact scope at an early stage.
Microsoft Learn describes WinUI 3 as the recommended native UI framework for new Windows desktop apps. It is provided as part of the Windows App SDK and can be used from C# and C++. It's not exclusive to Windows 11—it also targets Windows 10 version 1809 and later. Precisely because it's a candidate foundation for a wide range of Windows apps, being able to externally verify the update process carries real significance.
Contribution guidelines are ready, but outside PRs are still to come
According to CONTRIBUTING.md in the public repository, developers are expected to first fork the repository and build it locally. Changes should include the necessary tests, with PRs submitted against the main branch. Merging requires approval from two or more members of the WinUI team, along with resolution of all review conversations. A signed CLA and a successful PR build are also required. New public APIs or UI elements require a proposal process before code is even submitted.
Meanwhile, the August 27 announcement explicitly stated that the PRs currently in the pipeline are from Microsoft developers. The company is using this period to test the entire chain—from the contribution workflow through validation, documentation, and release. Having documentation in place for external developers and having fully opened up code acceptance are not, at this stage, the same thing.
Microsoft is currently using internal PRs to exercise the contribution workflow and validation process, confirming everything from documentation through release. According to the official post, the goal during this period is to establish a reliable, predictable pipeline for when the company begins accepting PRs from external developers. Microsoft says it will make a further announcement once that state is reached.
What to measure once transparency arrives
With the move to GitHub, there will be fewer occasions where developers have to wait for after-the-fact explanations from Microsoft. For one thing, the record now shows how frequently PRs are updated and when reviews begin. It also shows which changes were merged after review, making it possible to confirm from public information whether work is actually moving forward.
However, a visible process does not guarantee faster fixes or better product quality. If a published issue sits unaddressed for a long time, the only new outcome is that the stagnation itself has become visible from outside. And even after external PRs start being accepted, if Microsoft doesn't devote time to reviewing and maintaining them, the community's effort won't easily translate into product improvements.
When Microsoft begins accepting PRs from the general developer community will be the next milestone. After that, it will be necessary to track whether external PRs are actually reviewed, pass tests, and make it into a Windows App SDK release. If that cycle holds, outside developers, too, will be able to take part in improving WinUI.