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?

[mdtauk]

These are my initial thoughts on the questions you asked in the issue content.

I come from a design and user perspective, with only a little development experience, who got very interested in Silverlight/Windows Phone 7 development back in the day who now feels a little burned.

What templates would interest you most?

I think before asking for a list of template ideas, there needs to be some kind of audit done of the biggest and most used apps in each framework, so WPF, UWP, WinForms, MFC etc.

Examine the "silhouette" of these apps and figure out the common UX scenarios.

Off the top of my head, there is:

• Main Menu (All frameworks)
• MDI (multiple documents in a single window) (MFC mostly)
• Tabs and Datagrid (WPF, WinForms, MFC)
• Ribbon (Win32 apps Office, 3ds max, paint, wordpad, File Explorer etc)
• System Tray Utilities (MFC, WinForms)
• Browsers
• Wizards (WPF, MFC)
• Complex MDI apps (Adobe software, Visual Studio)
• Media Players
• Data Visualisation LoB (WPF and Web)
• Social apps (React Native, PWA - Skype, Facebook, Twitter)

All or some of these could benefit from WinRT/UWP system integration with Notifications/Action Centre.

All these New Project templates should eschew the built in Windows.Xaml namespaces, WPF control theme, and WinForms visual styles in favour of new templates and visual styles which match the FabricWeb/Fluent control designs.

There should also be an easy way for devs with existing WPF and WinForms apps to add a WinUI 3.0 dependency which gives them the new control designs with a simple using statement or manifest entry

XAML Islands

As Xaml Islands becomes easier to make possible - replacing old webview controls, colour pickers, XAML based Dialogs could be as easy as a Add New... and choose a Dialog, or standard control which existing C# and C++ code can call into, and they have their own codebehind.

Modern app and page templates like Xbox Next apps, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop, and Pivot - could all be made available for all Windows Presentation Platforms - with XAML Islands in place and sample content.

Any of these scenarios which are not currently possible in UWP XAML, should be with controls and templates to make these easier.

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

It should be a question asked when someone opens their project on the latest version of Visual Studio with a current Windows 10 SDK. Press the button and it either replaces the name spaces and using, or flags them if it is not a control it is familiar with.

On new projects it should be the default, and the nuget package installed along with future versions of the Windows SDK.

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

As with the automatic updating answer, New pages and projects should include it by default, and a message asking if they want to Automatically move to WinUI | Add ToDo comments to update namespaces | Do not move to WinUI.

What kind of apps would you be most excited to use WinUI 3.0 for?

As a user I want all apps running on Windows to share a common UI and UX no matter what framework was used.

I want apps to be installed without messing with the registry and leaving junk behind. (so Centennial)

I want all the apps to be installable from within the store, or from a Centennial type installer. Virtualise the System and Windows folders for every app.

Modernizing a C++ MFC app with Fluent UI?

Acrylic should be available to WPF, WinForms, and MFC apps, and included in default new templates via a WinUI 3.0 dependency or manifest. CommonControls and window styles should use Acrylic and extended titlebars (which can be overridden to go back to the current defaults)

Microsoft's Win32 non UWP apps need to all be recompiled with WinUI 3.0 so they all use Acrylic window frames, main menus, ThemeShadows, Context Menus, Text Fields, Progress Bars etc.

And then existing apps need a simple solution to drop in WinUI 3.0+ which then updates the looks of all the controls - or the ability to apply it selectively one dialog at a time, until the entire UI is updated.

[paulio]

re: namespaces, I would expect them to just change based on the target even it requires conditional namespaces.

[simonferquel]

Here are my answers:

Creating a new app

What templates would interest you most?

• I'd love to see c++/winRT win32+xaml and .net core+xaml first there, UWP templates coming second, packaged win32 app should not come as a template, as current app package templates should just work as they already do with current win32/.Net apps.
• Additionaly, I'd love to see item templates like "New XAML Window" with boiler-plate code to show it in an existing win32 or .net core App application (e.g.: making existing systray app à la Docker Desktop, able to show a new top level Xaml Window)

Adding WinUI 3.0 to existing Win32 apps

