🚀 WinUI OSS Update: Phased Rollout Toward Open Collaboration

[beth-panx]

Hey everyone,

Thanks for all the feedback, questions, and ideas. We hear you loud and clear and are taking it seriously. We're entering a new phase of focused improvements over the next 6 months, including product work and foundational changes to support a more open and collaborative future.

Many of you have asked about truly open sourcing the repo. While we’re not ready to commit to a specific end date for completing all milestones, we are actively working toward it. This isn’t a flip-the-switch moment, it’s a deliberate process.

📆 Phased Rollout Plan

We are taking a phased approach to opening up the repo:
Phase 1: Increased Mirror Frequency
After the WASDK 1.8 release (end of August), we’ll begin more frequent mirroring of internal commits to GitHub to increase transparency and show progress.
Phase 2: 3rd Party Devs Build Locally
External developers will be able to clone and build the repo locally, with documentation to guide setup and dependencies.
Phase 3: 3rd Party Devs Contribute & Run Tests
Contributors will be able to submit PRs and run tests locally. We’re working to untangle private dependencies and make test infrastructure publicly accessible.
Phase 4: GitHub as Center of Gravity
GitHub becomes the primary place for development, issue tracking, and community engagement. Internal mirrors will be phased out.

🧱 Why It’s Complex

WinUI has deep roots in Windows. Parts of the codebase touch proprietary layers that can’t be published as-is. We’re working to separate what can be shared from what can’t. This work is in progress and takes time.

🎯 Alignment with Microsoft Goals

We are being thoughtful about resourcing. This effort is happening alongside other critical responsibilities like security, platform stability, and support for existing products. Our current focus is on foundational work that unlocks value for contributors and increase transparency. We are aligning this work with Microsoft’s broader business priorities to ensure long-term support and impact.

💡 How You Can Help

If you’re passionate about WinUI 3 and want to contribute:

• Keep sharing feedback, it helps us prioritize.
• File issues with clear repro steps and context.
• Upvote issues that matter most to you with 👍.
• Interested in contributing code? Let us know!

We are working on making incremental progress and will share more soon. We will start using this project board to work collaboratively with the community on product prioritization. We also commit to better wiki and transparency on monthly planning. We know this isn’t everything you want to hear, but we hope it shows we’re serious about doing this right. We’ll keep sharing updates as we go.

Thanks for sticking with us 💙

[ghost1372]

Thank you @beth-panx
any news about WinUI Community Call?
#10520

also, Here, we have an excellent list of issues that need to be addressed.
microsoft/WindowsAppSDK#5250

[ne0rrmatrix]

One thing that I would find helpful is a clear separation on Doc's of what version of controls and xaml is in included in things like Maui. I am primarily a Maui dev and a lot of time is spent trying to figure out what docs apply to what I do. Example is Maui Community toolkit where I do work on Media Element. Figuring out which version of controls and what documentation from MS applies to device specific code for windows has been a guessing game for me since I started doing PR's for media element. A lot of time I just read everything I can find and apply what i can.

[jamespack]

One thing that I would find helpful is a clear separation on Doc's of what version of controls and xaml is in included in things like Maui. I am primarily a Maui dev and a lot of time is spent trying to figure out what docs apply to what I do. Example is Maui Community toolkit where I do work on Media Element. Figuring out which version of controls and what documentation from MS applies to device specific code for windows has been a guessing game for me since I started doing PR's for media element. A lot of time I just read everything I can find and apply what i can.

If it's a trade off between getting stuff fixed, new features, open source etc and better docs I'd rather see the former.

[beth-panx]

One thing that I would find helpful is a clear separation on Doc's of what version of controls and xaml is in included in things like Maui. I am primarily a Maui dev and a lot of time is spent trying to figure out what docs apply to what I do. Example is Maui Community toolkit where I do work on Media Element. Figuring out which version of controls and what documentation from MS applies to device specific code for windows has been a guessing game for me since I started doing PR's for media element. A lot of time I just read everything I can find and apply what i can.

Noted. One thing at a time. I am definitely aware that our get-started experience is not the best right now. It's on my long todo list. :)

[beth-panx]

One thing that I would find helpful is a clear separation on Doc's of what version of controls and xaml is in included in things like Maui. I am primarily a Maui dev and a lot of time is spent trying to figure out what docs apply to what I do. Example is Maui Community toolkit where I do work on Media Element. Figuring out which version of controls and what documentation from MS applies to device specific code for windows has been a guessing game for me since I started doing PR's for media element. A lot of time I just read everything I can find and apply what i can.

