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?

[jesbis]

XAML Islands require Windows 10, version 1903

In which case the project will be UWP for Windows 10

With WinUI 3.0, we're planning to make islands available on 1703 and up (so much further back).

We're also working toward WinUI being usable with a Win32 app model instead of UWP (informally being called "WinUI desktop"), so it won't necessarily have to be a UWP app.

[MarkIngramUK]

We're also working toward WinUI being usable with a Win32 app model instead of UWP (informally being called "WinUI desktop"), so it won't necessarily have to be a UWP app.

This is the thing I'm most excited about. A native application with the full API of Windows available, whether that's Win32 or the Windows Runtime, able to have performant UI via Xaml.

[mdtauk]

We're also working toward WinUI being usable with a Win32 app model instead of UWP (informally being called "WinUI desktop"), so it won't necessarily have to be a UWP app.

This is the thing I'm most excited about. A native application with the full API of Windows available, whether that's Win32 or the Windows Runtime, able to have performant UI via Xaml.

Take a WinForms app, keep the codebehind, but replace the Form with a XAML Window, and have access to all the brushes and XAML Controls.

WPF would be slightly more complicated to just use the WinUI XAML in place - but at least the WPF controls could be styled to match the WinUI ones

[charlesroddie]

1. The namespace should be renamed. "Xaml" is not appropriate because Xaml refers to a markup language, which is incorrectly being used as marketing language (which changes often) for native UWP components. "Xaml" should be replaced with "WinUI". You can see how much confusion is caused even in this thread, where it is very often unclear whether "Xaml" refers to the .xaml language or to ui components.
2. Insofar as this moves WPF and UWP closer together this is good. They each have features not present in the other, and it makes sense to have "Windows UI" that combines the two. There may be some duplication of features but this can also be a transition path WPF -> UWP.
3. Decoupling from windows versions makes sense, but it's also OK to assume a relatively updated Win10, given that Win7 will be well past EOL when this work is finished.

[MarkIngramUK]

Xaml is the name of the UI framework. Hence Windows.UI.Xaml...

[Mike-E-angelo]

Xaml is the name of the UI framework

Xaml was a technology in WPF that enabled developers to powerfully describe and construct not only scenes of presentation within their applications, but applications themselves. That is, you could describe UI elements as well as POCOs. If it was .NET, it could be richly described with Xaml and loaded into an application context.

Lest we forget (and it sounds like we have) that Xaml stands for eXtended Application Markup Language, which means that it is a markup language that enables you to elegantly and efficiently describe .NET application components. While it was primarily used to describe user interface elements, it was not in practice relegated or constrained as such.

I personally ended up using Xaml to describe my entire application configuration, removing and replacing App.config -- and yes, even Web.config -- complexity except in cases for those external APIs that absolutely required it.

Xaml is not UI. They are two totally different concepts altogether but have unfortunately been conflated for years now under UWP. I for one would love to see the term "Xaml" untangled from these efforts, but I am not very confident that such measures would be considered, let alone undertaken.

[eklipse2k8]

@charlesroddie I kind of agree the naming is really arbitrary. Just a tangent, if you ever inspect the stack traces of things originating in W.U.Xaml namespace, it's actually internally in a namespace DirectUI. I'd love to know the story of Win8 if anyone here was around during those days, because I imagine there was a different story. DirectComp for compositing layers, DirectManipulation for smooth scrolling and rubber banding, and then Direct2D/DirectWrite as the vector graphics engine with DirectUI on top to pull it all together. Then for some reason, some of it was back ported to Win7, only the Xaml bits got exposed through the WinRT system, while all the other APIs were left as cryptic com interfaces with weird factories and patterns that you needed to see samples explain how to invoke.

Actually, now that I think about it, it'd be really nice if, just like W.U.Composition exposed DirectComp and DirectManipulation through WinRT (or is it a rewrite), Direct2D/DirectWrite had a formal home here as well. They all work together to enable various levels of escape hatches and touch points of fidelity if you're looking for it. Win2D is really half baked and not a good API either.

[MarkIngramUK]

Windows.UI.Composition is a re-write of DirectComposition I believe. The APIs are similar but not the same.

[reli-msft]

Stop assuming all monitors are sRGB anymore. Treat all legacy apps' colors as sRGB and do conversion for each monitor during composition.

[reli-msft]

This might be a little off-topic, but assume you already have a large Win32 appliation written in C++, you want to modernize the UI system, so you may want to use WinUI or Comp with minimal dependency, like use Comp only without in-box control set, or even without XAML.

[MarkIngramUK]

That’s already possible now though, we don’t need to wait for WinUI 3.0 for that.

[jesbis]