• non-backward compatibility is the exact reason why I never used xaml islands on a real project (used it for fun on personal stuff though). Decoupling the UI framework from the Windows API is one of the greatest thing announced with the WinUI 3.0 roadmap (alongside the ability for non-packaged/non-uwp targetting apps to leverage it)

Updating your existing UWP Xaml app to WinUI 3.0

It might sound harsh, but I feel like UWP xaml app are a niche (since the drop of windows phone, there is no more traction toward UWP as a target platform), and even if tooling/interop would be nice to have, I don't think it should be the main focus for WinUI 3.0.
So both namespace update tooling (which might be actually done using a global find and replace) and mixing UWP xaml and WinUI xaml do not feel critical to me.

[simonferquel]

Also, just want to mention that this is a very welcome move, and having the whole UI framework open source on Github is awesome! Thanks a lot for doing this!

[GeertvanHorrik]

First of all, this is a great move! Unfortunately I cannot neglect the fact that I feel a bit hurt by the way Microsoft has dealt with the few last developers on their platform. At the moment I only use UWP for consumer-facing apps because:

1. WPF is way more mature than WinUI (validation, existing controls, etc), so for enterprise WPF is a better fit
2. UWP is great for multiple device categories (mobile, tablet, desktop, etc), that's where the consumers are at

It's great to see point 1 could be tackled with WinUI, so that makes me enthusiastic about the progress for WinUI. Unfortunately 2 is no longer applicable (no more cool devices, just desktops). It makes one wonder, at the time this stuff ships (1 year from now earliest?), what would developers need at that stage.

I think the consumer stuff is no longer part of the equation, that ship has sailed with the retrenchment "strategy". So the only thing it could be good for are enterprise apps.

In general, I would be more interested in a good migration strategy from WPF to WinUI to try and migrate our massive WPF code-base to Windows 10. The downside of having to update consumer-facing apps (currently UWP) is that they highly depend on external component developers (e.g. win toolkit, etc). I think there is no viable option to update these anymore since most developers (I know of) lost interest in consumer / windows client development.

Answers to the questions

Creating a new app

What templates would interest you most?

I would love to see .net core / xaml / C# here, since I think that's the most used language combination available. But maybe a migration template would be better here (try to get everyone on board as quickly as possible, the longer it takes, the more painful it will get).

Adding WinUI 3.0 to existing Win32 apps

I think this is extremely nice, and we would use this a lot (but realistically, this is at least a year away since enterprise customers are still on Windows 7, even when MS support ends, companies will be on Windows 7). Then we can slowly migrate WPF to WinUI 3.

Were you aware of Xaml Islands for modernizing desktop apps?

Yes, but too many customers are (or were) on Windows 7, so it was not an option for enterprise devs. And for consumers you could just use UWP anyway.

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

It's a good start because at the time this stuff ships, it would work on all supported versions of Windows 10 in the enterprise.

Updating your existing UWP Xaml app to WinUI 3.0

Consumer apps for MS are over, all because of the choices MS made, there is no more room for this. I would just skip this whole option and forget about it. It's sad because I put thousands of hours into UWP apps, but I think we need to make this death quick to make it less painful.

The whole promised story was always up-to-date, support all devices. I think we all know what way that promise went.

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

If it's just namespaces, a search / replace should do the trick as well.

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

No longer important, I am willing to take the loss of thousands of hours of development, there are no users left anyway.

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

Nope.

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

UWP Islands (sort of hosted components)

General

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?

It probably needs some maturing, but I see myself using this stuff in 1 - 2 years for enterprise development. Depending on how hard it is to migrate, we will either choose WinUI or web (depending on how Windows itself "evolves").

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?

Probably just adding new views to a WPF app and slowly start migrating.

[wbokkers]

I very much like this roadmap. UWP needs to be freed from its shackles, and this is a great way to do just that.

Updating your existing UWP Xaml app to WinUI 3.0

This is very important for my employer. We have a complex UWP desktop app in the store. We now need Desktop Bridge to get access to win32 APIs that are not supported by .NET Native.

I would like