If it's a trade off between getting stuff fixed, new features, open source etc and better docs I'd rather see the former.

Yeah, definitely need to start fixing the issues. I hear you... I will start working those into future iterations. The corporate world is a big ship that sometimes doesn't turn as fast as we want.

[nikolayvpavlov]

Yeah, definitely need to start fixing the issues. I hear you... I will start working those into future iterations. The corporate world is a big ship that sometimes doesn't turn as fast as we want.

@beth-panx , this is really rekindling my hopes. We're now starting a project to overhaul a large LoB app, and as the architect, I am placing my bets on WinUI 3. I hope I won't have to regret this in a few years. :-)

[mdtauk]

Maybe the first community call back, should answer some fundamental questions after the long silent stagnation of WinUI and WinAppSDK.

• Who are the people directing the project of WinUI?

• How are future changes discussed and decided?
  (Perhaps there should be open live streamed monthly meetings so progress can be transparent)

• How many people in total are assigned to the WinUI / WinAppSDK teams?

• How much of a tie up is there with the Windows dev team, in terms of who directs who when deciding control changes and Fluent design?

• Progress on a XAML WinUI Designer?

• How do community members request APIs or Controls which don't currently exist, to be created and added by the team?
  (How can the community help prioritise what they want or need, when not coming from Microsoft internal users of WinUI?)

• How long will the current teams be in place, before a future change of team, re-org, or change in priorities once again?
  (Trust in the platform and WinUI 3 specifically is in the doldrums right now, many suspect unless a project within Microsoft is AI focused, it is expendable and de-prioritised)

• Where does any big thinking come from these days? Replacements for Xaml, A C# equivalent of SwiftUI, Dev tooling, etc
  (Back in the day big ideas like Avalon (the original WPF and Xaml) and .NET would be developed. But today it feels like Web is the primary focus, and everything else is just maintanence)

[beth-panx]

I hear ya... although I have no control over reorgs, I will do my best while being with the project. And these are things we should discuss transparently for sure. Made notes for the next community call. Thanks!

[mdtauk]

I understand re-orgs are decided higher up, but the lack of consistency and continuity with these projects, does dampen any hope and excitement that WInUI 3 will see performance improvements, future feature gaps filled, and at a point where developer needs can be met. As things like the WinUI Designer are big projects which will need time and resource to make happen.

An eye on a 1-2 year plans, as well as longer term multi-year plans - will be needed to give confidence that this is a project that can not only reach a maturity level - but can also play a part in the future of Windows itself. Windows 12 if it happens, should continue the trend or replacing outdated UI with WinUI 3 or WinUI 4 etc.

[conceptworld]

@beth-panx Relieved that WinUI is very much alive and also there are people behind it listening. Love WinUI.

[beth-panx]

Thanks for the words of encouragement! 💖

[HotCakeX]

This is a great news for me. I love WinUI3, built 2 fully featured apps in the past 8 months with it. Naturally, seeing Microsoft investing in it more and using it in their own apps (recently the Copilot app) is a good sign.
What I'd like to see is the team prioritizing fixing existing bugs and issues over developing new features, at least until a big chunk of the existing bugs are fixed, especially those that are critical. Thanks.

[knightmeister]

I've been heavily invested in WinUI for years now. I sold it to our organisation as part of our modernisation efforts and we embraced it.

To be frank, I don't think Microsoft understands the damage they have caused to the evangelists and wider developer community, along with the companies who have embraced the never-ending stagnation and false promises from WinRT->UWP->WinUI/WASDK. We still don't have a working solution for input validation and basic things like modal dialogs are buggy - how exactly is a LOB application meant to work with such severe limitations?

Our company has been building Windows clients since Win3.0. We are not doing any Windows-first development anymore because of the lack of transparency, lack of progress, lack of accountability, lack of direction. WinUI is now ~15 years old if you count its evolution from Win8 (and I suspect parts of it date back to DirectUI in XP) and you're orders of magnitude behind Apple's operating systems. How is it that they can iterate and add new features so quickly and yet WinUI is still riddled with shortcomings and bugs?

@mdtauk has raised some great points and I'd love to see answers to all of them.

I'll add a few more to the list:

• It's been clear for ~18 months at this point that devs are fed up that there's been no transparency or communication coming out of Microsoft. Ohh...WinUI3 is really dead! - When can we expect the announcement? #9417 was raised in Mar 24 and has 580 comments. Why has it taken until now for it to be addressed?
• Is Microsoft planning on having the community develop the platform for them given their lack of investment?
• When will Microsoft begin triaging issues and updating the backlog of issues?
• Will Microsoft guarantee they won't bulk close 1000s of issues again?
• How is this proposed change of direction any different to any of other comms we've seen over the years about doing things differently - when will things actually progress?
• When is there going to be an updated roadmap?

