Ohh...WinUI3 is really dead! - When can we expect the announcement?

[softworkz]

Yesterday I made a post (Great News: All Bugs Will be Fixed In the Year 2041) which was meant to be a somewhat funny complaint about the lack of activity in terms of development progress and dealing with user issues submitted here.

Then I made a comparison of activity between WinUI3 and MAUI and those figures are quite revealing when thinking about it:

How can it be possible that MS is investing 20 times more effort into MAUI than into WinUI3 - the new and designated primary UI technology for Windows desktop?

Simple answer: It can't. It can only be possible in case when WinUI3 is no longer the "designated primary UI technology for Windows desktop".

Now I'm shocked to realize that it's way more serious than I thought as so many details suddenly fit together and make sense when being viewed in the light of that premise.

It all fits together

Smaller Bits

• No substantial official statements or responses are being made on GitHub anymore
• The Product Board is outdated and no longer maintained
• The hard drop of WinUI2 support wouldn't have been needed when still working in WinUI3, because large parts of WinUI2/3 code are identical, so certain fixes to WinUI3 could have easily been applied to WinUI2.
• The whole architecture behind this is ridiculously complex, all the projections, WinRT, the insane build system for the WinUI3 code, etc.
  • Experience is so inferior compared to .net based implementations - for both, framework consumers and developers
  • Inability to ship a visual designer (surely also due to the aforementioned)
  • limitations in the composition architecture (no external content overlay)
• Adoption from component vendors hasn't been great

Xbox Development

• No announcement has been made regarding the future of Xbox development
  • UWP is dead
  • WinUI2 declared as unsupported from one day to another
  • WinUI3 doesn't work on Xbox
    => but Xbox is not dead. So the must be something for Xbox which is not WinUI3

Cpp/WinRT in Maintenance Mode

as noted by @pjmlp (thanks!):

[..] leaving C++/WinRT semi-officially in "maintenance mode": microsoft/cppwinrt#1289 (comment).
Let this sink in, the main tool used to develop C++ code for WinUI, that C++ users are supposed to use in case they feel like touching WinUI 3, is in maintenance mode, without any roadmap to support anything beyond C++17, in fact there is a closed ticket about microsoft/cppwinrt#1123, while C++/CLI supports C++20.

Component Vendors