• direct access to all win32 API's;
• using a plain old win32 execution model. I'm fine with some Desktop Bridge-like sandboxing (e.g. virtualization of the registry);
• to put our app in the store (msix) as it is now;
• to still use WNS (push notifications);
• a painless update experience from UWP to some new Xaml Desktop app type. I don't mind doing some manual labor. Maybe I prefer good documentation over tooling here.

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

Existing styles should still work. I can live with some minor visual changes. But not with changes in behavior.

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

No.

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

If they can't be recompiled (third party): Xaml Islands-like approach. Otherwise it should be possible to easily port them to WinUI 3.

General

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?

• Desktop win32 apps, packaged with MSIX.
• Uno cross platform apps ;)

[meir-pletinsky]

Please do not introduce new namespaces for stuff like INotifyDataErrorInfo - it should be used in view models that are usually cross-platform and should not have dependency on WinUI. It should be defined where other stuff like this is located (i.e. INotifyPropertyChanged or INotifyCollectionChanged)

[shaggygi]

I would just like to know if the ultimate goal is to create a cross-plat UI stack. Understanding it might not be completely understood how we get there. However, if that is the intent... it would be better to brand this without the Win references at the beginning of this effort. It will be less headaches in the long term if you did.

Would it be better to label as XamlUI or similar? The Microsoft.UI.* namespaces are fine, just brand the repo and such as XamlUI 3.0 or similar.

Thanks for reaching out. Look forward to what's to come in this space 😄

[weitzhandler]

To me, all the technical details are less important.
UWP, WPF or any Windows-only framework, as awesome as it would be, isn't going to be enough so long it doesn't run on every platform (at least Windows, Droid, iOS and web), and is friendly with any screen size.

TBH was disappointed me on last Build to discover the MS has no plans on making UWP or XAML cross-platform. Uno got no official recognition other than a speech. Even more frustrating, I'd say hurting, was to discover that MS is giving so much love to React Native and HTML/JS driven frameworks AGAIN (WinJS), while neglecting its loyal .NET stack devs.
I'd want to see MS officially creating a cross-platform UI stack like Uno, and providing the right tooling, templates, and integrated support.

And BTW, I have been working with XF since its acquisition by MS, and wish it had an alternative, for following reasons: a. No web support, b. Very mobile biased, no love for desktops c. Its library hierarchy feels sloppy, definitely when compared to WPF/UWP control-library d. Is not using MS XAML.
Here's the feature request I posted on Microsoft Developer Community: .NET UI Standard.

Thanks y'all!

[TonyHenrique]

We need a XAML UI that also runs on the Web (Assembly). At least a subset of UWP.
Why not embrace UNO platform and make the web rendering using SkiaSharp?
Could be Silverlight 6, the web counterpart of WinUI

[huoyaoyuan]

Quick replies for the questions

What templates would interest you most?

.NET core SDK-style projects, or some simplified MSVC project format.
The old project files are too complicated to edit manually, and there are tons of interaction issues between the old and new project system. We should totally drop the old project system for brand new projects.

Were you aware of Xaml Islands for modernizing desktop apps?

No. I'm rewriting my application with a full data model change, so there's no progressive migration.

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

There are still many users on Windows 7 and Xaml Islands can't help.

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

No. All my components are self-written, or from MUX and WCTK, so I can perform a quick manual migrate.

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

No so much, because my project is not big(~20 pages and ~10 custom controls for now).

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

I'd like there to be a version shipped with OS, to allow creating very tiny tools and shiping in KBs. The tool simply fails to run on lower OS, as the supposed user can immediately contact me (e. g. through some chatting software).

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?

Creating a new Windows 10-only app and ship without the store.
Trusted signing is expensive for individual developers, and uploading to store isn't applicable for domain-specific, not long-term applications.

My personal look for the UI platform

Xaml toolchain

The xaml language is somehow not serious, and I'm facing many issues like "how should I represent this". WPF xaml and UWP xaml aren't fully compatible, so I need to remember their differences. Xaml are not fully compatible with .NET features, so I sometimes need to write some ugly tricks in my model, and a helper class.