Thanks all for the feedback on naming. As noted we do have a distinction today between the "Xaml platform" and "Xaml language" (with its own different specs/dialects) which can get confusing. I don't think a major rebranding is in the cards but we're definitely discussing naming and namespaces.

---

Use Windows.UI.Composition in a C++ Win32 application without XAML for modernizing existing applications (like Photoshop). They already have a UI architecture.

This might be a little off-topic, but assume you already have a large Win32 appliation written in C++, you want to modernize the UI system, so you may want to use WinUI or Comp with minimal dependency, like use Comp only without in-box control set, or even without XAML.

Thanks for the feedback on this - I think this should hopefully be possible in the end with WinUI 3, similar to a "frameworkless" app using Windows.UI.Composition which you can already do today. We'll keep this in mind as we determine how to structure the WinUI NuGet package(s) and dependencies.

---

Stop assuming all monitors are sRGB anymore. Treat all legacy apps' colors as sRGB and do conversion for each monitor during composition.

@reli-msft could you open a separate issue to track that?

[reli-msft]

@jesbis 👉 #67

[mdtauk]

Apple today announced SwiftUI...

How about if Xaml Direct were to be given Visual Studio templates to enable developers to choose to make apps using code instead of XAML and code behind.

[Mike-E-angelo]

I don't think a major rebranding is in the cards but we're definitely discussing naming and namespaces.

Thank you @jesbis I appreciate you being so engaging in this thread. Usually, it seems that someone will make a post/announcement like this and then leave it for dead (or for others to sparsely manage), so it's encouraging to see that you as the thread author are not only being engaged but also being attentive to what others are saying. Especially when those others is me. 😆