Forgive my cynicism - I hope to see this project succeed but based on what I've seen over the years, I don't have high expectations.

[knightmeister]

I'd take a different approach - Microsoft should proactively close all existing issues and restart the tracker.

I see merit in this but honestly there are so many longstanding bugs and feature gaps this would erase. I think a better compromise would be for someone on the team to triage. Anything without a concrete reproduction should be flagged and given ~30 days for the author to repro and provide a repository link. No doubt there is a lot of noise in the issue tracker but I'd still wager we lost a lot of relevant bugs and features in the previous bulk issue closing.

[goowy-maker]

It wasn't too long ago that Microsoft did exactly that -- they closed out all the unfixed bugs and started from scratch because the sheer number of bugs was too overwhelming for them to go through. They stated this on a Community Call at the time. So what happened? All of those unfixed bugs must have been re-submitted.

[riverar]

@goowy-maker That's not accurate; they didn't close all the bugs.

[weitzhandler]

Ppl spent hours creating quality issues and repros. The minimum you can do not to spit in their faces is to at least triage ALL of the issues.

[pjmlp]

They didn't, but there was an attempt to clean up old bugs, #8638 and two years later I would assert there are more open tickets than in 2023 when that post was made.

[pjmlp]

Honestly, this looks like outsourcing whatever is left from WinUI and wish whoever still believes Microsoft is serious about WinUI good luck.

You guys never have taken seriously how much the whole tooling and rewrite demands, since Windows 8, have burned all the good will from Windows developer community.

There is hardly any reason for a business to invest a new application into WinUI as foundation for their business.

It can't even match the features from UWP to this day.

[Panda-Sharp]

Apple apps use WinUI

Funny (not funny anymore), Apple (an other companies), use Windows native frameworks, Microsoft apps are web based instead.

[TimexPeachtree]

Sorry to say but some news has come that WhatsApp which had a perfectly good native Windows app with quick response and native speed and productivity (and every power windows user was praising how good it is), is now going to make their beta App a Web Wrapper App.

[mdtauk]

Sorry to say but some news has come that WhatsApp which had a perfectly good native Windows app with quick response and native speed and productivity (and every power windows user was praising how good it is), is now going to make their beta App a Web Wrapper App.

Meta has a multi-platform mindset, and moving from WinUI and a separate branch of code, they probably see usership not strong enough to warrant that, compared to a PWA approach. I am not sure its a judgement on WinUI, but I can't speak for them.

[Panda-Sharp]

And even more funny (not funny), same Microsoft apps that are web based on their own OS (where they have their own native frameworks), are native on other OSes... For example new outlook, that didn't even work offline when it went GA, It's native on Mac OS.

[nikolayvpavlov]

You are very correct that WASDK requires serious investment in man-power to improve stability, fix issues, and develop new features. While OSS may help, esp. w/ bug fixes, new features and deep stability improvements require a dedicated team, and good roadmap management. The latter seems dearly missing right now.

[goowy-maker]

It's time for Microsoft to admit that the entire WinRT (and its follow-on WinUI) idea was a mistake. It has its roots in the Windows 8 fiasco. There were a lot of bad decisions made back then and WinRT was one of them. Like trying to rebuild .NET natively (and differently!) in the OS where .NET languages take a performance hit calling into a foreign ABI and paying for interop costs and losing native .NET performance features. The whole thing was built for language projections and after all this time they only support two languages with WinUI? C++ and C#, neither of which integrate well. The fact that they gave up on adding Rust support for WinUI in a system that was supposed to be designed for such a thing speaks volumes. Just move on from WinRT and WinUI (and put XAML in moth balls too) and give us something like Flutter, Jetpack Compose, or SwiftUI. Something where you don't have to deal with multiple languages to create a UI.

[pjmlp]

@legistek WinRT is the child of Steven Sinofsky, that belonged to the anti-.NET faction on Windows development.

They "rescued" Longhorn, by turning all .NET ideas into COM, coming out with Vista, and doubling down on COM as main API delivery mechanism for Windows since then, which is why we ended up on WinRT, thus that was to be expected.

We can now compare how this all went down, versus how managed runtimes on userspace look like on Apple and Google platforms, and clearly see that the main reason why Longhorn failed was leadership, not technical.

[legistek]

WinRT is the child of Steven Sinofsky

