WinUI 3.0 roadmap - we need your input!

[jesbis]

WinUI 3.0

At the Microsoft Build conference in May 2019 we shared our plans for WinUI 3.0, which will greatly expand the scope of WinUI to include the full native Windows UI platform. This means that the full Xaml framework would be developed on GitHub and ship out of band as NuGet packages.

The WinUI roadmap is now up to date with the latest plans for WinUI 3.0:
https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

You can also watch the Build 2019 conference session State of the Union: The Windows Presentation Platform for more details.

We'd love to hear what you think, and have some specific questions below.

How will this affect building Windows apps and components?

WinUI 3.0 will provide many benefits compared to the UWP Xaml framework, WPF, WinForms and MFC.

So, we want to make sure it's easy for everyone to use WinUI 3.0 in new and existing apps. There are a few ways we can approach this, and we'd love to hear your feedback on what areas we should focus on.

Our current thinking is:

Creating a new app

We plan to create new Visual Studio 2019 project templates for common languages (e.g. C# using .NET Core, standard C++17 using C++/WinRT) and app model + packaging (UWP + AppX, Win32 + MSIX).

What templates would interest you most?

The developer experience would be similar to current UWP apps.

Adding WinUI 3.0 to existing Win32 apps

WinUI 3.0 will include Xaml Islands, which let you use WinUI Xaml in your existing WPF, Windows Forms, and C++ Win32 applications.

The current version of Xaml Islands is only supported on Windows 10 May 2019 Update (1903), but the WinUI version should be backward-compatible to Creators Update (15063).

Were you aware of Xaml Islands for modernizing desktop apps?
Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

Updating your existing UWP Xaml app to WinUI 3.0

You'll have to update your app's target version to WinUI 3.0 to take advantage of it, similar to retargeting to a newer UWP SDK today.

We want to maximize compatibility between UWP Xaml and WinUI 3.0, but there will be some things to be aware of when updating.

1. Namespace update

The root namespace for Xaml, composition, and input APIs in WinUI will be different than the Windows UWP SDK root namespace:

Old namespace	New namespace (tentative)
Windows.UI.Xaml	Microsoft.UI.Xaml
Windows.UI.Composition	Microsoft.UI.Composition
Windows.UI.Input	Microsoft.UI.Input

We're exploring options for helping you automatically update namespaces when retargeting your UWP app to WinUI 3, at least for .NET apps.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

2. Mixing UWP and WinUI Xaml components

The fastest path to releasing WinUI 3.0 would be to not support mixing:

• UWP Windows.UI.Xaml.UIElement and Windows.UI.Composition.Visual elements

with:

• WinUI 3.0 Microsoft.UI.Xaml.UIElement and Microsoft.UI.Composition.Visual elements

in the same app.

However, one of our biggest concerns is the compatibility issues and work that could create for existing UWP apps and component libraries, particularly if you're authoring or consuming UWP Xaml control libraries.
For example, existing versions of the Windows Community Toolkit wouldn't be usable in WinUI 3.0 apps, so both the Toolkit and any apps using it would need to update before using WinUI 3.0.

We hope that all UWP Xaml control libraries can be updated to WinUI 3.0, but we know that even in the best case it would take time for everyone to update.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

What would be your preferred solution for using UWP Xaml components with WinUI 3?

General questions

1. What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

2. What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

[Dean-NC]

Reporting: just from a WinForms perspective, I've used both Telerik and DevExpress (even their latest versions), and while Telerik was good, I think DevExpress not only has a better overall designer and experience, but has a lot more subtle features that allowed me to do more complex layouts than Telerik. I think the DevExpress rendering technology is more advanced.

[jevansaks]

it may be helpful for the Win UI 3.0 team to get in contact with them and see if their is a way to assist them in implementation.

Thanks for the call-out. We'll reach out to them as well.

[Elmarcotoro]

Thanks for the call-out. We'll reach out to them as well.

It may be worth talking with all of them and seeing what the blocks are? Telerik, Grapecity, DevExpress etc.

[jevansaks]

Thanks for the call-out. We'll reach out to them as well.

It may be worth talking with all of them and seeing what the blocks are? Telerik, Grapecity, DevExpress etc.

For sure, that's our plan.

[kitgrose]

We're a bit different than most developers building for Windows. We develop mostly kiosk apps (apps intended to be run by users other than the computer's owner, and typically full-screen without any access to the broader system). The apps are generally built to the specific requirements of the customer, with no intention to distribute them through the store or equivalent.

Because the apps run full-screen, there's very limited value in the built-in controls maintaining the look and feel of other Windows apps; instead they tend to be highly branded for each customer. We do still need a lot of common behaviour and controls from standard Windows apps, but we typically do a lot of customisation of each one's control templates or at least override their core styles. For a very long time we built a lot of apps as WinForms backends with embedded Flash frontends for UI.