And you are right: there's the 1) user interface platform and 2) the language/markup/description mechanism. In my critical remarks, I will say that I never give enough credit for the (first) user interface platform, as I know there's been a lot of great work by the Windows team around this. That's never been a point of concern as for me, personally. It's the 2nd area that draws my (and others') ire and consternation, and we see this in the UserVoice issues that have cropped up over the years.

All this said I would at least ask (beg, even 😅) to further consider branding efforts to better categorize these two spheres. I think "Xaml Direct" is the pinnacle of confusion here, as its name implies "Markup Language" -- it's right in the name! -- but there is nothing of the sort in its actual usage. Terribly confusing and misleading, and borderline abuse of brand, I would offer.

And speaking of Xaml Direct, @mdtauk:

How about if Xaml Direct were to be given Visual Studio templates to enable developers to choose to make apps using code instead of XAML and code behind.

As in something like CSharpForMarkup?

A much better and apt name than Xaml Direct, I would suggest. Of course, any name would be. 😉

[mdtauk]

And speaking of Xaml Direct, @mdtauk:

How about if Xaml Direct were to be given Visual Studio templates to enable developers to choose to make apps using code instead of XAML and code behind.

As in something like CSharpForMarkup?

A much better and apt name than Xaml Direct, I would suggest. Of course, any name would be. 😉

@Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

It is designed for middle-ware to write XAML UI from code, but what if there were templates to use it instead of XAML files? Just a thought to put out there...

[eklipse2k8]

@mdtauk YES! SwiftUI kind of looks like Xaml but done in code. I really love the idea of everything in code the way React does it. It's sort of old school to break up your design files and then link with some kind of code-behind, and I find it makes it hard to maintain.

A friend was just mentioning that they need the SwiftUI layout engine to work with the iPad Pro's 120hz display. So that's what they've been focused on. Quite fascinating really.

[mdtauk]

I made a new issue #804 where discussion about SwiftUI inspired changes could go @eklipse2k8

[Berrysoft]

Please DON'T FORGET to add templates for Visual Basic.😀

[reli-msft]

Let WPF to built on WinUI 3‘s lower layers!

[jesbis]

@reli-msft what benefits would you want to get from updating WPF?

If there are specific WPF features you rely on which you would like to see in WinUI then we'd love to hear more in the "WPF features that should be in WinRT [WinUI]" thread: https://github.com/microsoft/microsoft-ui-xaml/issues/719

[jesbis]

Closing in favor of new pinned issue #888

[sumitsahoo]

Really looking forward to this. Will solve many issues specially version related.

[weitzhandler]

@weitzhandler [on May 16 2019

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.

As per WinUI and XAML in general, I'd love to see improvement in the following aspects, some of which I find annoying and slowing down my work.

• A LOT more built-in converters There should be a ton of converters, some of which should even be used as a markup extension to reduce verbosity. This should also include negating simple arithmetic action, object to boolean converter (false by semantic value, i.e. empty string, empty collection, hidden visibility etc. per context).
• Same as above but with behaviors. There should be an easy port between binding and events/actions. Would be much easier if that would have been built-in and not have the dev live in doubt which non-tested NuGet to use.
• All missing stuff from WPF, such as some binding types, markup extensions, generic views and others.

Thank you!

[charlesroddie]

A LOT more built-in converters

Since Babbage's analytical engine, and Turing's theory of universal computation, it has been possible for a single computer which can run any program that any computer can run. You want to go back to a time when we have to create a new computer for every calculation you want to do.

The whole converters business should be unceremoniously dumped.

object to boolean converter

booleans are booleans. Other objects are not booleans. And there is no natural conversion from objects to booleans. Types are important in .Net and further untyped systems should not be exposed to users.

Yes and existing untyped systems like bindings should be dumped too.

[weitzhandler]

The whole converters business should be unceremoniously dumped.

I mean what are your alternatives? My pain point with converters is only that you have to re-write them yourself / choose from NuGet, and that they're so verbose. That in addition to them being non-flexible allowing no expressions such as arithmetic or negation etc.

booleans are booleans. Other objects are not booleans.

You're right, but when it comes to UI, it doesn't really matter. You wanna show/hide stuff based on conventional state of object. Not everything should have a dedicated visibility property.

existing untyped systems like bindings should be dumped too.

Huh? I actually think it has an advantage. Loose-coupling between V and VM can be good.

[weltkante]

existing untyped systems like bindings should be dumped too.

Loose-coupling between V and VM can be good.

For small projects maybe, but there are better abstractions for loose coupling than literally turning off the compiler assistance. If you ever had to maintain a large application with dozens to hundreds of views and want to refactor something which may be used in multiple sites, not having the compiler verify correctness of binding paths is a major degradation in developer experience. There is a reason why we have type systems in our languages, large projects are literally unmaintainable without tools to assist the programmer, currently UI languages are lagging behind a lot.

[simonferquel]

Compiled bindings help a lot for that.

[charlesroddie]

@weitzhandler I mean what are your alternatives? ... Not everything should have a dedicated visibility property. Huh? I actually think [bindings] has an advantage. Loose-coupling between V and VM can be good.

In a good reactive framework you can define observable variables (in code) like name:Mutable<string> and then map them to let visibility = name.map(fun s -> s <> "") and then bind them to view properties with visibility.bind someView.set_IsVisible or name.bind(fun s -> someView.IsVisible <- s <> "").

I use https://github.com/ReedCopsey/Gjallarhorn but there are various reactive frameworks around.

Note that: 1. everything is typed, unlike bindings. 2. Things (functions, properties, views) are referred to as objects, not by passing string names around, 3. functions are just functions, much less clunky than converters, 4. binding boilerplate, where simple object properties need to be given extra "bindable properties" etc., can be removed.

Views can still be written in Xaml, especially if they are simple mostly static layouts, with the disadvantage of magic strings everywhere, but the advantage of having a designer to give a live view. Better would be to have code which gives a live view. Very possible with an interpreter.

[HappyNomad]

Speaking of reactive frameworks, please check out Chain Reactive and tell if I should open source it.

[hupo376787]

Hi, can ms team solve all the bugs/features on uservoice? If did, that would a great step, more than WinUI 3.0.

[charlesroddie]

@hupo376787 I think you got downvotes because this isn't the thread to discuss the windows development platform more broadly, and even this repo is likely not the right place either as it focuses on just one aspect of this platform.

But it IS a problem that there is no place for open discussion of windows development platforms that microsoft and developers can take part in, and it IS a problem that the relevant microsoft group does not maintain any feedback mechanisms, having not updated or responded to that uservoice for several years.

[hupo376787]

@charlesroddie Yeah, it seems user voice is abandoned. I'll send my voice to Feedback Hub. Perhaps ms will ignore them, but I'll do my job.

[jesbis]

The UserVoice is being fully retired this month.

For specific products, GitHub repos (like this one) are the best place for feedback since the relevant engineering teams are actively using them.

For feedback that isn't related to a specific repo's product, please do use Feedback Hub. There is a "Developer Platform" category with various subcategories specifically for feedback on APIs and developer tools.

I know there's a lot of history and previous feedback currently on UserVoice (which we'll still keep track of), but both GitHub and Feedback Hub provide a more direct path to our engineering teams and workitem tracking than UserVoice ever could, so hopefully this should be a positive change. We're in the process of updating various support and feedback links.

We do see everything that comes in from either channel and really do appreciate feedback and bug reports!

[hupo376787]

@jesbis OK, got it.

[Dean-NC]

For WinForms, when using the new WinUI project template, will the Properties Window still work and be able to set the properties of the WinUI controls? I can code HTML all day long no problem (Asp.net MVC usually), but when there are so many settings available for controls, I've enjoyed using the properties window for the last 20 years.

[marb2000]

@Dean-NC I guess that you are asking about the XAML designer, no WinFoms/Windows Forms, right? If so, yes, the Properties Panel will still work for WinUI controls when you select an item on the XAML designer.

[Dean-NC]

@marb2000 I guess I naively thought that WinUI 3 would bring the new controls to WinForms in the sense that it would be mostly seamless, and that I could have a form with both legacy and WinUI controls on it, and that the Properties Window would work for both legacy and WinUI controls.

I read the entire posting above, and I've been following this with much excitement (as a WinForms developer), but I guess I've misunderstood the high-level workflow of how this will work (again, from a WinForms point of view).

I've said for a long time that WinForms could still be a great thing for years to come, but it's biggest weakness is that its basic controls look dated (textbox won't allow padding, so it looks skinny, small radio and checkbox buttons, etc.). Just the very basics of Win 10 controls (textbox, radio, checkbox) would go a long way to bringing new life to WinForms. Is there some article, or do you mind giving a brief description of how the workflow would be for a new WinForms project that wants to use both legacy controls and the new ones? Thanks.

[mdtauk]

@marb2000 I guess I naively thought that WinUI 3 would bring the new controls to WinForms in the sense that it would be mostly seamless, and that I could have a form with both legacy and WinUI controls on it, and that the Properties Window would work for both legacy and WinUI controls.

I read the entire posting above, and I've been following this with much excitement (as a WinForms developer), but I guess I've misunderstood the high-level workflow of how this will work (again, from a WinForms point of view).

I've said for a long time that WinForms could still be a great thing for years to come, but it's biggest weakness is that its basic controls look dated (textbox won't allow padding, so it looks skinny, small radio and checkbox buttons, etc.). Just the very basics of Win 10 controls (textbox, radio, checkbox) would go a long way to bringing new life to WinForms. Is there some article, or do you mind giving a brief description of how the workflow would be for a new WinForms project that wants to use both legacy controls and the new ones? Thanks.

More likely that you will be able to take your app project, add WinUI windows and pages, and use the modern XAML UI to replace your UI either totally, or bit by bit.

And there are XAML Islands for inserting XAML into existing Winforms and WPF UIs

[monkeynoises]

You Blazor team should work with Uno to get some of its hosting models included in Uno (in particular the server side), and/or to get the Uno UI (and thus WinUI 3) rendering/visual layer useable by Blazor....and/or maybe Xaml Islands for Blazor ?

[VagueGit]

I feel a little out of it here because most of the feedback comes from devs who work primarily in the xaml space. They generally seem to be looking for a better version of what they've got already. That might be good for existing users but I don't know if it will pull in many devs who have shunned UWP to date.

My team has developed only 1 UWP app. We won't be developing any more.

The insurmountable hurdle is the lack of a built-in tabulated report writer. We've tried all of the 3rd party report writers on the market that say they support UWP. Unfortunately none of them works well with UWP. Their UWP offering is usually a quick hack of their WPF/WinForms variant and won't work properly.

We use Stimulsoft Reports in our UWP product. It is very buggy and they have told us that they won't be fixing the bugs as their UWP uptake is so low.

I see you have data visualisation on the list. But the reason there are millions of battleship grey apps still out there is that many businesses don't care much about the visuals for internal apps. They want columns of numbers with sub-totals.

So if WinUI is meant to finally lure the forms over data devs, then we need a built-in tabulated report writer.

I hope this doesn't offend the visual people :-)

[Elmarcotoro]

I agree fully. How can we develop modern business apps without a reporting system that can be easily integrated with the app? it is a massive canyon that will stop developers moving over.

Business users need to be able to interact with tabulated data and then print it or export it into other formats. They also need to be able to create Invoices, quotes, statements and other instrumental documents.

It's my understanding that business/ enterprise is still the biggest consumer of Windows. Why is something so fundamental to the Windows ecosystem not being developed for UWP?

[jevansaks]

Thanks for the feedback @VagueGit and @Elmarcotoro ! Enterprise controls are a gap for us right now. But your timing is good, we are collecting feedback for the design of a DataGrid control. Please read and give feedback over here: #1500 .

[GeorgeS2019]

Likewise, beside square tabular data control, we need an opensource UWP graph control to creatively in democratise way share complex relationships through diagram control

[hupo376787]

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.

For the lack of various controls, we should not blame this team, but for the whole MS strategy. From the beginning of Satya abandon mobile, they prefer ios & android better, cause boss like them. The whole UWP ecosystem becomes weak and weak.

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

[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/