DevExpress are offering a few free components but these haven't been updated since mid-2022.
Their blog entries about WinUI3 stopped in mid-2022 as well (https://search.devexpress.com/?m=Web&q=winui3)

They probably know already about the end of WinUI3.

Timely Coincidence

Wasn't it at the same time (2022) that WinUI3 development had started to be driven down?

XAML Islands as a WinUI3 Exit Strategy

When looking at the changes that were made during the past year, then there's only one area where significant work has been put into: XAML Islands. Even though it had been requested by users earlier, it's not a most-wanted feature, but still, MS picked exactly that part as the one major subject of work.
XAML Islands allows to integrate WinUI3 content as "islands" when using other UI frameworks. Why is this so important? Who needs this other than a few with very specific use cases?
When customers want to modernize their applications, who would start by implementing something in WinUI3 which is then shown like a control/window within a WPF or WinForms app? Normally, such migrations would rather go the other way round: starting with a new application framework and subsequently migrating legacy components. But that's what is not being worked: There's nothing like a hWnd-Panel (which had also been requested by users).

Bottom line: When establishing a new framework for app development, then it's usually crucial to provide ways for developers to integrate legacy components into the new framewrok to allow subsequent migration, but not the other way round. Provisioning for the other direction only (and also as the only major change) can only mean that this is the end of the road for WinUI3, and XAML Islands are just implemented to soften the impact for affected developers enabling a life-after-death existence for WinUI3 components.

MS, when did you plan to make the RIP announcement?

And what will be the replacement?

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Closed similar issues:

• Announcing WinUI 3 Preview 3! ✨🎉 (#3620), similarity score: 0.75
• Announcing WinUI 3 Preview 2! 🎉💻 (#2917), similarity score: 0.75
• Question: What is going to be in WinUI 3? (#1412), similarity score: 0.74
• Announcing WinUI 3 Preview 4! 🎉 (#4156), similarity score: 0.74
• 📢 Announcement: Next WinUI Community Call on March 16, 2022 (#6726), similarity score: 0.73

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[softworkz]

Component Vendor Support for WinUI3

All the component vendors already know it.

Telerik

The two "under review" haven't been updated since about a year.
All accepted features are set to "Unplanned"

Ref: https://feedback.telerik.com/winui

Syncfusion

The WinUI roadmap for 2024 includes only improvements to shared components (i.e. improvements are made for multiple platforms) but nothing specific to WinUI3 controls.

Ref: https://www.syncfusion.com/products/roadmap/winui-controls

DevExpress

They are explicitly stating that their WinUI3 components are dead:

Ref: https://supportcenter.devexpress.com/ticket/details/t1206625/winui-3-the-roadmap-in-2024

[NicholasChrzan]

I think that the comments on the link above are the most telling:

[Neme12]

@NicholasChrzan Wow...

[LudoTexx]

Honestly their a lot of reasons, maybe the client do not want anymore a GUI who look like Windows XP ?

And DevExpress WinUI component is free while WinForm cost 999$/year, so Devexpress will not push clients to use a free component

[softworkz]

maybe the client do not want anymore a GUI who look like Windows XP ?

Hardly anybody uses the built-in WinForms controls for professional applications these days.

And DevExpress WinUI component is free while WinForm cost 999$/year, so Devexpress will not push clients to use a free component

Probably you haven't read everything: They stopped development. And they always do like this when they are starting to target a new platform: The initial versions are free for a while until it's mature enough to charge for future versions. MAUI controls are free as well, for example, as it's still in development.

[LudoTexx]

And they always do like this when they are starting to target a new platform: The initial versions are free for a while until it's mature enough to charge for future versions.

Ho, was not aware about this. My bad.

[softworkz]

Consequences

If this turns out to be true, this would be a severe incident:

1. You owe me two days of work

For creating the Pull Requests, since I didn't know that they'll be never even looked at due the product being abandonded.

Same goes for the effort that so many people have taken in order to submit bug reports or create design proposals.
You have been watching everybody doing it, even though you knew that they will never be worked on and fixed.

2. Have Microsoft Representatives been Lying to the Developer Community?

This needs to be evaluated. Behaving as if all would be fine and the product would be continued is quite close already.

And I recall statements like "all developers are working on WinUI3 now" which I think were made after 2022 and after stopping development (largely),

When the UWP bugs were all closed, it was promised that issues will be better handled in the future and it won't happen again.
IIRC, this was also after 2022.

[DitherDude]

WYSIWYG for WinUI3 says looking into it... but the only "official" microsoft feedback is the automated message when creating a topic, and a bot message for a deleted message. MS fixed a Co-Pilot bug that was reported witin ~a week, can't we be notifed that at least they are doing something?

[ChaimCL]

Let's think about the crazy future where blazor rules next. There's also a possibility that they really have very few resources, and it's hard to be convinced that it's really production usable until ms actively migrates the existing own app. I'll wait until it supports NativeAOT before I try it.

[softworkz]

There's also a possibility that they really have very few resources

If WinUI3 would be the future #1 desktop UI framework, then they wouldn't be assigning 20 times more dev resources on MAUI. The required qualification is not that different and MAUI cannot be a higher priority project than a native Windows UI framework which neither MAUI nor Blazor is.

[GF-Huang]

Have Microsoft Representatives been Lying to the Developer Community?

They also once said that Win10 is the last desktop version, but the person who said this has been fired.

[ChaimCL]

I don't think so, it looks like a technical reorganization, nothing is brand new (uwp equivalent). Apart from the fact that I can't figure out why the designer isn't being offered, but it's very much trending the blazor of the dotnet community looks like it's going to win this one.

[softworkz]

If you read through the issues here about it, you'll find some comments from a (now Ex-)MS developer exlaining why it's a huge task and why the UWP designer cannot be built upon.

[knightmeister]

WinUI is mismanaged and woefully understaffed. I wrote a post up a while ago which got a lot of traction.

Either close this repo and make it internal only and pretend that it's under active development or put it out of its misery.

I love WinUI and it had great potential and traction but all good will has been lost by the lack of comms out of Redmond.

Remember as well this whole UI framework and stack (WinRT) is as old as Windows 8. DPs of Win8 were available in 2010 or 2011. That makes the tech at least 13 years old. Appalling when you consider how much Android and iOS have iterated over that time.

[softworkz]

I wrote a post up a while ago which #8712.

I know it very well. ❤️ Your post had "inspired" me actually. After I had read it a few days ago, I had started investigating the actual dev activity which ended up in this: Great News: All Bugs Will be Fixed In the Year 2041, after which I dug deeper as it all didn't make sense to me.

Remember as well this whole UI framework and stack (WinRT) is as old as Windows 8. DPs of Win8 were available in 2010 or 2011. That makes the tech at least 13 years old. Appalling when you consider how much Android and iOS have iterated over that time.

Maybe that's one of the reasons for the decision to create something new (which I'm inclined to believe).

[softworkz]

My suspicion is that they have pulled off the majority of developers to work on something new. Maybe they'll call it WinUI4 to make the whole story not appear even worse than it does already, but it must be on a very different technical basis. If it was a continuation only, they could have backported fixes and wouldn't have to invest into Xaml Islands. Also the component vendors wouldn't have had to pull their efforts if it wasn't something technically different that is coming.

And it's clear that something must be coming: the framework gap on Xbox needs to be filled. App development for xbox is not abandoned, WebView2 for Xbox has just been released in November and UWP is been given up, so there's an obvious gap as Xbox is meant to stay.

[softworkz]

The strongest evidence of all is the component vendors' behavior. I mean, MS doesn't make a call to DevExpress like "Oh, we just wanted t let you know that WinUI3 is dead. Sorry for your wasted effort. Goodbye". It would rather be something like "We want to have you on board from the early stages on while we are developing a successor technology to WinUI,"

Another reason from which I find it very plausible that they switch onto something new is the WinUI3 source code and build system; When you see that and move a little bit around everywhere, then - at least in my case - you'll just want to run away and do something else... ;-)

[ChaimCL]

The strongest evidence of all is the component vendors' behavior. I mean, MS doesn't make a call to DevExpress like "Oh, we just wanted t let you know that WinUI3 is dead. Sorry for your wasted effort. Goodbye". It would rather be something like "We want to have you on board from the early stages on while we are developing a successor technology to WinUI,"

This could be a good thing, the future could be the realm of declarative UI frameworks and blazor, which could be echoes of Longhorn from twenty years of unfinished visions (everything is dotnet). I have no doubt about that with their now frantic embrace of web technologies.

[softworkz]

Now and in the future, there are and will be many UI frameworks. But this is about the operating system's native UI framework, i.e. by which the OS components themselves are developed, so I doubt that it will go in any such direction like web. But a .net-based rewrite of WinUI3 is something I could well imagine. It's actually my nr 1 theory.

[Neme12]

Also the fact that they even converted this serious issue to a discussion to show us how much they don't care: #9154

...Or at least they don't care that this UI framework is only usable for simple mobile-like apps and don't care that it's unusable for any complex business application. I seriously doubt that something like Visual Studio could be made with WinUI 3, so it's not a replacement for WPF.

[softworkz]

Prediction

Whenever they will respond to this, directly or indirectly, one of the first statements will of course be saying that WinUI3 is not dead and will continue to be supported till the end of days (or at least according to the OS support periods).
Maybe it will even be said that it will continue to be worked on (which doesn't mean much, given the snail-pace at which it is running already).
Then it will be said, that future focus is on XYZ, though.

(Yet, that's what I mean by saying that it's dead)

Note

I have no insider information on this subject. If I had (like at some occasions in the past), I wouldn't post about it. It's solely based on observation, inference and deduction (and experience from similar cases). There's a chance that I could be wrong, but I don't think so.

[Neme12]

Unfortunately I think you're right. I just really hope they don't go the web route, even for native apps. But even if they don't, the fact that they're creating yet another UI framework/application model is just... They keep making new and new ones and then replacing them with new ones just 3 years later, and those who invested in the previous technology are s*** out of luck. First (that I remember) Windows Forms, then WPF, then Silverlight, then Windows Phone + Windows 8, then UWP, then WinUI 3… all incompatible with the previous ones. Oh and in parallel, Xamarin and then MAUI. I’m afraid it’s going to happen again to WinUI 3… And then Microsoft says that they "care about compatibility".... while leaving developers who are stuck on the previous thing behind. This isn’t how to treat your developers well, Microsoft… Can’t they for once stick to a single framework and work on making it the best it can be, and making the developer experience the best it can be?

[softworkz]

Yes, but not always a monetary one 😉

[softworkz]

Hmm...could that be the news: MS buying AvaloniaUI?
It would answer all questions here and also align with WPF having a new team and a new roadmap.

The Avalonia site is also prominently advertising support for the component vendors' controls. I'm sure they cannot solve everything from their own side only, it requires collaboration with them, which means in turn that those parties are investing effort in this direction.
Yet, the business model is not for the masses, so why would they do that? Unless they'd know something we don't know.

[softworkz]

It would also fit into the timeline. I dug out whe roadmap document from the history where it was said that there's a new team: https://github.com/dotnet/wpf/blob/be08c08b0cddfe075b8535ab7b3b591113d2f3c2/roadmap.md
This was at the beginning of 2023, so it would perfectly fit into the picture that some decision has been made in 2022.

[Neme12]

Hmm...could that be the news: MS buying AvaloniaUI?

I really don't think so. And even if they did, they probably wouldn't abandon their flagship native UI framework. Lots of people write native apps. There isn't just .NET out there. And Windows apps themselves need to use something and most of them are not C# (although I know Microsoft Store is (was? not sure if it still is))

[softworkz]

Agreed that it cannot be a replacement. It's merely a question of focus.
In that case, WinUI3 would probably continued to be cooked on low heat - just like now.

[ghost1372]

I should mention that the WPF team has recently been activated and is providing WinUI 3 styles and controls.
So If this is done, who will use WinUI 3? I think no one.
Because:

• Styles and controls exist in WPF
• We can use WASDK API in WPF
• WPF can be run on Windows7+ which WinUI 3 cant.
• WPF is updated with the release of new versions of .NET, so we don't need to wait for updates, unlike WinUI 3, which needs to be updated.
• WPF does not have the limitations of WinUI 3, especially in the Windowing
• I should also mention, the presence of the designer, faster compilation, faster execution

Also, I must mention that there have been good changes since wasdk v1.5 and we will have good changes in 1.6.
It seems that the main problem is the development team, whose number is probably very limited. It is better to hire some Indians to solve the problem.

[softworkz]

WPF does not have the limitations of WinUI 3, especially in the Windowing

Yea, in no other Windows UI framework I had to send WM_CLOSE to my own window to close it
(without exiting the app - as Window.Close() doesn't do the same like a click on the titlebar close button)

[Neme12]

WPF can be run on Windows7+ which WinUI 3 cant.

And more importantly, it can be run cross platform, even on Linux, thanks to Avalonia XPF, like I said in #9417 (reply in thread)

[ghost1372]

It's a civil war at Microsoft, and the winner is the WPF

[roxk]

faster execution

This is false. At least for C++ :p

[brabebhin]

WPF is aging, and unless they rewrite the backend to directx 11/12 and fix the performance issues, it is unlikely to be the framework of the future, as much as I would like that.

Supporting the styling of winui is just a solution to make legacy Microsoft WPF apps blend in with the new stuff.

[LudoTexx]

[Neme12]

Sound like there's no improvement from UWP and it's still the same (buggy and half finished). I feel your pain. That's a tough situation :/

[LudoTexx]

Yes, it is sadly, but kind of my fault, wanting to use the latest technology for some UI improvement and specially trusting MS on new tech perennity.

[softworkz]

My program crashing randomly cause of coreclr.dll, random ExecutionEngineException

Despite of all ranting about WinUI3, I need to say that 99% of such "crashes" are due to the way you are coding. In most cases, these are caused by threading and the way you handle events.
It's a common practice in .net based UI frameworks to "misuse" threads which are firing events that you've registered on, for performing application work. In COM based environments, this is generally a no-go. The golden rule is to do just minmal work within event handlers and let the event callback go as early as possible. Practically, speaking, schedule the work on the DispatcherQueue instead of performing it directly. e.g.:

        private void UISettings_ColorValuesChanged(UISettings sender, object args)
        {
            this.DispatcherQueue.TryEnqueue(this.UpdateTitleBarColors);
        }

The DispatcherQueue is often presented as a measure to perform tasks on the UI thread. But another important use case is decoupling of event callbacks, which means that you should even use it in cases when the callback is on the UI thread already. It's not always needed, but unless you have gained some experience in which cases it may be needed and in which it's not, your best bet is to follow this rule unconditionally.
For some events of the framework, you will see that the event arguments have a .GetDeferral() method which you are supposed to call in cases where the handling of an event can go over a longer period: You acquire the deferral object and use it for later completion, but you still let the event thread go immediately. This is a very different pattern from .net, where it rarely matters what you do and how long an execution path remains rooted to the handler routine.

When you are interacting with hardware and there's COM somewhere in-between your application code and the hardware, and you are receiving events from the hardware, keep this in mind as a general measure. A while ago, I've been working for a company who have a WPF application that is inferfacing with a range or hardware through different interfaces and in one case, they've been struggling for years with instabilities in hardware interaction. When I told them how it can be fixed, no one believed me, saying they had tried everything already and it would be MS' fault (and between the lines kind of "none of your business anyway").
Eventually, I had changed the code accordingly and their long-standing problem was fixed by this simple rule: "Don't do stuff inside event handlers when COM is involved" (or WinRT to some extent).

[roxk]

What's the point of this post? Don't think anything meaningful would come out of this.

WASDK 1.5 and 1.5.1 was just out. Community call on 1.6 roadmap is posted. Are you some kind of PR guy to sabotage WinUI just to advertise WPF?

[softworkz]

Not at all.

I've been frustrated that my PRs are ignored and no action is taken on my and others' bug reports.
Then I looked deeper and realized that something must have happened which is not officially told (yet). If you have watched the community call, there were 4 or 5 people involved, but the work that has been done between 1.4 and 1.5 (about 6 months period) is even less than what a single developer can do in half a year. Another strong indicator is that the component vendors have jumped off, and these are usually the first (outside MS) to know when some new UI stuff is coming.

And what I want is to be informed earlier in order to avoid investing into a technology with a limited future.

[softworkz]

Also consider the following:

Until 2022 they've been pretty responsive here to all kinds of posts, which has ceased almost completely.
As a community manager, you are always interested to prevent any false rumors from coming up in the first place. But they haven't denied this in any way. Even though they did read it.
Now you could name a dozen reasons why they wouldn't respond, even something along the lines like "why should they answer to every little idiot posting some fantasies about world's end?".
But the truth is: denial is incredibly cheap when it's true, and easily done before even thinking about whether to respond or not.

Lastly: I have no intentions to paint a false picture and just talk things down. You have my word that I will deeply and sincerely apologize to the whole team and fellow developers in case when it would turn out that I've been largely wrong.

[gautambjain]

I feel the slowdown in WinUI 3 fixes and new features is because WinUI 3 is also the Windows component of MAUI. So in this process many bug fixes get postponed and new features/fixes are delayed due to the testing cycle on all platforms. Plus of course the most important is the compatibility between the management of these teams.

[softworkz]

If you would be right, then this would be reflected in actual code changes to WinUI3 in this regard, which don't exist. Aat least not at a scale that would match your theory.

[Neme12]

Why would that delay fixes and features? If anything, it should accelerate them because they're needed for MAUI.

[gitmixen]

Hello everyone, Mik from Windows team is here, thanks for starting the conversation.
As predicted above, I would definitely start with the statement that WinUI3 is not dead, I would even say that I see WinUI as the future of Windows desktop development.
In fact, we've just had WinUI Community Call a week ago when the team has shared the latest insights on what's the current priorities, latest controls update, performance tools and more, encourage you to check out - https://www.youtube.com/watch?v=uFgGhNGlPm4
We've also shipped WinAppSDK 1.5 and 1.5.1 in the last two weeks - https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-151-15240311000.

Now, it's obviously our platform is not in the place we want to be in the future - there is a big backlog of items that we need to triage and prioritize among different internal and external customers. One of the strongest feedback items we've heard consistently that Microsoft is not using the same technologies we are recommending to developers, and we are working on that too.

I think one other area your feedback attributes directly is that our platform is not fully open sourced, we make source code available, but there is not currently a way for community to directly contribute to the release. You can watch the discussion about this topic during our latest WinUI Community Call with specific details.

We continue to invest in frameworks Windows developers use. For example, we've recently shared our refreshed roadmap for WPF on GitHub - https://github.com/dotnet/wpf/blob/main/roadmap.md

Windows will continue to be an open platform for developers.
We are on this journey and value the feedback - please continue sharing it.
Thank you

[HEIC-to-JPEG-Dev]

ActiPro - one of Microsoft's partners and often promoted by Microsoft, has said they won't invest in WinUI (have officially abandoned UWP as well) and instead moved their development to Avalonia and WPF :(

[brabebhin]

TBH, despite all the reassurances we get every now and then, it is very likely web widgets will take over Windows UI, and there will be some sort of winRT projection to allow COM usage for hardware device access (like we had in win8). There's little interest at Microsoft to support anything more than that, since the business model under Nadella has been Azure and cloud, and now the AI stuff. C# and dotnet both prioritise web stuff. Consumer apps can afford the performance hit of web widgets, while directx will provide the high performance where needed. There's simply no room for WinUI, or a fully managed UI framework.

I personally have no idea what they are even trying to do with MAUI, since Microsoft's misguided mobile efforts are dead.

[pjmlp]

See Blazor being pushed everywhere, and regarding what you mention with Web and COM, Microsoft owns React Native support for Windows, which is what the XBox Dashboard has been rewriten, from its original WinRT implementation.

[Panda-Sharp]

One of the strongest feedback items we've heard consistently that Microsoft is not using the same technologies we are recommending to developers, and we are working on that too."

This is the worst part, not using your own native framework for your own first party apps, that should be a showcase of your own technology, it's a really bad that leads devs asking their selves: "why should I use this if not even Microsoft does?" ... especially considering that most of them moved to inferior, slow, heavy, pen&touch unfriendly web tech (including some OS controls).

[legistek]

One of the strongest feedback items we've heard consistently that Microsoft is not using the same technologies we are recommending to developers, and we are working on that too.

This is absolutely my No. 1 criteria and a potential dealbreaker. In the old days (MFC, etc. - yes I was there) - we knew your developer tools were golden because you were using them.

The primary reason I started getting interested in WinUI again is because MS is starting to actually use it more, including in the Windows shell. That plus 1.5 being a huge improvement I feel like things are starting to finally get on track and you have a viable contender for a WPF successor finally.

But here's my feedback for y'all - you NEED TO FOCUS. I feel like I'm looking at a menu at the Cheesecake Factory here. There are too many damn options and none of them has everything I need. I love WPF, and if you're gonna go with that one as the winner then go with it and kill RT once and for all. If not, let WPF die and beef up WinUI so it's at par. Or if you think cross-platform incl. web is the ultimate future then go all in on MAUI and for Windows put it on top a Skia or D2D renderer and kill everything else.

Regardless, please, enough with having 15 different flavors of frontend frameworks where none of them is rock solid. Even the most valuable company in the world can stretch itself too thin. You're like the Roman Empire, too big to govern itself. You need a single "Frontend Development" czar who can make sense of all this and unify it and assign the resources more sensibly. Instead you have a bunch of independent little kingdoms between Blazor and MAUI and WinUI and WPF and React Native and whatever the heck you guys use internally

10+ years after Windows 8/Metro disappointingly little progress has been made. All there are are more options, layers built upon layers, and none of which is the whole package.

[kingsznhone]

I'm interest in WinUI for about 3 years. But I don't see any advantage compare to WPF yet.
Windows App SDK have many UWP/WinRT spaghetti inside that make me lost my sanity.
What I'm expect is a "mordernize WPF " with cutting edge rendering pipeline and some often-used controls, sets of theme/style.
Rather than a spaghetti SDK with wrapper in wrapper in wrapper.

[ivanjx]

apparently it is being tracked here #6527. but to be honest this does not really affect my case since what i want is to overlay winui controls over the webview which other alternatives cant provide.

[yg-i]

The major downside of the WinUJ3 WebView2 is that it cannot be overlaid (with transparency) over other controls. All other webviews (win and non-win, UWP, WinForms, Win32, Android, OSX, iOS, WebOS, Tizen etc. etc.) can do that, just not the one for WinUI3. We had to go great lengths of research and experimentation to find a way around.

Do you know if this applies only to the WebView2 in WinUI or to WebView2 generally?

The IE ActiceX WebBrowser control not only allows transparency (by keying out a color) but allows mouse events (click & hover) to selectively fall through to the window below. I was able to get transparency working in WebView2 (outside of WinUI context) but never the desired mouse behavior available in the old WebBrowser controls.

[softworkz]

It's not a limitation of the WebView2, but of WinUI3 composition. The WebView2 sends its content with transparency, but on the WinUI3 side, transparent areas will be painted on top of the window background color. Due to the same limitation it's also not possible to have transparent content in a swapchain panel.

Transparency works in all cases where the WebView2 is rendered to a Win32 window (with hWnd) and also in case of UWP (DirectComposition).
The transparency doesn't work via color keying. You get real transparency with smooth blending according to what's transparent (and at which level, 0-255) in the browser.

For input event forwarding, there's no built-in way. Since no simple color keying is used, there's also no yes/no regarding whether an input even should be handled inside or outside. I see three ways to do that, though:

1. Handling in the browser
   You can add pointer move and click handlers to the window or body of the document and forward all events which aren't handled inside the html doc to the outside and process them there
2. Native handling in the outer app
   You can register (hook) to receive window message before they arrive at the webview, then you can determine in some way whether it's for the webview or the native app and forward it accordingly
3. Make sure that the native app receives the messages first, see whether it's handler there and otherwise post the messages to the webview for processing

[yg-i]

Wow, thank you for this very knowledgeable and helpful reply! I appreciate you pointing this out:

Since no simple color keying is used, there's also no yes/no regarding whether an input even should be handled inside or outside

It had not occurred to me that transparency via color keying (which is visually inferior, as you pointed out) was the very reason why the natural selective mouse fallthrough behavior I observed was so easily achieved in IE WebBrowser, and so there's a genuine tradeoff here, not just a bug waiting to be fixed by the WebView2 team.

I recently saw this Electron demo (must wait for gif to load, then click play) of exactly the mouse behavior I wanted (note how the mouse cursor is IDC_HAND when it hovers over the non-transparent regions in the Electron window, and how it changes to IDC_IBEAM (as that's the appropriate cursor for the vscode window below) when it hovers over the transparent regions.

electron/electron#1335 (comment)

Unfortunately its impact on performance is probably too great for the app I'm developing. Your option 2 is probably more suitable for my case.

Thanks again for the great explanation!

Edit: the link has been corrected.

[softworkz]

Unfortunately its impact on performance is probably too great for the app I'm developing. Your option 2 is probably more suitable for my case.

Well - in case of the demo - and assuming that the webview window has focus, there isn't much communication needed for changing the mouse cursor, because as long as the webview has focus, it's the browser alone to be in charge of changing the mouse cursor, so you don't even need to communicate with the outside for this.
If the cursor needs to also change depending on the layout (controls) at the outside, you could provide a map of them (like list of rects) to the webview and handle all there (maybe like until there's a pointer-down over such an element).

Option 2 would make sense if you want to use hit-testing functionality of the native side, but it would fail when elements inside the browser can overlap controls on the outside - which you can't know from outside code.

Last: Use web messaging for communication between browser and outside world (like PostWebMessage). It's async and capable enough to even transmit pointer-move events to the outside.
(but probably not for pushing all window messages unfiltered from outside to inside).

[NicholasChrzan]

It's good to see that there is at least one session dealing with Windows desktop application development. The reality is that WPF will be the favored technology for the foreseeable future and the windows app sdk (WinUI) will primarily be used for projects previously developed in WinRT/UWP.

WPF is simply more feature complete and easier to use than WinUI. It has much better window management and a working designer. In addition developers are going to have a lot pain if they try to convert any non-trivial application from WPF to WinUI. They'll need to be comfortable with calling into the Win32 windowing API and dealing with UI thread issues as WPF was much more tolerant of handling UI bound property changes happening on a background async thread. Developers converting from UWP will have an easier time because WinUI is essentially the same and things like the designer didn't work great, so they got used to working without one.

The real issue is that for Windows desktop applications WPF works just fine, so there isn't a real compelling reason to port existing apps to WinUI. There needs to be a real effort to make WinUI development easier and have more parity with WPF and reduce the need to hit lower level APIs.

[softworkz]

I very much agree, that's essentially the status quo: A life-after-death migration path for UWP applications.
The problem is just that this doesn't match the way how MS is positioning this, i.e. as being "the future of Windows Desktop Development".

But all indications a pointing in the opposite direction: It isn't.

🡆 Which brings us back again to the topic of this conversation

[brabebhin]

I very much agree, that's essentially the status quo: A life-after-death migration path for UWP applications.

Unless you are tied to file system access, which is absolutely horrendous in UWP, there's really no reason to bother yourself with winUI, cause everything that winUI can do, UWP will do better, faster, and with less bugs.

winUI3 still hasn't reached feature parity with UWP, and UWP has been sitting idle for 2 years already.

[NicholasChrzan]

WinUI gives you more than just better file access. The ability to target the latest .Net (if access to 8 has been fixed), multi-window support, and if you create an unpackaged app you can access everything that a "normal" windows application can (like Win32, or other C based dll libraries, and things like the registry). These are the primary reasons we moved our app off UWP and to WinUI 3.

[brabebhin]

If your application is functional in UWP, there's no reason to go to winui 3.

If your goal is to have a desktop application that can also access winRT, you also don't need winui3. Cs/winrt and cpp/winrt will do that for you. I suspect the majority of the WPF developers are in this boat.

You go winui3 when you need a desktop app that requires both win32 stuff and the unique controls that only exist in winui3/uwp, like the map control. Or you absolutely need a directx 11 flavored xaml. In this case, well, I'm sorry for you :(

[NicholasChrzan]

Exactly, we had a winrt/uwp app that we needed to interact with native third party Dlls that wasn't possible under the sandbox model that UWP apps ran under, so moving to WinUI3 opened up that functionality along with support for multiple windows was enough to push the migration.

[softworkz]

From a Different Angle: Looking at the API Side of WinAppSDK

So far in this conversation, we have mostly put it all into the same corner, even thogh there are two different parts that WinAppSDK is meant to cover:

• The UI Framework - WinUI3/XAML
• The "modern" Windows API as a replacement for the Win32 API
  (by this I mean both, WindowsSDK APIs and APIs from WinAppSDK, I'll further refer just as "WinRT APIs")

So could it be that we've been unfair by not differentiating accordingly?

Is it maybe just WinUI3 alone and all goes well at the side of the "modern" Windows API?

I say NO and I'll try to illustrate this with a tiny..

Developer's Diary

Over the past few months, I've been in charge of developing a new Windows version of a well-established hybrid cross-platform application to replace the predecessors (an Electron app for Win desktop and a WinJS app for Windows Store including Xbox).

Replacing it all with a single UWP application has been the original goal, but it soon became clear that we cannot achieve equality with the desktop app when using UWP and it also became clear that UWP would be a dead horse, so it turned out that we need two applications once again: WinUI3 for desktop and UWP for Xbox. WinUI3 was chosen due to the high similarity with UWP to leverage some synergy effects at least. The core application is htmljs based and displayed via a webview - it's the same on all platforms and the native side "only" needs to take care of platform-specific things, but there are a lot of them and it's way more involved than it sounds.

Due to the need to develop the same application for UWP/WinUI2 and WinUI3 at the same time and in parallel, I gathered a bunch of first-hand experiences to achieve individual tasks, not only regarding WinUI3 vs. UWP but also with regards to using Windows APIs and I'll focus on the latter because UWP is dead anyway.

WebView2 Transparency

In case of video playback, we need transparent overlay of the webview on top of the video. This is possible on every other platform you can think of, plus many others which you wouldn't even think of (e.g. smart tv's or more exotic platforms).
The one and only platform in the world where this is not possible is WinUI3 on Windows (due to the composition architecture).
The WebView2 team say they can't do anything, the WinUI3 team says.....(nothing - as usual).

The solution to get around this limitation was: To create a custom implementation of a WebView2 control which doesn't use composition but hWnd overlay within the WinUI3 window.
Of course this doesn't fly without using the Win32 API to manage the window relationships and z-ordering.

🡆 So what came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Splash Screen Animation

We have a complex XAML animation to show on startup. Unfortunately it didn't run smoothly, and even worse: it caused WebView2 startup to get stuck sometimes (sounds like a programming error but it's not). It's just too much happening on the main thread on startup - not in the app code though (WebView2 COM invocations).
Solution: Show the splash screen on a different thread - but this is totally unsupported. What's supported though are XAML Islands. But these are meant to include WinUI3 XAML in a Win32 application, not in a XAML application itself. But hey, then create a Win32 Window in our own app to show the XAML island content (running on its own thread) and then make that window the top child of our app window and we got a threaded splash screen - with the help of the Win32 API.

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Video Player Integration

We are integrating a custom video player which is layered below the (then transparent) WebView2. It must be resized and properly positioned in z-order. Also, we apply rounded corners in non-fullscreen mode to match the rounded corners of the application frame.
None of this could be achieved using WinRT APIs.

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Closing Animation

The application has its own short animation on close by which it disappears. But Windows (or rather the Desktop Window Manager) also has an animation to show when a window is closed, which of course doesn't match into the picture: A window frame shadow which decreases in size and fades out doesn't make sense when the window has disappeared before already.
Luckily, there's a Win32 API in DWM to disable this for a specific window...

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Refresh Rate and HDR Mode Switching

We need to be able to automatically adjust the refresh rate of a display (if support) to match the video framerate on playback. Similar for switching HDR Mode on or off for a specific display.
WinRT APIs allow to enumerate the connected displays and get the current refresh rate and HDR status. But it's not possible to make any changes to it, neither to determine on which of the displays the app window is currently been shown on.
(for Xbox it's different, it has a special WinRT API which allows this)
For WinUI3: of course it's all doable via Win32 APIs.

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Network Isolation

Packaged Windows Store apps are underlying a stupid restriction which disallows network connections to the local machine (ridiculous imo - not general but that there's a manifest capability for everything but not for this).
Extremely unfortunate is that Visual Studio removes this restriction during development - which means: the bad surprise typically comes late.

Even apps running FullTrust are subject to this restriction - but guess what: when running FullTrust, there's a Win32 API you can call to lift this reestriction for your own app...

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

HID Input

We need to support remote controls. There's a WinRT API which allows to get and process this input (HidInputDevice), but like usual for those APIs, some hubris addict got hell-bent on inventing rules and restrictions for using this API and unnecessarily decided to disallow receiving certain events (in this case from the "consumer page"). As a result, remote control support is limited on UWP/Xbox but not in the WinUI3 app, because there's a Win32 API through which you can get at all input data without restrictions.

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

DPI-Aware Window Sizing

In WinUI3, you can get the "RasterizationScale" somewhere from the XAML root. The problem though, is that this value is only populated after the xaml tree is initialized/loaded.
But at this time, the window is shown already. What if you need to resize the app window in a specific way to match the content? Of course you want to resize the window before its shown, not showing it first and resizing only once the content is loaded. But WinUI3 doesn't give you the dpi scale information earlier.
Gladly, there's a Win32 API (GetDpiForWindow).

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Theme Switching

WinUI3 allows changing the app theme (dark/light). It even allows you to change it for a certain XAML subtree. So far so good.
But what you cannot do with WinUI3 is to change it for the whole application, specifically the app window frame and titlebar (note: I'm talking about instant change, not after restart).

This little detail makes the switching feature pretty useless. But - you've seen it coming - there are Win32 APIs which allow to achieve this.

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

Application Exit

With WinUI3, there's no way to close your own application in the same way as if the user would have clicked the close button in the title bar. When closing the app programmatically, the regular sequence of closing events is not fired and it exits right away instead.

So what we need to do to close our app (like user-initiaed) is to get the window handle and send a WM_CLOSE message to our own app's window - hard to believe but as much true as insane.

🡆 What came to the rescue? The Win32 API!
🡆 Could this have been solved with WinRT APIs? No!

True?

Yes. It all happened during the past few months only. The app exists and is completed.

Conclusion

This matches my earlier experience with UWP apps and APIs. Whatever you want or need to do - half of the time ecactly those parts that you need are not available or implemented or restricted/forbidden, even though it's easily possible with regular Windows APIs.

The WinRT APIs are a useless in many ways and areas. Often unsuitable to get the required jobs done.

Each time when you see some statement claiming that those WinRT APIs are meant to be the future of Windows API and a replacement for the Win32 APIs, then be quiet and listen closely - as you might hear me laughing all the long way through the internet (or crying 😆).

[brabebhin]

Tbh, c++/winRT can be easily used with C++ builder, whereas C++/CX could not.
I am not sure where the problem with C++/winRT tooling lies, but they need to do something about it, especially the idl file, which is a constant source of errors.

[legistek]

(1) Plain old COM would work equally well on C++ and C#.
(2) You still have DirectComposition. So far as I can tell the "Windows.UI.Composition" WinRT APIs are either ports of, if not simple wrappers for, DirectComposition. For a hot minute I once started going down this route. Truly the only difficult part of WPF/WinUI to replicate atop of DC would be virtualization, and there are ways of doing that which are far less complex than MS's flavor.
(3) I can't say I fully understand why in 2024 you'd want to write a UI in C++. I'm sure you'd manage just fine with .NET. (See what I did there? "Manage"? Get it?) 😃

[pjmlp]

Any C++ compiler worth their salt is full of extensions, including C++ Builder and Qt, yet for whatever reason we got a political riot inside WinDev to get back to the stone age of ATL development, so bad that even the legacy MFC has better Visual Studio tooling.

Or to pick @legistek's point, not only is C++/CLI updated to C++20, it has better development experience in Visual Studio, alongside Windows Forms, than C++/WinRT, now in maintenance, will ever acomplish.

[brabebhin]

Ideally I would like to have C++/CLI supporting both WPF and winUI. This would keep C++/winRT only for creating winRT components.

[sylveon]

I can't say I fully understand why in 2024 you'd want to write a UI in C++. I'm sure you'd manage just fine with .NET. (See what I did there? "Manage"? Get it?) 😃

C# interop with C++ is a pain, and I really dislike C++/CLI.

[mikernet]

@gitmixen I just finished watching the community call. Thanks for doing the community calls, I will definitely participate in the next one. I feel slightly more hopeful about the future of WinUI after watching that, but I'm still rather reserved with that hope. Guess we will see how it pans out.

I didn't see this addressed or mentioned in the call, but I may have missed it as I did fast forward through some parts. What I would really like to see is the basic, fundamental, and (what should be) relatively simple bug fixes addressed, some of which have been neglected for many years and cause us to need hacky workarounds all over the place....things like not being able to use modern C# features (this has caused us a lot of pain with shared code), null value bindings, bindings to base class methods, and binding to values outside of a data template.

Can someone please, PLEASE, look at addressing these fundamental usability issues/bugs:

#8723
#8221
#1904
#2508

[legistek]

At the risk of shamelessly plugging, I started a little project this morning to serve as a compilation of workarounds for framework-level features missing in WinUI.

https://github.com/peter0302/WinUI.Redemption

So far there's a respectable MultiBinding as well as a means of applying bindings as a part of styles. More to come.

There really is A LOT that can be done in WinUI even with all its current limitations, but sometimes it requires a bit of relentlessness and creativity.

[mikernet]

I'm sure you know about the Windows Community Toolkit that has a bunch of awesome stuff in it. There is also Uno Toolkit, which can be used in plain WinUI projects as well and has some really helpful things in there: https://platform.uno/docs/articles/external/uno.toolkit.ui/doc/helpers/ancestor-itemscontrol-binding.html

[legistek]

Uno has been doing amazing work for years, seemingly asking nothing in return. If anyone deserves a Microsoft acquisition it's them.

[hez2010]

As for

The Product Board is outdated and no longer maintained

That was that the person responsible for creating the section left the team and he used a private account to create it, so it was abandoned.

[brabebhin]

I'm not sure if that is making things any better tbh.

[softworkz]

The Product Board is outdated and no longer maintained

That was that the person responsible for creating the section left the team and he used a private account to create it, so it was abandoned.

Thanks for the info, didn't know that.

I'm not sure if that is making things any better tbh.

The really bad part is that there isn't any notice on that board to indicate that it's abandonded and where to look at instead.