Broadly speaking almost every app we write integrates some kind of web-based backend with some piece of hardware (e.g. a printer, a barcode scanner, a mag stripe reader, an RFID scanner, a camera, card payment hardware, vending-style cash payment components, etc.), and the vast majority of those components historically have come with Win32 SDKs and not UWP ones.

For those two reasons, most of our historical apps are WinForms apps, and most of our modern apps are WPF ones. We have built a few UWP apps (largely to benefit from the really nice Assigned Access/Kiosk mode capabilities of Windows), but they're typically a pain to work on compared to WPF, and we typically can't get compatible hardware SDKs anyway.

We are very much intrigued by XAML Islands though, to allow us to write Win32-compatible apps with modern UI (although the advantage of UWP over WPF to us is not always clear, especially if we're not using standard controls or Microsoft-specific effects like Fluent, etc.).

To answer your specific questions:

What templates would interest you most?

C# with .NET Core, Win32 with WinUI 3.0 overlaid would be nice.

Were you aware of Xaml Islands for modernizing desktop apps?

Yes, and I was relatively happy with them when I've played with them, although we're not likely to use a single control, so much as making a decision for the whole custom UI.

The main reason I was aware of it was because we'd get Lottie support for Win32 apps.

Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

Not really; we almost always control the target PCs and can ensure we're always getting the latest compatible release.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

Yes.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

Very minimal. The main compatibility headache we'd have would be changed StaticResource keys for styling core elements.

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

Yes, we have used the Syncfusion UWP control library in the past.

What would be your preferred solution for using UWP Xaml components with WinUI 3?

The preferred solution would be to have more standard controls available in WinUI itself rather than leaning on outside sources (e.g. document viewers), but I expect those external component libraries would typically be more progressive about updating their libraries than we'd be at switching to WinUI 3 anyway for the most part.

What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

I'm excited to see UWP controls being more clearly decoupled from the UWP app and security model that has historically locked us out due to hardware compatibility reasons, especially since WinUI is being designed and developed in the open.

With such clear guidance about how Microsoft recommends us to build app UIs, I would expect all our apps would end up with WinUI frontends, regardless of which backend we can support.

What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

Mostly about getting access to more actively-maintained libraries of controls in my older apps, with nicer, more obvious documentation (or even access to the underlying code for the standard control) makes it much easier to figure out when I can adapt a standard control and when I need to roll my own user control. For example, in a recent app built in WPF I had a couple of date pickers; getting that control to work nicely for touch, and customising the size, font, pop-up icon, etc. was extremely annoying. I'd be inclined to use WinUI for that sort of app by default in the future given the roadmap above, because:

1. I can be reasonably assured that there is a native date-picker control that is at least moderately touch-friendly
2. I can examine that control's native/out of the box templates, etc., easily to see what I need to override to get it to match the design proofs for the customer's look-and-feel (as a roughly representative example, I might want to figure out the cleanest way to style the type—font size, weight, family—of a TextBox control's Header independently from its input text; does the standard HeaderTemplate use magic static resources I can redefine or do I need to override the template itself? If I do override the template, what's the default template's markup look like; does it do/support anything I hadn't considered?).

[Elmarcotoro]

I see that this has been closed, but there are a couple of issues that get raised by our users which I though would be worth raising. They are productivity improvements for users who work with large amounts of data.

TextBox: If a user needs to edit a TextBox they first have to click in the TextBox to display the clear button and then click the clear button to clear the TextBox. This is very inefficient when working with large amounts of data. It would be good if when the users clicks or tabs into the TextBox the text could be highlighted ready to be written over.

Gridview/ ListView: The Gridview and ListView do not seem to allow the user to effectively Tab through the collection. The ListView does allow Tab to move to controls on the same row, but it will not Tab to the next row of controls. Instead the ListView loses focus and Tab moves onto the next control in the visual tree.

These are two issues raised by our users as very annoying.

[kmgallahan]

@Elmarcotoro

I'd recommend that you create a new issue for each of the improvements you mentioned. The WinUI team will then triage to determine if they'll require WinUI 3 to be released before implementing or not.

This issue existed primarily to garner feedback regarding the 2 "General Questions" at the top of the post.

[RChrisCoble]

Support the Blazor hosting model native in WinUI. This would allow a Blazor control to be used directly in Client/Server web, or used directly in WinUI. The Blazor roadmap has this future concept without using a WebView control. This way the control's UI runs native with the .Net Standard portion of the code also running native.

[Mike-E-angelo]

Support the Blazor hosting model native in WinUI

Discussed on the Blazor side, FWIW: https://github.com/dotnet/aspnetcore/issues/11082

[jbartlau]

For sure, that's our plan.

@jevansaks Would be great to get into the loop as well.

[guilt]

I'd like better consistency of Tray Menus / Icon Menus with WinUI 3.0. Every App has a different spacing, and Win32 apps do not follow the font rendering / spacing / themes consistently. Please fix this already!

[alexandrevk]

WinUi in desktop completely useless for me due to lack of any windows management possibility: show/hide windows, windows position, windows size, dock/undock ...

[dotMorten]

@alexandrevk it is still a preview. Did you see the windowing API design? https://github.com/microsoft/ProjectReunion/issues/157

[rkarman]

Thank you @dotMorten for linking to the windowing announcement post!

@alexandrevk - we are putting together APIs for Reunion that will allow you to do these type of windowing operations from both Win32 and UWP with WinUI content as well as when using other frameworks/swapchain content in your window. Some of these windowing features may then be abstracted into the WinUI window class for easier access as well, but that is further down the road. Feature specs for the windowing area are in the pipe, stay tuned.

[nick-n-dev]

Speaking strictly as an invidual user (ie: non-corporate/company) and c++ only, even if i am just a lone voice shouting into the void, i feel the need to say, that as long as any of these new UI systems are tied to UWP and that horrible packaging system they build into, then i'm afraid it will always be in the dark whatever you do. (Speaking from WinRT experience, havn't tried WinUI yet but it looks pretty much the same to me). Surely it must be known that little to noone actually uses UWP apps? (actually hated by most afaik) so if its going to be called 'native' then why isnt it truly 'native', ie: a few #includes, link a .lib or two and build your app in STANDARD c++. Having to resort to things like Qt when cross-plat is of no concern, just to avoid wrapping win32 for the 1000th time is getting kinda old to be fair. Anyway just my 2cents, from someone who uses the language every day, but probably has no place commenting here.