Coming with x:Bind, things becomes even worse. The simple scenarios are easy to use, but it's very complicated to do things that's more than a property access. For example, it doesn't support method overloading, so I must compile to check which overload is chosen for this binding expression. I cannot even do a simple switch, or a "visible when some property is false" conversion, and a helper method is required. The documentation says nothing about these detailed scenarios, so I think there should be a position for xaml-language-design discussion, and make xaml a seriously designed language like C#.

The xaml editor are hard to use too. It's reasonable for designer to try execute some code to show the actual effects, but the text editor should just be aware of metadata. Opening an xaml file in source view is slow because it's activating the designer, and throwing some interaction exceptions for totally fine-to-run xaml, such as NullReferenceException and Cannot convert __ComObject to some type. It touches ProjectReference through built libraries, and results in complicated error even when a simple edit to non-public-api area in dependency library, typically the implementation of data model. So I think there should be a metadata and source code aware, fully Roslyn integrated xaml compiler. This would benefit a lot if Roslyn has a "custom code generating/lowering plugin" feature.

A better windowing model

It's regular for information-full, state-full application to use multi-window model instead of navigating model. Currently in UWP, creating new window using ApplicationView is painful because there are threading issues. The new AppWindow shares the UI thread, and I'm not sure about its UI performance.

Rewriting Visual Studio in WinUI at sometime future can prove it to be a mature UI system.

Data binding interfaces

We are very tired for creating models implementing INotifyPropertyChanged. I've written a custom MSBuild task to convert a xml into expanded property accessors, but it doesn't help when I want to do something custom in the setter when the property changes.

And there are threading issues. My data come totally from a background network server, so context capturing for await can't help me. In WPF and Binding, it's just as-is because Binding solves threading itself. When changing to x:Bind, I have to solve it inside event raiser, because x:Bind just operate on the calling thread. Things becomes even worse when I have multiple application views touching the same data, which means there is not global UI dispatcher available, and the only solution is capturing SynchronizationContext.Current at event registration. For collections, ItemsSource is not thread safe neither, and the same workaround is required.

There should definitely be a toolchain to solve the modeling, threading, and extending issues for mutable bindable models. And a generic built-in solution for bindable collection should provide a mechanism for "specified property of any child changed".

IObservableVector<T> is a fake generic type that can uses object only, INotifyCollectionChanged is non generic. Just implement it for built-in collection like ObservableCollection<T> is not enough, especially for complicated, ISupportIncrementalLoading/IItemsRangeInfo oriented scenarios. The platform should provide an default abstract implementation with best practices, allowing the user just implement an abstract data-filling method.

[mdtauk]

@shaggygi @weitzhandler @TonyHenrique

If there is to be a Cross Platform future for UWP/XamlUI3.0 abstracting the XAML syntax, from the Windows Renderer, and the rest of the Windows Runtime would be a way to handle it.

If there could be an almost plug-in mentality with the project, there could be an Android or iOS/AppKit Renderer, and an Android/iOS AppKit Shim to pass ART APIs into C# and VB, as well as the existing C++, C language support.
Xamarin could help here.

Microsoft does not need to be the ones working on those alt platform renderers.

But focusing on Windows for now... WinUI 3.0 could encompass Fabric Web / React Native / WPF / WinForms / MFC. PWAs will also be a first class citizen for app development, so there are cross platform stories for apps not made for Windows/.NET/UWP directly.

What is needed now, is to provide a story for C#/.NET/UWP devs to bring their apps and investments to the wider landscape of platforms.

[anthcool]

My 2 cents: I'm a Xamarin.Forms dev, and (like many others) am interested in seeing all XAML dialects being merged into one that works everywhere, including the mobile space. Not sure how that would go down, but that's at least my wish on the matter.

[mdtauk]

WinUI 3.0 onwards perhaps - but there are too many WPF apps out there to expect them all to re-write and translate all that XAML. New WPF projects could use the more modern WinRT XAML dialect. You could introduce the equivalent of a DocType to XAML so different dialects could co exist in the same project.

Easier said than done of course.

[simonferquel]

@mdtauk I think that once the Xaml platform is actually made open-source, we will have a clearer understanding about what it relies on on the bottom of the stack (we already know that the main platform-specific dependencies are DirectX11, Direct2D and Windows Media Foundation, but who knows what part of the Windows SDK is used there), and how it is layered (so that we can have an actual feeling about the feasability of any porting).
Also we have yet to see under what kind of license the source code will be distributed. I am not sure if it has been decided yet.