Yep. Who got pushed out after the Windows 8 debacle. That was the opportunity to cut their losses and go back to the drawing board. And yet they couldn't bring themselves to drop the WinRT code branch and just go back to WPF. Inexplicable.

[HMO-SOUL]

Both wpf and winform use com though

[nikolayvpavlov]

Both wpf and winform use com though

Not quite true. Both use COM only when interacting with the Shell (including drag & drop) where the API is COM-based. For the rest, both make no use of COM. WinUI / WASDK, though, heavily relies on WinRT, which is based on top of COM.

[goowy-maker]

but the Longhorn project has shown us that building the system directly on dotnet is not feasible

Maybe it wasn't feasible 24 years ago, but it certainly is now. Android has shown that a system designed solely to run apps in a VM works very well. If Microsoft had embraced C# as the primary language for Windows apps (and forget about language projections for a native ABI) and focused Windows to be primarily a .NET host, they'd have been in much better shape. They should have moved away from COM and WinRT after the Windows 8 failure and moved to make .NET the primary operating environment for applications and supporting system services. Instead it now looks like the web browser is the primary environment for Windows desktop apps which is really a pity because .NET is so good.

[testdevnz]

Stop wasting financial and environmental resources on developing laggy garbage. Either fix the fundamental issues with performance and mouse wheel scrolling that hurts the eyes, or resurrect UWP and .NET Native

[testdevnz]

On the left is the UWP, on the right is the winui 3. Does it hurt your eyes?

12346.mp4

[MPITech]

Too early to know if we made a mistake, but we are developing a large application in WinUI that connects to MariaDB for the backend using EF Core. The lack of decimal support in XAML binding and in the WinUI controls has been killing us. I know someone was working on decimal support for 1.8, and thank you for that. Will that be in the final 1.8? Will you be able to bind decimal values directly to the existing or a new NumberBox control without using a converter?

You said to keep sharing feedback, so I am 😄 And please don't make me feel any worse about choosing WinUI3, it is a great platform, I just wish we had things like decimal support, input validation, window switching that wasn't so buggy, and a designer in Visual Studio. My life would be complete. 😄

[MPITech]

It looks like from my inquiry on the WinAppSDK site that there are no immediate plans for a decimal NumberBox. Syncfusion has told me they may try to come up with one in the coming months for those who have their control package, but it was suggested by @dotMorten that I lift the current NumberBox and replace all double refs with decimal to see if I can come up with my own. It looks like that may be what I will have to try next because it has been way too long, being forced to only bind to double values.

[dotMorten]

So I took a little stab at it: First I ported the NumberBox to C#, and after that made a generic version of numberbox, so that I can create subclasses like public class NumberBoxDecimal : NumberBox<Decimal>. Seems to work great with my limited testing. See my branch here: https://github.com/dotMorten/WinUIEx/tree/NumberBox/src/WinUIEx/NumberBox
Let me know what you think. If it does the trick and serves your use-case, I could probably include this in an official WinUIEx release (donations not required but welcome 😉 ).

[ghost1372]

@dotMorten
Last night I was porting the NumberBox and it was half finished. Today I saw that you did it. Thanks.😁
I would like to use your port if you don't mind.

[MPITech]

@dotMorten @ghost1372 You guys are AWESOME. I looked at the NumberBox code yesterday to see if I was going to be able to do it and I didn't know where to start with the C++ code. I can't wait to try it out after I wake up a bit. 😄 Thank you so much guys.

[Lightczx]

That's how microsoft force me to learn cpp. I didn't know anything about cpp before I use WASDK.
After using this, I have to port stuffs like MicaBackdrop/DesktopAcrylicBackdrop(and other) to C# to neutralize the impact of slow and content-less release schedule.
There are alose experimental things like ContentExternalBackdropLink/ContentExternalInputLink/IAppWindowExperimental only present in winmd, not in projection dll...

[Lightczx]

I personally seriously want the Microsoft.UI.Input.dll to be open source.
Most issues we and our users facing rooted here. I have to open IDA to jump to the faulted rva to see what's going on in the so called "proprietary layers" and finally find out it's an assert failure for the internal state of a COM obj and immediately fail fast.

[riverar]

What do you find as a result of your debugging and what do you do with that knowledge?

[Lightczx]

Some of them only happens when a debugger is attached and very hard to get a repro, the default winui template code plus repro codes(guessed) turns out just works fine.but if you check out my pinned repo it just can be constantly triggered.
As I am not a professor of asm code(and decompile stuff) I basically did nothing and just hoping a ranfom refactor(on my side) can randomly address those issues.

