Update: WinUI 3 roadmap feedback

[jesbis]

Update: WinUI 3 roadmap

Thanks everyone for the great discussion and feedback so far on the WinUI 3 roadmap (#717)! The team is paying attention to every comment and issue that comes in.

I wanted to give a quick update on some of the main areas of interest that came up.

Availability Roadmap

2.2 Stable Release

The next release of WinUI will be 2.2 stable in July. Further development will continue on the 2.x versions while we work on 3.0 in parallel.

3.0-Prerelease Preview

We're hoping to release an early preview of WinUI 3.0 before the end of the year. We're currently on track but timing will be tight - we have lots of work to do between now and then.

The preview would be missing features but would enable building basic apps to get a feel for WinUI 3.

This should include a preview of Xaml Islands support on Creators Update and up (15063+) for adding WinUI UI to existing apps including WPF, WinForms, MFC. It would also include a temporary Visual Studio template (probably via a .vsix extension) for creating a new UWP WinUI 3 app.

It would not include "WinUI in Desktop" yet (more on this below).

3.0 Stable Release

On track for next year.

Open Source

We're working toward open source but don't have a firm ETA yet. It will start as a branch in this repo.

We're planning to open-source as early as we can and move our active development to GitHub. That means the code won't be fully clean and modern yet compared to the existing WinUI 2 code in this repo - we have lots of Windows C++ code with lots of history 😊

Feedback summary and updates

Some highlights of the feedback we've heard and where we're at, in no particular order:

WinUI in desktop applications

We know that using WinUI in desktop apps is the most interesting scenario for lots of Windows app developers. The goal is to enable using Xaml markup + WinRT APIs (via .NET or C++) as the UI for a win32/desktop app (instead of a UWP app), without needing to use Xaml Islands.

@LucasHaines and @marb2000 are working closely with the .NET and Visual Studio teams on this and can share more details as the work evolves.

Note that UWP support will be ready before win32, just because UWP is less work.

Our focus is still Windows 10 and 8.1, but we hear the feedback that some of you still have users & customers on Win7 and we'll be evaluating the market and options over time.

Tooling and templates

We're still planning to (in order):

1. Replace the current Visual Studio default UWP app templates with:
   (UWP app model) + (WinUI 3.0 UI) + (.NET or C++ language)
2. Add new Visual Studio default desktop app templates for:
   (Win32 app model) + (WinUI 3.0 UI) + (.NET or C++ language)

We're also starting to think about what migration helper tools we might build, starting with tools to migrate existing UWP C# apps. Your feedback on this has been helpful!

F# support

It was awesome and informative to hear all the feedback on F# and the potential benefits for Xaml apps. @kathyang - one of the interns on the WinUI team - has been investigating this and talking to the F# team, and would love to hear your ideas in the tracking issue #740.

Just to set expectations: if we did anything to support new languages it would have to be after the initial WinUI 3.0 release, just because we have lots of work to do to get 3.0 working with the currently-supported languages first. It's also possible that we could accept community contributions after open-sourcing WinUI.

Cross-platform UI

We hear you about .NET and cross-platform UI. This is a complex area with lots of potential opportunities.

The WinUI 3.0 release is focused on providing a great solution for Windows client developers, but we're thinking about future opportunities. We're also big fans of the Xamarin team and are in touch with them.

Some of you also mentioned Uno specifically: we think nventive (creators of Uno) had a great presence at Build the last couple years and our team spent a good amount of time talking to them to understand their approach to technologies and industry.

WebAssembly is also increasingly interesting and on our radar. We think this is an exciting space with many improvements on the horizon which Microsoft is continuing to invest in, and we love the work that Mono, Uno, Blazor and others are doing.

INotifyDataErrorInfo etc.

@LucasHaines is working on getting the input validation work we showed at Build 2019 fully integrated into WinUI 3 and would love any further feedback on:

• the tracking issue: Add Input Validation Support to WinUI (UWP and Win32 Desktop) with INotifyDataErrorInfo #179
• the ongoing spec review: Spec Review: Input Validation microsoft-ui-xaml-specs#26

Features (new & old)

New features

We've shifted active feature development on Xaml from UWP to WinUI 3.0. That means most new features will require WinUI 3.0 to be a bit more stable before we can start development on them. We review every proposal that comes in and we've started tagging those proposals in with the needs-winui-3 label so we can revisit them as soon as we can.

Please do keep filing new feature proposals for things that would help you use WinUI 3!

Desktop parity (e.g. WPF)

Thanks for sharing the feedback about WPF parity and ensuring WinUI 3.0 is a fully featured platform for rich desktop development. This will continue to be an ongoing effort for us.

For background info, some of the goals of UWP Xaml included:

• improving on the performance, battery life and scalability of previous Xaml platforms like WPF and Silverlight
• ensuring all UI can adapt to multiple DPIs, screen sizes, input modes and device types

Which required some changes to previous Xaml functionality, including:

• optimizing and extending existing controls
• introducing new controls and UI patterns, like NavigationView
• supporting new user input modalities, like super-low-latency inking
• introducing new Xaml concepts, like {x:Bind} instead of {Binding}
• tighter integration with low-level systems, like SwapChainPanel with fully native DirectX11 and DX12 support instead of D3DImage
• integration with the UWP app model, which can provide benefits like better app lifecycle management, resource loading and install/uninstall experience
• removing particularly slow features with relatively low usage until they could be optimized and reintroduced over time, e.g. radial gradients (which is coming back fully optimized hopefully soon: Proposal: RadialGradientBrush  #266)

As well as improved threading, hardware acceleration and many other optimizations.

TLDR:

WinUI 3.0 includes many features that aren't in WPF, but WPF has some features that aren't in WinUI 3.0.

We're continually working on expanding the features in WinUI Xaml and Composition, so if there are specific WPF features you rely on that you'd like to see in WinUI 3 then keep letting us know by opening a new issue, commenting in the "WPF features that should be in WinRT XAML" #719 issue that @mdtauk started, and voting on existing issues/comments.

Your continued feedback will help us prioritize what to focus on!

Thanks everyone!

WinUI 3.0 is a marathon and not a sprint so keep looking for updates over the coming year.

Special thanks to all-star commenters like @mdtauk, @MarkIngramUK, @galvesribeiro, @mike-eee, @TonyHenrique, @eklipse2k8, @mrlacey as well as @weitzhandler, @jozefizso, @simonferquel, @reli-msft, @kmgallahan, @GeorgeS2019, @meir-pletinsky, @zezba9000, @mfeingol, @bchavez, @Shidell, @KyleNanakdewa, @Happypig375, @wbokkers, @meteorsnows, @ekral, @contextfree, @Pinox, @GeertvanHorrik, @shaggygi, @riverar, @r7dev, @natemonster, @mfe-, @khoshroomahdi, @jkoritzinsky, @edgarsanchez, @charlesroddie, @4creators, @wjk, @vitorgrs, @thomasclaudiushuber, @paulio, @niels9001, @lhak, @huoyaoyuan, @anthcool, @Suriman, @RyoukoKonpaku, @GiorgioG, @Felix-Dev, @dotMorten and everyone that gave feedback on the roadmap so far!

Please leave a comment if you have other questions.

[MarkIngramUK]

Thank you for listening to the community feedback. I’m really excited for WinUI 3.0 (Win32 + WinUI + C++). This feels like the framework we’ve been waiting for! RIP GDI 😉

[adrientetar]

(Win32 app model) + (WinUI 3.0 UI) + (.NET or C++ language)

So this would basically be the UWP UI, but without the phone-like lifecycle and sandbox? That seems interesting for desktop apps, then – I'll be experimenting with this.

[mdtauk]

Thank you for the update, and hopefully more updates will come as WinUI 3.0's initial feature set is locked down, and any new controls or control features that have been proposed, which may make it into WinUI 3.0.

Oh and documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful to pre-empt the umpteen amount of questions that will come.

Perhaps a nice matrix of what is included with which combination of frameworks and APIs, along with the architecture diagrams we got at Build!

[weitzhandler]

You guys are incredible, thanks for everything!
The xplat section made my day, especially that Uno is on the radar.

[zezba9000]

Our focus is still Windows 10 and 8.1, but we hear the feedback that some of you still have users & customers on Win7 and we'll be evaluating the market and options over time.

Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be? Seems like most of the features people use on the desktop would just work and for special / platform specific ones that don't, maybe keep them away from being part of the core UI system and keep them in platform specific packages such as (Win10, Win8.1, Win7 Nugets etc).

Also if there was a cross-platform XAML that had the same look and feel across all devices (Win32, Android, iOS and WASM) like you can do with HTML (but not Xamarin sadly) my company would have jumped on it years ago.

Also glad you guys consider this a "marathon (great Bungie game too)". The less fragmentation in the XAML space the better for everyone and taking to many short cuts will just end you back where you started ;)

[jesbis]

documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful

We're working on it and will share more as this develops!

---

Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be?

@zezba9000 WinUI doesn't use .NET, and you don't necessarily have to use .NET Core with WinUI: it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features, not just higher-level add-on features like specific controls.

[mdtauk]

documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful

We're working on it and will share more as this develops!

Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be?

@zezba9000 WinUI doesn't use .NET, and you don't necessarily have to use .NET Core with WinUI: it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features, not just higher-level add-on features like specific controls.

For Windows 7 compatibility - it would require some third party to build their own compatible renderer for the XAML, as well as some kind of alternative Shim for any OS level APIs needed.

Right now there is no idea if this is possible - the hope is that when the WinUI bits are removed from the OS, they are put into the open source project in a way, which will enable other platforms to provide some kind of compatibility component. Think Xamarin, Uno, or .Net Core with a custom renderer.

[zezba9000]

it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features

In my mind what constitutes a "core feature" wouldn't be something that relies on OS specifics besides of course rendering and input. Which in those cases would be abstraction layers anyone can extend. At a foundational level one in theory should be able to render the UI with a custom software-renderer and do Input with a custom XInput backend with a virtual cursor if so desired. If you can do that kind of modularity you can pretty much do anything and extending the platform support becomes extremely easy (as is done in games). You spend a little more time in this area and down the road everything takes a lot less effort. If WPF XAML was designed this way it could have just been taken and used in UWP apps. Technical debt will just become an endless loop otherwise.

Things like tray-icon support etc could be in a "WinUI Windows basic features (Win7-Win10)" package. Things like push notifications could be in a "WinUI Windows extended features (Win8-Win10)" package.

Hope that makes sense.

[jesbis]

@mdtauk, @zezba9000 it's all theoretically possible, and we have lots of platform abstraction expertise on the team. As with anything, it just comes down to cost, schedule and expected benefit 😊

In addition to development and testing costs (which would extend into potentially non-obvious areas, for example ensuring everything works with old assistive technologies) we also have to consider support cost over long timespans.

Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize.

[mdtauk]

In addition to development and testing costs (which would extend into potentially non-obvious areas, for example ensuring everything works with old assistive technologies) we also have to consider support cost over long timespans.

Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize.

@jesbis I don't see much benefit in adding compatibility to Win7 for WinUI 3.0 - Linux, Android, iOS, iPadOS and MacOS however, may be beneficial for providing a cross platform solution, which does not rely on native UI frameworks.

[weitzhandler]

@mdtauk
@jesbis I don't see much benefit in adding compatibility to Win7 for WinUI 3.0 - Linux, Android, iOS, iPadOS and MacOS however, may be beneficial for providing a cross platform solution.

Agree to that. I'd just add web-assembly, to me it's even more essential than Linux.

[zezba9000]

Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize.

No my company does not. I was giving more of a design argument in an area I've seen XAML struggle with in all its iterations (from my perspective) but ya I totally see why MS wouldn't want to spend time there. However it would be cool if WinUI was capable enough for others to do this work if they needed to (which tends to happen I've noticed) without going down a rabbit hole of Windows dependencies as is the case with WPF now.

To be clear on what my company would love to see is Android and WASM support be a little more official than UNO (and 3 years ago). We make management software that governs the state of a collection of local computers and system setups usually involving a big need for Win32 APIs (UWP would never work for us but we like the UI because of compile-time errors unlike HTML build systems) and our clients + us need Win32 + Android + Browser UI experiences that have a uniform experience and feel. HTML is just a big pain point as it adds needless abstraction and complexity that otherwise not need be there as our primary code base is in C#.

Hope thats better feedback for ya.