[mdtauk]

Android uses Vulkan and I think supports OpenGL
iOS and macOS use Metal

As for the media codecs, it may be possible to make use of native C based APIs to substitute.

@simonferquel It will become clearer when the code is refactored and checked in. And it may require some iOS and Android experts to lead those efforts.

[lhak]

I think changing the namespace was a reasonable approach when winui was collection of controls. However, now that it basically replaces the platform, I think this is not justified anymore. This is already works in same way for WPF/Winforms, where code can be moved from .net Framework to .net core without changing the namespaces in code. The platform should automatically be able to load the winui versions of the necessary dlls when enabled. In this way, source and binary compatibility (I have successfully used .net framework libraries in .net core apps) can be preserved.

[jesbis]

Just wanted to say thanks everyone for the comments so far! The WinUI team is looking carefully at all the responses and points.
We'll also likely split off some focused issues to talk about specific points that have come up (e.g. compatibility with existing UWP frameworks and components) once we've organized our thoughts.

[MarkIngramUK]

For now, there is a arguement named "UWP is dead" on twitter, I think MS should clarify this and declare their uwp road.

You’ve just posted that on the roadmap thread...

[Elmarcotoro]

@jevansaks Thanks for the info on the Datagrid control. This does not deal with the issues of printing reports and pagination, exporting and such. These are real life business scenarios that need to be dealt with, not whether some button animates (as nice and as cool as this can be).

@hupo376787
"For a reporting system, I think Telerik UI is the best choice currently."

From what I can see Dev Express are the only ones who currently provide a full stack for creating and viewing reports for UWP, and their pricing seems to be on the premium side. All the others including Telerik have gaps in their tooling which means reports for UWP cannot be created. I'm willing (hoping) to be corrected on this.

[VagueGit]

For a reporting system, I think Telerik UI is the best choice currently. A Chinese proverb saying "Some people specialize in some professions while others in other professions.". Telerik, or DevExpress or someone else, are good at reporting.

@hupo376787 please take extra care to check your facts before implying a posting is incorrect. Telerik Reporting has a report designer for WPF and WinForms but not UWP.

DevExpress also has a report designer for WinForms and WPF, but not UWP

So please check your facts before committing yourself to an error that will be preserved in perpetuity and circulated widely. Hey that sounds like it might be an old proverb one day 😉

[hupo376787]

@hupo376787 please take extra care to check your facts before implying a posting is incorrect. Telerik Reporting has a report designer for WPF and WinForms but not UWP.

DevExpress also has a report designer for WinForms and WPF, but not UWP

So please check your facts before committing yourself to an error that will be preserved in perpetuity and circulated widely. Hey that sounds like it might be an old proverb one day 😉

OK, I think we have the different understanding of Reporting. I mean https://www.telerik.com/universal-windows-platform-ui and https://www.devexpress.com/products/net/controls/win10apps/.

[Elmarcotoro]

I was incorrect, Dev Express do not provide reporting for UWP. It appears no third party tooling developer does! I contacted Dev express through their chat, about whether they had a road map for providing reporting for UWP.
They said,
"The XtraReports Suite uses the functionality provided by the System.Drawing assembly and the thing that prevents us from implementing the same set of tools for Universal Window Applications is that this assembly isn't available there (https://stackoverflow.com/questions/31545389/windows-universal-app-with-system-drawing-and-possible-alternative). So, we haven't yet established our future plans in this area."

@jevansaks, it seems there is a lack of communication between the Microsoft UI team and these third party tool providers. We would be happy to use third party tooling, but it looks like the UWP platform makes it difficult for these companies to integrate the tooling they have for other platforms into UWP.

They asked me to contact their reportingteam@devexpress.com with our reporting requirements, 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. I don't see how you will get business devs on the universal platform without proper reporting tools.

https://www.devexpress.com/subscriptions/reporting/

[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:
dotnet/aspnetcore#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? microsoft/WindowsAppSDK#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 🤣