[dotMorten]

@nl-n you should be happy to know that one of the big deals with WinUI is that it doesn't require to run as a UWP app. In fact this has been possible since preview 2. Currently it does require packaging as msix, but msix is actually a pretty decent way to distribute (and update) your apps.

[nick-n-dev]

@dotMorten That's one of the big issues: requiring side-loading/installing via the store. i don't know a single person who doesnt disable/strip the store before (or just after) installing windows, so how are we supposed to distribute them?. I know that's somewhat rhetorical but it serves the point. I should just be able to zip up the build directory and distribute it (or an installer if warranted). Then there's the compatibility issue, a great many people still refuse to even install W10, so there's that too... It is good however to hear that's the direction 3.0 is heading though, as much as i hate xaml, it would be a welcome addition. Maybe we could get it without needing to install the whole 50gb UWP workload in VS too? 🙏 (exaggerating i know, but still)

To quote @MarkIngramUK near the beginning of this thread:

It's 2019, I want a fast, native UI, and I don't want to have to seriously consider making a user interface with CreateWindowExW, GDI, etc.

which (funnily enough) i am literally having to do right now, and yes it is just as painful as it sounds :)

[dotMorten]

@nl-n who said anything about the store? MSIX isn't really different from installing from MSI. It's just an app installer. Double click it to install. No store needed. Guarantees a 100% clean uninstall too (as opposed to MSI which makes a giant mess)

[maxkatz6]

i don't know a single person who doesnt disable/strip the store

It's not common though.

how are we supposed to distribute them

First of all, you need to inform users to not disable the store)

I should just be able to zip up the build directory and distribute it

MSIX can be installed without a store. With latest Windows versions user don't need to enable anything for that. Of course if package was signed before with trusted certificate. But yeah, if user removed store from the PC, then he could also remove MSIX/APPX AppInstaller from it as well. In that case they probably don't want all variability of applications.

a great many people still refuse to even install W10,

It's their choice. Nuff said.

whole 50gb UWP workload in VS too

Single SDK is about 3GB. It isn't required to download every one starting 10240 one.

[nick-n-dev]

@nl-n who said anything about the store? MSIX isn't really different from installing from MSI. It's just an app installer. Double click it to install. No store needed. Guarantees a 100% clean uninstall too (as opposed to MSI which makes a giant mess)

That was from the description visual studio gives you, 'for sideloading/installing via the microsoft store', the only other information i've found on msix is from the msdn, which basically says: msix packages are sandboxed/virtualized 'appx' applications, which is pretty much a killer for anything working directly with the winapi. And they require signing to even be installable?...

It could also just be crossed wires i suppose, too much differing teminology, and i don't know much about UWP.

It's not common though.

More common than you think, and with reason 😄

Anyway, it wasn't my intention to derail, so i'll go back to writing my CreateWindowExW stuff for now 🤣