[NicholasChrzan]

If we are interested in contributing code to help move this forward is there a process for that?

[michael-hawker]

We're still in phase 1 right now, the code in the repo is basically overwritten by the internal mirror (that frequency will increase once 1.8 is released); so, if you somehow manage to validate and submit a PR it needs to be copied to the internal repo instead of being merged in here (a big part of the goals of this work to change that). If it's something small like a XAML template change, then those can be easy enough to copy, but do still involve some work.

But I think you're talking about the process of phase 1 itself; unfortunately, by the definition of why things aren't currently open source called out above in the original post. The underlying layers are things that are not exposed, that's why it's not completely independently buildable. I'll defer to @azchohfi and @codendone if there's anything they can think of, but I think it's just a matter of getting through the checklist of items. Once tests are exposed in Phase 3, then I'm sure there could be some additional improvements there to the coverage of tests or modernization/standardization of tests that could be discussed. (For instance, we've developed some nice setups for doc, sample, and test development in the Windows Community Toolkit, but the infrastructure for WinUI is much more complex.)

Ultimately, that's what getting through the phases enables. Once we hit phase 2, you should at least be able to build locally to validate changes from checking out the repo. And by Phase 3 or 4, we'll be in a place to directly accept contributions through PRs.

In the meantime, contributing to docs, or the docs/samples in the WinUI Gallery repo, or just going through issues that need more information to help drive clarity or minimal repro projects would be a huge help. Thanks! 🦙❤️

[xbjfk]

WinUI has deep roots in Windows. Parts of the codebase touch proprietary layers that can’t be published as-is. We’re working to separate what can be shared from what can’t. This work is in progress and takes time.

I hope that this will also help resolve #2488, in particular where it was mentioned that there are too many breaking changes at the WinUI level.

Overall I agree that the priority should be fixing critical issues, however I believe that going towards fully open source can help with this.

[beth-panx]

Hey everyone – I wanted to share a quick update on WinUI going OSS. Since our announcement, we’ve been making steady progress untangling the codebase from proprietary layers in preparation for both Phase 1 and Phase 2 outlined in the original plan.

Because WinUI’s shipping schedule is tied to the Windows App SDK, our branching strategy now lets us start completing PRs alongside the upcoming WASDK 1.8 release. The 1.8 Preview shipped on August 19, and the stable release is coming soon, which gives us the right foundation to begin integrating changes. With that alignment, we’re targeting early October for completion of Phase 1.

Phase 2 is still in active development, and while we’re treating it more cautiously, we hope to share tangible progress soon.

Thanks again for your patience and continued support.

[AndrewKeepCoding]

Hi @beth-panx, thank you for the updates!
Just out of curiosity, for “Phase 2: 3rd Party Devs Build Locally,” do you currently have any rough requirements for machine specs? For example, disk space, memory, etc.

[weitzhandler]

Hi @beth-panx
I just wanted to say thanks for these updates and communications; they are a breath of fresh air, especially after such a long period of silence and neglect from Microsoft.
A lot of people completely lost faith in WinUI and XAML, so it's extremely important that you keep this channel open and steady, and stick to your goals.
This community is one of the most loyal people Microsoft has ever had. I believe we are mostly people who have been around since the birth of XAML and Silverlight and are very enthusiastic about original WPF/WinUI XAML (not MAUI). We've been sticking around all along and yet we're still here.
The least we deserve is clear and transparent communication about Microsoft's plans for XAML and Windows development.

[nikolayvpavlov]

I fully second @weitzhandler. We are the die-hards of native app development, who are still trying to bring apps, i.e. value, to Windows. And yes, we don't like MAUI, we don't even believe in it. If there is a cross platform with value, that is Uno. Microsoft should buy Uno, provide a migration plan from MAUI to Uno, and invest into WinUI and Uno.

[weitzhandler]

The best thing that ever took place in the XAML arena since SL is Uno Platform.

[beth-panx]

Hi @beth-panx, thank you for the updates! Just out of curiosity, for “Phase 2: 3rd Party Devs Build Locally,” do you currently have any rough requirements for machine specs? For example, disk space, memory, etc.

The repo itself calls for about 80GB disk space for a single build flavor (this could change, so don't quote me on it). You'd probably want to consider OS and Visual Studio install and other dependencies if creating a VM. It is a real project after all, so it requires sufficiently powerful dev machine. I was able to build it on my 32gb RAM laptop. 😃 This is something we should document after 2nd phase for devX and contributing guide... Good reminder!

[Slion]

Nice initiative, could you please also release WSA as OSS?