WinUI 3.0 roadmap - we need your input!

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

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?

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?

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.

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

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.

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!

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:

WPF is way more mature than WinUI (validation, existing controls, etc), so for enterprise WPF is a better fit
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.
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 devs. 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.

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 company. 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.

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)

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?
Thanks for reaching out.   Look forward to what's to come in this space :smile:

To put it simple. To us UWP, WPF or any Windows only framework, as awesome as it is, will never be enough.
TBH got really disappointed latest build too find out Uno got no official recognition more than a speech.
What's even more frustrating is that you're giving love to JS, React while neglecting the .NETers.
In conclusion, I'd want to see Uno officially backed up and boosted by Microsoft and WinUI actively embracing it at least as you do to React.

We need a XAML UI that also runs on the Web (Assembly).

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.
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.

@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.
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.

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.

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.

@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.

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.

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.

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.

I just want to say thank you to MS for listening more and giving .net developers awesome tools, but I can’t help but feel disappointed with UWP Xaml future after the build conference.
Reading this blog and many articles on the net you get the feeling that UWP is becoming exclusively “enterprise” and even that is debatable as many enterprises are becoming more OS agnostic allowing workers to use for example MacBook Pro’s.
Let me be clear that I am heavily invested in native UWP and Xamarin Forms (Android, iOS) and I luv the platform, but after MS announce native support for React, I’m about to jump ship.
I know I must make my UWP app more platform agnostic on the desktop therefor I was hoping that I can create a “hybrid app” with my current uwp app as the shell and incorporating more and more web front end technologies by using React in the mix.  Something like the proposed “Sets” feature that I understand is now delayed because of higher priorities within Edge,  would have been ideal for my current solution as it totally blurs the lines between native UWP and web technologies by running native as well as web technology in “windows/edge tabs”.  This “hybrid” approach will allow me to slowly embrace web technology into my current platform but also gives “native apps” a tab in the “browser” so to say. (from a consumer perspective) This also provides me an escape hatch if “native uwp apps” fail long term on the desktop.
The reason for above thinking is UWP does not provide me with an escape hatch as it can easily become the next Silverlight victim if there is no cross-platform capability soon.  MS is hedging their bets with making sure they don’t lose out on the PWA trend or their hand is being turned therefor React native support on Windows. The problem is I took a bet hoping by this time there will be a “path” for UWP/c#/.net into the browser or cross platform and that I can reuse most of my investment into those platforms.
I remember when every developer out there shouted buy Xamarin, it took MS forever todo that. I think most developers that are familiar with web assembly know that recently they managed to run a “full version” of Windows Server in web assembly will say buy the Uno platform and make it huge with significant investment. If a full OS can run on web assembly MS should give every .net  developer a migration path to cross platform capability to protect their existing investments.
You might say Blazor is there but frankly before I invest more time in a new platform I will rather learn React or you might say we MS have limited resource for all of this.  Surely when you pay $7.5 billion for Github it all becomes relative.
I think is critical that MS understand the reputational damage that a failed migration path to cross platform capability for existing UWP/Win32 investments.  Cross platform capability should be synonymous with .NET 5 and it’s not.  I’m not sure if baby steps to cross platform in this instance is going to work out for MS.

What templates would interest you most?

Do you mean project templates or item templates as well?

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

Would this just be a search and replace (less value) or also incorporate updating dependencies to new version (more valuable but not sure how you could tell)
Re: Backward compatibility for new features
Will being backwards compatible to Creators Update (15063) be a fixed reference point or will the plan going forward be to support the current version and X number of versions prior to that?
What will this mean for anyone creating an extension or own control or functionality they want to share publicly? Will they need to support that level of backwards compatibility too? Even to Windows 8.1?
Re: Migrating namespaces
Will it be possible to migrate an existing UWP in stages (I'm thinking pages) or will it be necessary to update the whole app at once?  If it's the whole app in one go that will make adoption slower.
What about migrating WPF apps? - Is the migration strategy to use XAML Islands which could use WinUI 2.x or 3.x? Could both be used in the same app?
Yes, splitting this issue into multiple, more focused ones will help captures ideas more clearly and avoid tangents.

Please replace all instances of UWP with the appropriate names, as it's not clear what you're referring to.

@mrlacey:

Do you mean project templates or item templates as well?

Item or library templates are interesting too! There are some great points in the replies so far about providing additional boilerplate and starter code which is something else we could consider adding over time, perhaps like the Windows Template Studio.

Would this just be a search and replace (less value) or also incorporate updating dependencies to new version (more valuable but not sure how you could tell)

Good question - what kind of dependency updates would make it more valuable? e.g. finding new compatible NuGet package versions?

Will being backwards compatible to Creators Update (15063) be a fixed reference point or will the plan going forward be to support the current version and X number of versions prior to that?

We envision the support version range to change over time based on usage. Rather than being restricted to a specific number of versions, we will likely continue to look at usage data and support the most active in-market Windows 10 versions.

What will this mean for anyone creating an extension or own control or functionality they want to share publicly? Will they need to support that level of backwards compatibility too? Even to Windows 8.1?

We don't currently envision imposing any additional requirements or "certification" for custom controls. Versioning would be up to you. The overall versioning story across May 2019 Update, WinUI 3.0 and future versions of WinUI is definitely a topic we want to go into more depth on soon though.

Will it be possible to migrate an existing UWP in stages (I'm thinking pages) or will it be necessary to update the whole app at once? If it's the whole app in one go that will make adoption slower.

Great question - thanks for noting that. This is also a topic we want to go into more depth on soon.

Please replace all instances of UWP with the appropriate names, as it's not clear what you're referring to.

@riverar: is there a specific usage or section that isn't clear?
We use the term "UWP Xaml" to refer to the Xaml platform that's shipped as part of Windows 10 and the UWP SDK, in order to distinguish it from other Xaml-based platforms (e.g. WPF).
We also refer to the "UWP app model" (packaging and installing, data and state management, the runtime lifecycle, etc.)), as distinct from a Win32 app model.

Even on Windows Desktops, users spend lots of time Browsing the Web.
I think that we need a way to develop decent Web Apps, using the (subset of the ) UWP vNext XAML + .NET (C#/F#/VB.NET)
I developed in WPF + ClickOnce for many years, then started to look at UWP. I like UWP, but it (or the next ver.) needs to be able to run standalone EXE, better Window APIs (allow to make a even custom Winamp Window style App if we WANT), more Printing APIs, easy interop with C dll, OCX, at least a subset of the Components should  Run on the Web.
Microsoft can do it. You did it with Silverlight, you did WPF, you did UWP. Now is time for the ultimate GUI XAML framework. And, in my opinion, Web must be supported, at least a subset of the functionality.

INotifyDataErrorInfo

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)

About this topic. Windows.UI.Xaml.Interop already has a INotifyCollectionChanged interface and Windows.UI.Xaml.Data has INotifyPropertyChanged. These two will be moved to Microsoft namespaces. Perhaps the System.Runtime.WindowsRuntime assemblies can do some mapping from WinUI to .Net

My only thing I want to add if it hasn't been added already is, I 100% support the MSIX/Appx package model and Win10 has done a fantastic job of fixing the shit that was installation and removal over the lifetime of windows. However, I always struggled to build a "UWP" application because of the weird subset of available API choices that were made in the AppContainer sandbox. As a C++ developer, that was frustrating and every year seeing you open the sandbox up further to allow the full Win32 API set has been a relief.
So if WinUI 3.0 lets me build an app with access to 100% of the Win32 stack, then this will be golden! I've tried using XamlIslands right now, and it's a fantastic escape hatch, but it's been unstable for me and it's got some work left before it's truly across the finish line.
Getting project templates that let me build a Win32 app, without being stuffed inside an AppContainer process, and let me access all of the advancements you've made with UI, then WinUI 3 will be a perfect fit for me.

@eklipse2k8  There still needs to be a permission system for accessing a user's files and devices, even in a relaxed sandbox.  Also I think there should be rules to keep in userland and avoid elevation to admin and kernal access - without some kind of official testing and code signing requirements.

Hello Microsoft,
I don't know how much this post will influence the topic of Font Rendering, ClearType, DirectWrite and the future of Windows UI but I'm one of the small but vocal & passionate few who have some serious grievances with the font rendering subsystems in Windows.
It is well documented pretty much everywhere on the Internet people's frustrations (or satisfaction) with Windows UI and font rendering. You'll have some that love font-smoothing, and you'll have some that absolutely hate it.
I am not here to discuss whether one is better than the other. Nor am I here to discuss registry hacks, 'font tuners', or how I can tweak OS settings to make fonts appear better. Trust me, I've done it all; even going so far as doing research to write a kernel mode driver to patch DirectWrite functions in Kernel mode.
I am here because I have a common visual medical condition called myopia / near-sightedness. I can see things clearly up close. But just at arms distance, my vision is right at the edge of my visual acuity and where text starts to become blurry.
Beyond arms distance, I'm required to wear corrective lenses. :eyeglasses: I'm sure we're all aware, desktop computer screens are right at about arms distance. Hence the problem.

Fonts that look smooth, look blurry to me.
Fonts with sharp edges (snapped-to-pixel) look clearer to me.

When fonts are snapped-to-pixels, the sharp edges are a visual signal to my brain that my vision is not out of focus. However, when I encounter font-smooth text, that visual signal tricks my brain to think that my vision is out of focus.
As a fellow developer who spends long periods of time writing code and looking at text, it's frustrating and hurts like hell. This is the major reason why I'm still running Windows 7 and not Windows 10. Almost all of Windows 10 main Metro UI is using font-smoothing everywhere.
To illustrate this font-smoothing issue, let's look at the services.msc MMC snap-in on Windows 7:

Do you see any blurry text that looks out of focus? Here. Let's zoom in a bit closer...

Goodness, gracious it feels like I'm looking at text cross-eyed in an autostereogram.
It turns out, in this specific case, digging through the control hierarchy of this window, the MMC snap-in hosts an Internet Explorer DHTML/ActiveX control which is rendering fuzzy text in the description panel. The sharp (snapped-to-pixel), "Help" menu and list of services is rendered with normal USER32 and GDI32 primitives.
This small example highlights one of the biggest issues with font-rendering in Windows. It turns out IE8 will respect the global operating system setting that disables ClearType and font-smoothing. However, if you install IE9 or above, IE9+ will happily ignore any and ALL efforts to disable font-smoothing. IE9+ just doesn't care and forces all users to view text on websites (and in ActiveX controls) with font-smoothed text.
The problem gets worse for users like me because as time has moved on, the birth of Windows 8 and Windows 10, Metro Apps, WPF and UWP have all taken the same approach as IE9+. All of these UI technologies under the hood ignore global operating-system wide settings that should be respected on our machines. That if we disable ClearType and font-smoothing at an operating system-wide level, we expect ClearType and DirectWrite APIs (and consequently, Metro, WPF and UWP apps) to not draw with any font-smoothing.
I know I'm not the only one with this problem.
A while back, Google Chrome did the same thing with their v31 release and tried following the IE9+ approach and switched all font rendering to DirectWrite ignoring global system-wide settings and it put the Internet in rage. See Chromium Issue 319429. Finally, after much gnashing of teeth, Google reversed course and corrected the issue in Chrome 37 for those users with myopic visual impairment and now respect the operating system-wide setting that disables font-smoothing.
Thanks to the powers that be and market forces, Microsoft Edge lost the browser war and is now adopting the Chromium rendering engine, but I hold with bated breath that the Edge team will respect disabled font-smoothing.
I am here only to advocate that Microsoft needs one global setting that needs to be respected, for all apps on the operating system, across all UI stacks, for those with visual acuity issues.
And as a friendly reminder, this is an accessibility issue for Windows UI in general, not one of visual preference.
Thanks,
Brian
:walking_man: :walking_woman: Missing Persons - Walking in L.A.

This means that the full Xaml framework would be developed on GitHub and ship out of band as NuGet packages.

NuGet is great, but supporting vcpkg (and CMake) would also be appreciated (for those of us with large, existing cross platform libraries).

What templates would interest you most?

In preference order:
Win32 + Xaml Desktop + WinUI
Win32 + Xaml Islands + WinUI
UWP + WinUI

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?

Yes, Xaml Islands is interesting, but as we target consumers, and not enterprise customers, the expanded backwards compatibility isn't a deal breaker - most customers are reasonably happy to update their OS (and given time scales for implementing changes based on new WinUI Xaml, having it locked down to 1903 would probably mean it's been out a year already).

The root namespace for Xaml, composition, and input APIs in WinUI will be different than the Windows UWP SDK root namespace:
Would it help if Visual Studio or another tool automatically updated namespaces for you?

This doesn't affect me, as we don't have a UWP app (currently use WPF for direct sales and WPF + Desktop Bridge for the store), but changing namespaces is a one time thing, and even in the largest code bases, a global find and replace for Windows::UI::Xaml isn't that daunting (we're all using version control right..?).

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

That's fine with me, they should be treated as separate incompatible libraries. You either target UWP Xaml, or WinUI Xaml. As mentioned above, the one time conversion shouldn't be that difficult.

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.

Microsoft needs to pick a technology and stick with it. For years we've been promised the latest and greatest desktop UI frameworks (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml, and now WinUI Xaml). Whilst the choice is great, it leads to a fragmentation of functionality and developer knowledge. It's much easier to have one session / one webpage / one stackoverflow answer on implementing a feature in Windows, vs 7 different ones depending on the tech. If WinUI Xaml is the future, the Community Toolkit needs to be updated to take advantage of it.

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

I've been holding off doing anything with UWP Xaml because the functionality just isn't there (in comparison to Win32 / WPF), and I assume I'm not alone in that respect. As such, full compatibility isn't an issue.

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 Xaml components with WinUI 3?

N/A

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?

There's no mention of Xaml Desktop in the roadmap. Does this fall under the remit of WinUI?
I've mentioned this before to people at //Build/, but the reason for not adopting UWP Xaml before is that it was impossible to make an application that makes use of existing C++ libraries. For example, when a user chooses a file with FileOpenPicker, the result is delivered as an IStorageFile, and there is no way of passing this to an existing 3rd party library to open (e.g. libpng, libjpeg, etc). This is why we've had to stick with WPF, so if Xaml Desktop or Win32 + Xaml Islands allows us to live without these restrictions, then yes, it would enable us to use WinUI for a new application.

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 Win32 app with WinUI (and packaging with MSIX).

If you've got any questions, please let me know, I'm happy to discuss further.

Actually hoping there is way to call Compact Overlay from WPF/WinForms.
We just need a administrator permission system like "Draw over other apps permission" in Android.
Hope this app model + packaging (UWP + AppX, Win32 + MSIX) allow that (Full Abstraction inside Sandbox)
Isn't Windows suppose to be most advanced and unlimited possibilities, with best security?
No by crippled feature for security.

Thank you for opening up to the community for input regarding the roadmap.

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

On to the point, we have quite a number of UWP apps in use for enterprise clients right now, and I hope the migration path will not be that hard. If there's breaking changes It'd be very nice to have a migration tool similar to the .Net Framework to .Net Core that generates how compatible our migration path would be, this should report anything that might need changing (e.g. APIs that might be deprecated or behave differently) and an option to automatically change the namespace if possible. This way the migration path for UWP to WInUI will not be as volatile for use enterprise users.

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?

Yes, but wasn't much of a problem since moving forward all our newly developed desktop apps are using UWP communicating via an API backend, and most of our clients are already running Windows10.

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?

The desktop team is already excited for the news of WinUI 3, but as stated above dreads the migration of all our UWP Apps to it if the path is not that smooth.
As for the general XAML since the whole XAML UI framework will live decoupled from Windows as others have voiced make it so that it's possible to swap out the renderers. This will open up the possibility of running WinUI XAML on other platforms which is a huge defining factor nowadays when people choose a stack to stick with, as evidenced with the popularity of Electron and JS frameworks taking advantage of such for small companies that do not have the manpower to specifically develop native codebases for each platform.
Also add that with WinUI 3 onwards should also improve on the XAML dialect as well, maybe introduce a version namespace / Doctype to specify which version of XAML is being used so to keep backwards compatibility for older apps. There's alot to be made on making XAML less verbose or chunk some boilerplate out, like having to write INotifyPropertyChanged with backing private setters for one instead of just being a simple property attribute say NotifyPropertyChangedAttribute and let the build step inject the implementation to avoid runtime overhead or DependencyProperties for custom controls to simplify making components. Maybe also take some of the improvements on the Razor team for some of the good parts they have.
These requests may or may not be feasible, but I love XAML and would love for it to continue to improve so I'll state some of the pain points (but still serviceable) I and some on our team had when developing for them.

@mdtauk I'm not opposed to file security but the underlying kernel should prevent you from writing in places you're not authorized to as opposed to using a whole new set of API and abandoning the win32 file API. Also, I know this is getting way off topic, but the StorageFile/StorageFolder api are horrible replacements, not even accounting for file security.  Further, it should never have been a restriction that sandbox'd apps need special MS approved permission to write in user's documents folder.  Just for example how crappy the file story for the AppContainer effort was, it was impossible to create a sqlite DB anywhere except in the user's hidden LocalData folder. For a desktop system where users want to create, save and open files, and save as, yadda yadda, it put the burden on the software developers that they needed to retrain their users how to manage users' content.
As far as administrator access, the Oct 2018 release added "allowsElevation" as an entitlement, which makes sense. An app could allow a user to run as administrator if they need that broad system level access for some feature set. We're not all building cute little photo editors and flow chart apps.

@MarkIngramUK Thank you for your comments, Just one clarification. The Xaml Desktop concept that was presented in a Sneak Peek at //Build 2019 has been renamed to WinUI Desktop. This new Visual Studio project will use a Win32 app model, with WinUI as presentation framework, and it can be native or managed (using .NET Core 3).

Thanks @marb2000 - is this within the WinUI 3.0 timeframe?

@marb2000 by WinUI Desktop, you mean Win32 apps with Xaml Islands?  Which build session was this shown in?

One thing the WinUI team should watch out for with the WinUI 3.0 rename: If you rename any of the types that are projected in .NET, then the projections won't work (and we aren't planning on adding any more since it's not a maintainable extensible system). Here's a list of the types that we project: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h
Any changes to different types than these types will require users to wrap their objects in new objects that implement the new interfaces or copy their data into the new types. In particular, the INotifyPropertyChanged and INotifyCollectionChanged types are of interest with respect to XAML Islands and providing downstream support.

INotifyDataErrorInfo
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)
About this topic. Windows.UI.Xaml.Interop already has a INotifyCollectionChanged interface and Windows.UI.Xaml.Data has INotifyPropertyChanged. These two will be moved to Microsoft namespaces. Perhaps the System.Runtime.WindowsRuntime assemblies can do some mapping from WinUI to .Net

Thanks for the reply, but why you need it in Microsoft namespace if .NET Standard has it in System.ComponentModel already? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky. NET is only one framework you can use to make apps with UWP XAML.  They want text field validation available for Devs, no matter what athrframework

@mdtauk , no, WinUI Desktop (previously Xaml Desktop) allows you to use Xaml with Win32 directly, without the use of the island.

@marb2000 It'd be great if the Application Packaging Project allowed you build an AppX with a Win32 window and include WinRT components in the same easy way that a UWP project does. There's lots of things that don't work without manually editing the vcxproj files such as adding resources and cppwinrt compiler generating the headers from included WinRT components.

Another Project that is important for this new UI is the PropertyChanged.Fody by Simon Cropp that allows automatic implementation INotifyPropertyChanged (I tried with C# / F#). See https://github.com/Fody/PropertyChanged
It allows a simple code like this:
[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

wich we can use to Bind to the UI.

One thing I would like to see in WinUI 3.0: Currently, the UWP XAML compiler (genxbf.dll) can only be invoked directly by MSBuild when referenced from a csproj, vbproj, or vcxproj file. This is because there is no command-line tool that can be used to invoke this functionality. This strikes me as a very weird decision, as nothing else in the Windows 10 SDK download requires Visual Studio. (The WDK add-on also includes Visual Studio targets, but those targets all invoke command-line tools that are usable independently of VS.) I would greatly appreciate the addition of e.g. XbfCompiler.exe and XbfCodeGen.exe to the SDK’s bin directory. (The former EXE would compile XAML files to XBF files, and the latter would generate the code-behind files that are required to reference XAML types from code.) This would be mainly useful in C++ projects that use CMake or another, non-Visual Studio build tool, but could also be used for C# and VB.NET projects if required. Thanks!

@MarkIngramUK do you happen to know where I could learn more about WinUI Desktop.  Those Build 2019 sessions are not available to watch online.  Sounds like important information that should be linked to in this repo

@mdtauk It was mentioned in a so-called Sneak Peek, which is only for Build attendees. Afaik there's no recording. I was also not there, but there's a slide - maybe the best slide :-) - available on Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk The WinUI 3 roadmap has the latest information and diagrams which are even more up to date than what was shown at the Build sneak peek. There’s no such thing as “XAML Desktop” nor “WinUI Desktop” that was just a somewhat confusing word choice (in retrospect) on a slide that got photographed. The concept being communicated (and the roadmap tries to explain this more clearly) is that for WinUI 3 we are working to make it so you can have a new Win32/Desktop app project template that uses WinUI 3 for it’s UI (just as today there are ones for things like WinForms, WPF, MFC, etc.) in addition to an updated UWP app project template that uses WinUI 3.

The 3.0 roadmap seems quite reasonable for the following strategy: enable any Windows client app to use XAML and the "modern" WinUI controls.
However, this strategy seems short-sighted if one considers the reality of the today's market: for a lot of app development, Android and iOS are the primary targets, and Windows is a nice to have. For the .NET developer, Xamarin gets you decent Android and iOS support, but their Windows support is sub-par. So for native mobile/desktop apps, Win UI 3.0 does nothing to simplify cross-platform development for .NET developers.
What I'd really like to see is a go-forward XAML dialect with truly universal aspirations. I should be able to write a .NET app using XAML, and have that app run on Windows, iOS, and Android. The app should be truly first-class on each platform and have access to native elements as needed. As mentioned, Xamarin is a good start, but its dialect of Xamarin is very different, it has poor Windows support, and none of the work that you're doing helps.
So, tldr, good that you're continuing to provide a modern UI platform for Windows. Good that you're making it easier to use from different kinds of apps. Bad that you're not aspiring to cross-platform support.

Optionally disable or opt out of the legacy-mobile application lifecycle behaviors, such as suspend + tombstone.
The reality is that UWP is a desktop environment and at least for games, the user may often minimize the app which usually leads to suspending/tombstoning the app. This is a jarring experience and one that is very different from any win32 desktop app or game. Requesting an extended deferral, which will likely still expire, is not enough to seamlessly deal with this.
While this lifecycle is handy for some apps, it's detrimental to others. Ideally a desktop app or game should be able to declare a capability that allows for the app to opt-out of the suspend+tombstone lifecycle model, which would prevent it from being eventually suspended when minimized.

@natemonster
Per: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

On desktop devices, extended execution sessions created with ExtendedExecutionReason.Unspecified have a battery-aware time limit. If the device is connected to wall power, there is no limit to the length of the extended execution time period. If the device is on battery power, the extended execution time period can run up to ten minutes in the background.

A tablet or laptop user can get the same long running behavior--at the expense of battery life--when the Allow the app to run background tasks option is selected in Battery usage by app settings.

@TonyHenrique when [you mention Fody](2 days ago), is this because you want to create an awareness of it, or are you saying it should be built in to WinUI?

Item or library templates are interesting too! There are some great points in the replies so far about providing additional boilerplate and starter code which is something else we could consider adding over time, perhaps like the Windows Template Studio.

@Jesbis I'm a core contributor to Windows Template Studio and am watching the WinUI roadmap with a view towards what we do in the future and how we introduce support for WPF. ;)

what kind of dependency updates would make it more valuable? e.g. finding new compatible NuGet package versions?

Being able to detect NuGet updates would be more useful but there are other potential compatibility issues with taking updates. I'd make detection of new versions and automatic conversion a low priority. There are so many considerations that it would be a big project in it's own right and I'd rather see time invested in the platform that a tool like this.

@mrlacey I mentioned Fody because I think it is an interesting solution and we need a better way to avoid the INotifyPropertyChanged boilerplate code.
It works on C# classes and even on F# Records.
So on the WinUI roadmap there should also have this.

@tonyhenrique / @mrlacey I think the Fody stuff (OAP) should be out of scope. The WinUI team have enough on their plate already, and I think it's better to have the weaving in separate projects (much faster release cycles in case of improvements).
And I think this is actually a .NET (IL) implementation detail of the models, not actually anything to do with WinUI (although it can listen to the change events). My suggestion is to keep them separate. For example, I use Catel and it has its own Fody weavers to make sure everything gets weaved correctly.

What I'd really like to see is a go-forward XAML dialect with truly universal aspirations. I should be able to write a .NET app using XAML, and have that app run on Windows, iOS, and Android. The app should be truly first-class on each platform and have access to native elements as needed.

There is a long standing proposal to go in that direction: Cross platform UX for .NET 5 - original title Cross platform UX for .NET Core 3.0. The overwhelming support of community for it is obvious and we can hope that MSFT will realize that this is the best direction to develop any UI framework working on .NET. There is pretty much no reason to keep separate codebases for different platform groups and forcibly creating separate developer skill sets based on different UX frameworks supported by .NET.
By creating single UX for all platforms we cancel all inefficiencies in framewrk development and lower the barriers to developer adoption. Only these two aspects should be sufficient to consolidate all UX XAML based frameworks.

@mfeingol / @4creators , I would settle for

The app should be truly first-class  on each platform

on Windows to start with...
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.

Now that with WinUI3.0 and above the code is decoupled from Windows 10, are there plans in the future for WinUI to work on Linux and Mac?

@jesbis Touch interactions will be kept in WinUI 3.0?

Thanks for the clarification, I had assumed the way 3.0 would work was to include Xaml Islands in WinUI, rather than use the Community Toolkit.
With it becoming XAML plus Win32, it makes more sense, especially with the Windows Core OS rewriting it's shell in XAML.
As I understand it now, this rich Win32 API access is in C and C++ | with anything in C# relying on .NET (all be it now .NET Core).
Perhaps there should be a safe and simple way to access these Win32 APIs, as well as more entry points for displaying an apps UI?

System Tray XAML flyout for WinUI 3 apps

simple Picker UIs for Hololens/Xbox/Surface Hub/IoT, etc

updated XAML customisable Common File Dialogs, and folder pickers

simple C# .NET access to Win32 APIs

compact setting for all XAML elements, which match Win32 and WPF control sizing (this will help Frameworks to sit comfortably together)

matching control styles/fonts/accent brushes/acrylic when using WinUI

clear definition of which devices require the WinRT/Mobile lifecycle

Xbox Next control styles built in for Xbox app development and testing on Windows

Store and single exe/MSI/APPX packaging and downloading supported by default, NO INSTALLERS, centennial type file system virtualization by default

WinForms WinUI 3.0 - simple UI, access to MFC, mouse and keyboard only

WPF WinUI 3.0 - dense UI, 3D rendering, DPI aware, simulated touch and basic ink support

Xaml WinUI 3.0 - full touch, MR, gamepad, inking, voice, mouse, keyboard.  Dense and simple UIs.  New windowing support.  MR 3D rendering.  Optional managed lifecycle, or desktop lifecycle. Best of all worlds default for shell and reworked inbox apps, with Win32 versions of inbox apps like notepad, charmap, paint, file explorer - open sourced and available from the store.

Touch interactions will be kept in WinUI 3.0?

@r7dev yes, the plan is to keep the same level of touch support.

F# is ignored on the WinUI 3.0 roadmap. Microsoft ignoring one of its products once again.

Win32 API Thoughts
Something I also thought about is the reason win32 has stuck around too. I think there's an assumption that this is because of legacy projects, but it's actually quite deeper than that. The Win32 ABI is super easy to hook up with your language of choice, nodejs, python, rust, go, ruby, c#, c++, etc. etc. If my core project is in rust for example, and I want to generate a window to manage the output, as a rust developer, it's super powerful to access the win32 API set and build a front end in the same language.
On OS X, to access AppKit you just needed to bridge the objc_msgSend C API and gain access to the entire obj-c infrastructure. All of those languages above did a really good job of bridging that and it made it easy to write in your language of choice and produce something compelling.
So if you want to to make WinUI 3.x be the true path forward for accessing low-latency, low-memory, high quality Win32 UI, you need to consider the ease at which other language maintainers can tap into the infrastructure.
UI Consistency
If you're really planning to decouple the UI from the system, what is the plan for the UI remaining consistent with each OS upgrade? When Apple makes tweaks to shadows and gradients in AppKit or iOS, Apps that rely on the system frameworks inherit all of those tweaks and remain consistent.  It's also going to make it hard for you to add system-wide experiences because Apps that are locked to UI infrastructures 3 years ago may not operate well with some new system service, so they will have another compatibility layer as time goes on.
There will always be features that need to be opt-in, I can think of Dark Mode as something that if the app wasn't designed for it, it really wouldn't make sense to offer it as an option, but there are still tweaks to system components that would change over time.
Binary Size
What is the planned story for delivering all these UI.dlls with our projects? Will these things be 40mb of runtime that need to ship with our projects? What will happen if a project is abandoned, will they start to look outdated because they use old UI frameworks?
One of the benefits of C++ is that it has a minimal amount of library overhead depending on the codebase. Certainly if every single app from here on out required WinUI 3.x, that is going to be 40mb x number of apps.

Binary Size

WinUI is already a dependency, just like .NET is. It's already a system-wide library. :)
You don't have duplicated dlls, and you won't have it.

"Something I also thought about is the reason win32 has stuck around too. I think there's an assumption that this is because of legacy projects, but it's actually quite deeper than that. The Win32 ABI is super easy to hook up with your language of choice, nodejs, python, rust, go, ruby, c#, c++, etc. etc. If my core project is in rust for example, and I want to generate a window to manage the output, as a rust developer, it's super powerful to access the win32 API set and build a front end in the same language."
This is a mixed bag though as while implementing WinRT support for a new language is a huge hump to get over, once you do, you end up with autogenerated typed bindings to any new APIs. I've been working on a Rust project that bridges Win32 and WinRT recently (using the Composition APIs in a Win32 window), and the Win32 parts have definitely been more of a pain overall even though I've had to clumsily work around the remaining lack of Rust support for some WinRT features like class inheritance.  (It does definitely help that using Composition inside Win32 is now possible, since it allows incrementally improving support for this feature instead of having to tackle the entire app model all at once)
Probably the biggest problem is that the documentation for low-level WinRT ABI details is kind of disorganized, and there's just very little understanding or awareness of them in the world/community, I'm hopeful this situation will improve with the xlang project though.

What templates are you most interested in?

Currently I prefer to start from a Blank App (Universal Windows) project. I like templates with a preconfigured framework too, but only when i want to try out something quickly. A "Main Menu" Template and MDI Template for UWP would be nice too (as those templates exists for WinForms too)

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

Yes, I'm aware of Xaml Island. If I can, I'll try to stick to a pure WPF or pure UWP app. I wasn't in a situation where I'd would require such a feature.

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

Yes, sure if it works reliable! I'm surprised by the many comments which don't appreciate such a nice feature. Also this feature could check if an update to WinUI 3.0 is doable, adopt the XAML Code, adjust the namespaces and install the required WinUI nugets.

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

I would expect to change only the namespaces of the control to work full with WinUI 3.0. I don't want to invest much time in upgrading to WinUI 3.0

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

I'm using third party UWP Xaml control libraries (like Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement ).  I think I would be able to upgrade simple controls from third party libraries like a Dockpanel by myself to WinUI 3.0.

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

Create a "Blank App with WinUI 3.0" project template in Visual Studio for UWP. The WinUI 3.0 dependency will be installed as nuget (like in WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...]. I absolutely would prefer such a solution as long, as I get all basic controls. I would expect that all classes from Windows.UI have an equivalent class in the Microsoft.UI Namespace.
The main topic in WinUI 3.0 was all about controls and windows 10 compatibility which can be used from UWP and WPF or WinForms via XAML Island, if I'm correct. Are there any chances that the UWP XAML Markup gets somehow additional features?

Style Triggers missing
Style `BasedOn={StaticResource {x:Type TextBlock}} missing
Defined DataTemplates with DataTypes aren't automatically applied like in WPF (only via Key)
Why is every second Windows.UI.Xaml.Controls control (TextBlock, Border,...) declared as sealed?! Please don't do this in WinUI 3.0 with UWP.
Markup Extensions for WPF parity
This was already mentioned, but I'm gonna mentioned it one more time. Its sad that UWP doesn't make use of the System.ComponentModel.IDataErrorInfo. That way I can't share my Model project between diffrent Platforms.
ReportControl (for Enterprise Applications)

I'm really looking forward to WinUI 3.0 and its backward compatibility !

F# is ignored on the WinUI 3.0 roadmap

Are there any chances that the UWP XAML Markup gets somehow additional features?

@Happypig375, @mfe-:
The roadmap only covers the initial 3.0 release, and for the initial release we're mainly focused on parity and backward compatibility for existing features, with a small number of new features.
If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

When it comes to languages, it would be neat to mix and match (which should be fine if everything is compiled down before packaging)
F# used for some back end logic - C# for Databinding and UI code - C++ for controls and maybe some low end Win32 hooks or even to launch a WinForms dialog.
All code languages are equal, interchangable, with WinUI 3.0 handling all the UI

That’s xlang 😉

That’s xlang 😉

@MarkIngramUK  Hmm, I thought it was a bridge between languages, which abstracts each language, rather than allowing code files from multiple languages in a single project.
I have kind of struggled to understand the purpose of xlang - glossing over the updates that have been happening in the repo (but still have it in my watching list)
Does xlang work pre or post compiling?  Is it its own abstracted language which can be projected, or does it just sit between existing code files?

Yes, you can’t mix languages in a single project. It’s a bridge, but still useful for those purposes.

@MarkIngramUK  I guess so if its code that can be compiled then included.
It would be good to be able to use C# to access native Win32 features

@jesbis I'm honestly more interested in a cross-platform aspects of this project...
I think that at start, you guys should rename it to something more generic and not strictly to "Windows".
I got it that the initial implementation should be strictly focused on Win32 and back UWP/Xamarin apps and Windows but just OSS it and make it from the beginning called like a "Windows-only" framework, will definitively not get much traction just like UWP didn't and developers from other platforms would never get interest on it.
If the target on .Net 5 is to be "One .Net Everywhere", which is basically what everyone always expected since .Net 1.0, the foundations for "Anything but Win UI" framework should start cross-plat.
A very good example on how to make it right is Google Flutter. Flutter is on its very early days, but got A LOT of traction due to the fact that their core (aka Flutter Engine) is 100% cross-plat and works everywhere (including IoT, Win, OSX, and now even Web!).
That is just my 2c. I would love to get back to work on Xaml but if it keep on the same line as on UWP, I'm afraid it will not get the right traction and will be another attempt to re-write WPF that will eventually need another attempt in the future and so one so forth.
Please don't take me mad and don't take my comment as a bad criticism. I just wish that the efforts on the UI on .Net world would get something like Flutter, .Net Core 3.0/.Net 5, and even Blazor.

For the record, I event started a project to rewrite/port Flutter engine entirely on C# and .Net Core due to the lack of options on .Net World...

BTW, CoreUI is a good name...
Kudos to Jake Helfert for that suggestion 😄
💃

BTW, CoreUI is a good name...
Kudos to Jake Helfert for that suggestion 😄
💃

CoreUI may get confused with .NET Core
WinUI is very much focused on Windows, but the XAML framework within it, could get renderers for Metal (iOS and macOS) or Vulkan (Android) - and FabricWeb could be the PWA/ChromeOS way to handle the other platforms.
If the team ever choose to bring the presentation platform over, and Xland or Xamarin could handle the runtime for cross platform apps.

About the migration from inbox UWP UI to WinUI 3.0, I'll quote a recent blog post from @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ):

Fun bottom note: What’s happening to UWP is not that it’s being killed: Microsoft is pivoting bringing the bests parts to where we need them. This actually happened before, but it was unfortunately not used as an opportunity to perform a pivot. Remember Silverlight? Guess where .NET Core’s cross-platform CLR came from. And lots of Silverlight’s code also ended up in UWP. Had they only pivoted and said “Yeah we agree Silverlight doesn’t make sense in the consumer spare, but it’s thriving in the enterprise space, so let’s build on that, and we’ll evolve it into .NET Core and Windows Store”. Unfortunately that didn’t go so smooth, and lots of people still suffer from PTSD and wary of whatever Microsoft does that appears to be killing off any technology.

I really think it's important to remember that being perceived as killing off or resetting existing frameworks without giving developers and codebases a good way forward doesn't just affect developers on the existing framework - it can cast a cloud over future efforts as everyone wonders why the new thing won't just meet the same fate. This isn't meant as a remark on any specific proposed migration approach, more a response to the comments to the effect that migration doesn't matter because not many people are using the existing inbox UI framework. That's not the only consideration!

CoreUI may get confused with .NET Core

I actually like .NET Core UI or CoreUI way better.
The UI should be an abstract model that has nothing with Windows. It should render anywhere there is .NET Core.

@mdtauk

CoreUI may get confused with .NET Core

I actually like .NET Core UI or CoreUI way better.
The UI should be an abstract model that has nothing with Windows. It should render anywhere there is .NET Core.
BTW, please see my updated comment above.

@weitzhandler  WinUI 3.0 is about combining various Win32, .NET Core and UWP frameworks with a single XAML framework, and interoperating with WPF, WinForms, and MFC++
XAML on Windows is rendered down to Direct X.
If you wanted to take that same XAML, combined with .NET Core, and make it work on other platforms.  You would need to write new renderers for those platforms.  iOS and macOS use Metal as their Direct X equivalent.  Android uses Vulkan.  No idea how Linux handles rendering, I would guess its just Open GL.
Microsoft will not want to do that themselves because it does not make sense for them.  But WinUI 3.0 will be open sourced - so others could choose to try to bring it cross platform

@mdtauk
Thanks for clarifying that. Flutter is probably the future for me.

@mdtauk
Thanks for clarifying that. Flutter is probably the future for me.

That is just my understanding, I could be mistaken.
Flutter is supposedly getting Windows support in the future.  And React Native support is coming to Windows also.  Plus there are PWAs if you are invested in that Web HTML and Javascript world.

 Especially for someone who's been using C# and XAML extensively for years, no need to explain about that.
XAML is going to die, because more and more customers require their apps to be portable. Windows only apps is a doomed future. Flutter is making rapid progress and with their announced Windows and web support, they're going to win.
You finally convinced me to start learning it. @adamped was right all along.

To me the whole WinUI story can make more sense if they also take in consideration allowing at least a basic subset run cross-platform (macOS, iOS, Android) including Web, and also offer a better F# support and project templates (including XAML Two-Way Binding to F# Records, and also a more functional Elmish way)

HTML is a horrible non OO markup language, and JS sucks ♭@lls. Especially for someone who's been using C# and XAML extensively for years, no need to explain about that.
If MS isn't going to race Flutter and make XAML multi-platform, it is going to die, because more and more customers require their apps to be portable. Windows only apps is a doomed future. Flutter is making rapid progress and with their announced Windows and web support, they're going to win.
@mdtauk, do you work for MS?

@mdtauk

Microsoft will not want to do that themselves because it does not make sense for them.

@jesbis Can you please comment on that sentence? Would be nice to know where MS is headed and whether XAML is going to become officially xplat.
@mdtauk

Plus there are PWAs if you are invested in that Web HTML and Javascript world.

 Especially for someone who's been using C# and XAML extensively for years, no need to explain about that. I've made numerous projects with HTML, CSS and JS, and the more I use the more I hate it, it's a total mess-up.
If MS isn't going to race Flutter and make XAML multi-platform, XAML is going to die, because more and more customers require their apps to be portable. Windows only apps is a doomed future. Flutter is making rapid progress and with their announced Windows and web support, they're going to win.

XAML needs to be environment agnostic just like HTML is without taking 100mb+ for even the most basic tool apps as HTML apps do. This means a XAML framework that is written in pure C/C++ or C# and can be hosted in WASM, Win32, UWP, iOS, Android, macOS, Linux etc with minimal effort when it comes to porting. You need an agnostic rendering backend like game engines use to start with.
None if this UWP focused XAML is solving any problems my company or me personally has had for years with XAML... and thats portability. TBH MS is going about UI completely wrong and its going to get no where fast (its wasting a lot of valuable time for a lot of people). This UWP XAML hackery just doesn't come off well to people I show it to... which is sad because it just means an never ending push back against the adoption of XAML and I have no more arguments at this point.
The only way to save XAML in my opinion is:

Create a new agnostic / portable framework base for .NET Core and C/C++.
Create an agnostic rendering abstraction layer anyone can extend via pull-requests.
Just like HTML keep the XAML focused on single windowed app concepts (just as is done in games as well) BUT allow extended desktop features for multi windows etc. (This allows the app to run in almost any context just as a games UI can)

Simply put there are two conditions that have to be combined into one before XAML adaption will be excepted.
#1 MS needs to back the XAML project or people fear it falling out.
#2 It needs to be cross-platform or everyone is going to be stuck with crazy bloated HTML runtimes.
Anyway thats my two cents and if WinUI 3.0 is designed right maybe porting will be possible. At this point though idk what to feel.

There's a few comments about being cross platform in here, and I'm not so sure that WinUI would need to be cross platform to be successful. It wouldn't work well on Mac or Linux anyway, as it's different enough that it wouldn't feel native on either of those platforms. This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.
Also... Fluent on Mac would feel clunky, just look at iTunes, Apple had to port their entire UI system to Windows, and it definitely feels out of place. Font rendering is different, the animation curves and shadows and color choices just feel so out of place in Win10. I mean, it's fine and usable sure, but I prefer spotify which doesn't try to emulate any desktop UI and just uses a web browser under the hood. On Mac, seeing the reveal spotlight with square components in a desktop full of rounded corners and no reveal effect would clash so hard.
No, I think this project should focus on offering the best in class way to make native Windows software, for developers who want/need to build windows software. Leave the cross platform stuff to the Electron/Typescript teams to solve.

There's a few comments about being cross platform in here, and I'm not so sure that WinUI would need to be cross platform to be successful. It wouldn't work well on Mac or Linux anyway, as it's different enough that it wouldn't feel native on either of those platforms. This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.
Also... Fluent on Mac would feel clunky, just look at iTunes, Apple had to port their entire UI system to Windows, and it definitely feels out of place. Font rendering is different, the animation curves and shadows and color choices just feel so out of place in Win10. I mean, it's fine and usable sure, but I prefer spotify which doesn't try to emulate any desktop UI and just uses a web browser under the hood. On Mac, seeing the reveal spotlight with square components in a desktop full of rounded corners and no reveal effect would clash so hard.
No, I think this project should focus on offering the best in class way to make native Windows software, for developers who want/need to build windows software. Leave the cross platform stuff to the Electron/Typescript teams to solve.

I don't think anyone really wants full Fluent design on other platforms, but rather just be able to maximize common code between platforms.
This is something that has already been addressed by the Microsoft Design team. The Fluent website explicitly says "design and build custom apps that are natively iOS while still uniquely Fluent". The Fluent docs show that native control styling should be used.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button
What should be avoided, is having to design and maintain completely separate UIs for each platform. That doesn't mean that it needs to look identical on the surface, but should share a common layout, and UI designers should be able to reuse as much as possible. The actual styling does not (and should not) need to match the Windows 10 system styling.
In essence, what is wanted is an easy way to get Windows apps running on other platforms, without having to remake the entire UI - not to bring Fluent design to other platforms. That would enable people to write for Windows first, and then bring their app to other platforms without a lot of work.

@KyleNanakdewa Well if they're open sourcing it, let some Xaml fans go off and create the underlying platform bits. I think it's probably architecturally complex enough and takes advantage of Win32 enough that i suspect the port would be a massive undertaking.

I think this project should focus on offering the best in class way to make native Windows software

This argument might be compelling if Microsoft didn't already own an existing cross-platform XAML toolkit that just happens to offer a very different dialect of XAML than WinUI.

Plus there are PWAs if you are invested in that Web HTML and Javascript world.

Yes... "that world" which is quickly replacing everything we know about native OS/Store/Hosted development. 😆
https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097
Consider "that world" exists on all modern devices with an HTML5 renderer:

Apple with 1.4 billion
Droid with 2.5 billion
Windows 10 with 800 million

You will notice that Windows now has the smallest market share, meaning that any offering that caters specifically to this platform will be one that reaches the smallest marketplace.  Doing so only lowers an application's maximum potential market reach which, in turn, lowers its maximum potential revenue ceiling.
Compare this with Flutter, which with one codebase reaches all of the aforementioned marketplaces, along with the web, which as mentioned is composed in aggregate of all three -- therefore maximizing market reach and potential revenues for application developers while reducing the necessary costs of building applications to do so.
While I am a huge fan of the efforts here to open source, collaborate, and solicit community feedback, I have yet to see anything from these discussions (which I also enjoy 😁) that signal to me with any confidence that the efforts here will be competitive -- and therefore profitable -- when compared with the likes of Flutter (which btw is also gearing for PWAs).

Diagram control is essential in any data driven modern desktop experience in soon to be official NET CORE 3 (Sept 2019) and eventually. NET 5 (Nov 2020)
I see the provided Networkview open source control as an effective use case on how to work with Xaml to port WPF to Win UI control. This ported Win UI will serve as a good guild for others to port other slightly more complex WPF controls to Win UI.
We see 2 in 1 use case where our app need to support the tablet mode in future Windows Core OS. We suspect Winform in. NET Core 3 will not help.. another strong justification why Win UI diagram control is NOT just an exercise of PoC BUT should be part of win ui core controls in similar FIRST class as Grid control moving Forwards..

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Seems @migueldeicaza is taking matters into his own hands: https://github.com/microsoft/microsoft-ui-xaml/pull/736

I want to echo @eklipse2k8 's thoughts on cross-platform. When making a cross-platform UI library you will always have to make compromises. WinUI should not compromise - it needs to be the modern replacement of Win32 UI (I don't want to be calling CreateWindowExW any more!) and it needs to be a showcase of what you can do on Windows. WinUI on macOS or Android would always deliver an experience which could never match the native experience. We write cross-platform applications, and we write native UI on each platform. That way the customers get the best experience on their choice of platform. If people want a cross platform solution, that's fine, they should look to another library for that purpose - perhaps one that wraps WinUI on the Windows platform.
And with regards to PWA, these do not represent the full use of the Windows UI system, recommending focusing on "single window applications" would immediately rule out any professional piece of software (except games). There are solutions already for PWA and cross-platform - we don't need another one.
Obligatory XKCD:
https://xkcd.com/927/

@MarkIngramUK  I think the talk of Cross Platform is more about being able to code to .NET and XAML for declaring UI - then to have that app run on Android, iOS, macOS, Linux?! - without having to change the code behind or abandon the XAML.
Now if there were XAML Renderers for these other platforms - how they interpret the XAML could be like Xamarin Forms, which hands over to native UI platforms - or just essentially draw to the graphics card buffer and draw the pixels on screen - maintaining most of the same controls styles.
WinUI 3.0 should remain a Windows focused project to unify the various APIs and ABIs with a modern XAML based UI platform.  But that doesn't mean Xamarin or individuals can't take the rendering code and make versions for other platforms.
All that would be needed really (at a high level of thinking) is to ensure the code that renders XAML to the screen in Windows is contained, so other renderers could step in for cross platform scenarios.
WinRT/UWP/XAML is going to need some refactoring to extricate them from the Windows 10 OS - so how that refactoring is done, to allow for future expansion, is something to keep in mind.  Whether cross platform becomes a reality or not.

@MarkIngramUK  I agree with @mdtauk
There should be no reason why we can't use xaml to describe UI components in other libraries including React.  If you look at a project like http://www.cshtml5.com , they use xaml that gets converted to html.
I also don't think anyone alludes to the fact that the end goal is for the UI to look the same on other platforms but what I personally want is something on the UI side that I can use to leverage my existing investment in eg UWP
The point is simply this.  If I make a proposal to a enterprise customer and present an awesome UWP app that is fantastic in all respects.  If that enterprise customer has 1 person that is using for example a MacBook Pro, then I immediately have a problem as the enterprise customer will rather take something that works everywhere (lowest denominator => website) than my "native app"
So accessibility is key. The fact that MS is still expecting us to make investments in "native apps" in 2019 without any roadmap to cross platform capability is crazy.
Any new project from a enterprise perspective is likely to follow the above logic for accessibility and therefor all new projects will be biased toward the web and all because there is no roadmap that includes cross platform capability on XAML/UWP
So then we fast forward 2-3 years from now , no new investment from companies into UWP/win32 and you are sitting with another "Silverlight" that nobody cares about.
MS can even tell me that XAML is deprecated tomorrow and the "new" UI library is for example React. As long as c# can be glued to this new library then I will cut my losses, dump XAML and embrace this new cross platform UI library.  At least my investment has durability and is accessible long term.

And with regards to PWA, these do not represent the full use of the Windows UI system

Fair enough, and I agree.  I suppose part of the confusion here is the namespacing to reflect Microsoft.* when really it sounds like it should still be Windows.* (or even Microsoft.Windows.*).

There are solutions already for PWA and cross-platform - we don't need another one.

Unfortunately, this is not the case for .NET development, which is part of the confusion and cross-platform angst around this announcement and subsequent discussion.

therefore maximizing market reach and potential revenues for application developers while reducing the necessary costs of building applications to do so.
Sometimes performance and UX details make big difference. Skype has maximized market reach using Electron framework at the cost of sacrificing performance and the result is the commercial disaster.

I don

Skype has maximized market reach using Electron framework at the cost of sacrificing performance and the result is the commercial disaster.

Don't think it's due to the performance. It's because of WhatsApp and other apps out there who won the game because they hit at the right timing.

Regarding cross-platform (xplat) solutions.
Xplat solutions are an abstraction over multiple native underlying systems. My understanding of WinUI is that it will be the native system for Windows.
If WinUI was to also be xplat, how would it incorporate things that are unique to Windows? Wouldn't that prevent it from doing new and innovative things? Or would that mean it's on Microsoft to port anything new or differentiating from Windows to other platforms too? What about things that couldn't be ported because the other underlying OS couldn't support them--should they not be added to Windows?
If you build something with native Windows technologies, it's reasonable to assume that Microsoft will support that for a period of time and provide a path forward to newer Windows based systems in the future. (Acknowledging SilverLight as an exception.) I don't think it's reasonable to assume that if you build something with native Windows technologies and then want to run it on a competing operating system then it's up to Microsoft/Windows to make that easy. If you built an app for the iPad with Swift and wanted to also bring that to the Windows desktop, would you expect Apple to change iOS development to make that easy?
If you enjoy or prefer using native Windows technologies that's great. What you can't do is defer the business decision you make in choosing those technologies to someone else. All technology choices have consequences and no-one knows what might be required a few years in the future or what your customers might ask for. Asking for software developed specifically for Windows to also be able to run elsewhere can give the impression that the aim is to avoid making a technology decision that could have possible negative consequences at any point in the future. Based on the nature of technology and the speed of change I don't feel that's realistic.
That said, if you want to build an xplat solution (and there are lots of people who do & reasons for that) because you either want to target multiple operating systems now, or may want to in the future, then that's a reasonable and understandable scenario.
For that Microsoft have Xamarin. Or, if you'd prefer something with XAML more like UWP, there's Uno. (There's lots of other options too.)
If, like me, you want to see Xamarin have better native support for building Windows apps, I don't think having WinUI try and do mulitple things is the answer.
WinUI is about more than just XAML and specific controls. It includes details of how those controls and the apps that are built with them integrate with the underlying operating system.
If WinUI planning focuses on making Windows development on Windows the best it can be then that's a good case for having innovation and good future support. It's also likely to increase the chances people will want to continue using Windows and therefore it becomes important that it has solid support from multiple xplat solutions.

Regarding cross-platform (xplat) solutions.
Xplat solutions are an abstraction over multiple native underlying systems. My understanding of WinUI is that it will be the native system for Windows.

Sorry but I don't feel that way...
Look at Flutter... It has a core engine that can render anything on any platform it supports.
On top of that, it has components that are fully implemented on Dart using the engine managed layer and that represents (draw/render) in pixel fidelity the platform and design language you want to use for example, Material.io and Apple's Cupertino.
So, that IMHO, that would be the best approach to make something cross platform and that at same time represents the underlying platform capabilities.

I don't think it's reasonable to assume that if you build something with native Windows technologies and then want to run it on a competing operating system then it's up to Microsoft/Windows to make that easy

Right... I think the point here that others are making is that this seems a bit backward/tone-deaf these days, especially in the context of starting a new application.  Why would someone build a native Windows application when that only reaches a small % of the market?  This is not a good use of capital.
If it's to maintain legacy Windows applications or to specifically make a Windows application, then yes I am in agreement with all of this and it makes sense.  However, since there appear to be breaking changes and further investments involved, the value proposition of doing this vs. using Flutter has yet to be explained.

If you build something with native Windows technologies, it's reasonable to assume that Microsoft will support that for a period of time and provide a path forward to newer Windows based systems in the future.

No. Essential UI coverage for building enterprise LoB apps would be just fine.

For that Microsoft have Xamarin. Or, if you'd prefer something with XAML more like UWP, there's Uno.

Uno isn't officially recognized by MS. Like Google offers Flutter to its devs, MS should provide an xplat UI framework or standard. I don't necessarily need it to be WinUI, but there should be a ".NET UI Standard", that when implemented by any framework, should provide the essential building block of UI and is rendered by the implementing platform.

That is precisely what I'm saying...
For example, the flutter embedders for Desktop on both Win10 (WPF and UWP) as well as OSX are coming.
They are 100% managed by flutter runtime, but they are only using (for example) WPF/UWP to get the windowing management and Graphics pointer. All the rest is managed by the engine...
We've ported flutter engine ourselves to an embedded ARM device and I have to say it was an awesome experience. Why? Because it born to be portable and to run anywhere by letting the "embedder" to deal with platform specific implementation details on primitives like GPU, Software rendering, Input management, etc...
That is why I'm saying that WinUI by means of UWP: The empire strikes back is not going to work long term.
MSFT must come with something cross-platform, open, and portable. Just like they did with .Net Core, with Blazor, etc... Reinvent UWP/XAML will not going anywhere.
I believe XAML has a good potential if used properly in a sense where it is used to "describe" (or declare like some say) the UI. The "engine" build the render tree from it, and then dispatch the render commands to the underlying platform.
Like MSFT recently did with Chromium as the core for Edge, I believe WinUI (or whatever the name it became) could leverage Skia as it has backends for GL, DX, Vulkan, Software Rendering, FB, etc... Just by starting with that you have a HUGE potential of adding other platforms later...

@galvesribeiro ,

Look at Flutter... It has a core engine that can render anything on any platform it supports.
On top of that, it has components that are fully implemented on Dart using the engine managed layer and that represents (draw/render) in pixel fidelity the platform and design language you want to use for example, Material.io and Apple's Cupertino.

Great, so as soon as Apple release an update to macOS, and the UI updates (perhaps button corner radius changes, or background gradients change, etc) your Flutter application doesn't update and continues to look like the previous OS - unlike a native control which would get the benefits for free.

@MarkIngramUK that is the work on the team to support updates.
Just like Xamarin team provide updates from day 0+1, this team could do the same. Google team does that as well...
By using the "native" control, you are back again on Xamarin world were you only do, wrappers (aka Renders)...
We're not discussing C# bindings to native controls (Like Xamarin does)... We are talking about a full UI  framework like you do with Flutter...

@MarkIngramUK

our Flutter application doesn't update and continues to look like the previous OS

If we wanted 'native look and feel' we would have used Xamarin.Forms.
What we need is a platform agnostic UI rendering engine, that can potentially tweaked and themed to have native look and feel. The top requirement is to develop once and ship same UI everywhere, native look and feel doesn't matter to us at all, we don't want that. We want all OSs to render it the same.

For the record, nobody uses the "default" theme for any platform. They all create their unique UX on top of the design languages of each platform.
If you are so concerned about having alway look as the native component, your app probably will never have good audience as they would look... Meh...

I believe we're talking about two different projects here. WinUI needs to be the Win32 replacement. People are asking for a cross-platform solution, which is reasonable, but I don't think it should be this project.

Also, Flutter allow you to use the "theme" on all platforms. So you can run Cupertino on your Win10 PC.  A BIG example is Material design. It is a design language, not a set of controls. It can be used anywhere... It just happens that some platforms (like Android) has its native controls implementing it...

@MarkIngramUK
I'm just clarifying why WinUI should not be just a Win32 replacement, thats all.
If that is the case, then I'm pretty sure it will fall in a foreseeable future just like UWP...

I agree @MarkIngramUK  WinUI itself should be focused on providing a unified UI for Windows, no matter whether you use C#, WinRT APIs, Win32 ABIs, C++, F#, VB, .NET Core.
WinUI 3.0 involves lifting all that code and rendering of XAML out of the Windows OS, and making it a framework, independent from the OS update cycle, and making it open sourced.
How it is lifted and repackaged is still up in the air.  Only those internal to Microsoft know how they will do it.  In order to support future cross platform support for XAML, I only hope some thought is put into how it could be achieved in the future, as they are extricating it from Windows.

@jesbis @terrajobst @jevansaks
People need your urgent input.
What is Microsoft's plans in bring a UI framework into .NET Core that renders everywhere .NET Core runs?
A no is also an answer. The uncertainty going on for so many years is killing us. If we no .NET has no intention we can at least KNOW and shift priorities (such as using Flutter when we need an xplat UI solution). There wasn't a word about that @ Build.

@weitzhandler, they already have a roadmap, with the following paragraph:

A native Windows target for web and cross-platform frameworks
WinUI 3 is better optimized for libraries and frameworks to build on.
For example, we're planning to base the new high-performance C++ React Native Windows implementation on WinUI 3.

Ok then...
/me keep working on FluSharp

which is reasonable, but I don't think it should be this project.

It's thirsty out there @MarkIngramUK, pardon our projections. 😅

with the following paragraph

Doesn't say much. It doesn't reveal MS' clear intention for making C# and .NET development xplat. It maybe says that HTML JS & CSS shi{ are better equipment for you than C# if you want to be portable.

with the following paragraph

Doesn't say much. It doesn't reveal MS' clear intention for making C# and .NET development xplat. It maybe says that HTML JS & CSS shi{ are better equipment for you than C# if you want to be portable.

At the moment, Xamarin and Xamarin Forms is Microsoft's story for C# and .NET Core development outside of Windows.
React Native for Windows is coming for Javascript code and Native UI (which will use WinUI 3.0 XAML)
At the moment Microsoft has no plans announced for bringing WinUI 3.0's XAML to other platforms.
WinUI the project is trying to unify the Win32, WPF, MFC, UWP, .NET Core dev frameworks, under a single modern XAML presentation framework.
I think after that, work should go into finding ways to render XAML written for WinUI 3.0 - on platforms like macOS, iOS, Android, etc - but that is not on the agenda so far.
Once WinUI 3.0 work starts on here, it will be open source, so that makes future cross platform work possible for the future, if there is enough need for it.  And it may not be Microsoft who eventually make these cross platform paths available, it could be the open source community.

Any plans on making F#, C#'s redheaded stepchild a first class citizen?  And then people wonder why the vast majority of .NET developers won't touch F# with a ten-foot pole.

At the moment, Xamarin and Xamarin Forms is Microsoft's story for C# and .NET Core development outside of Windows.

Yes, Xamarin.Forms is being ported to macOS, GTK, UWP and WPF, plus having material design everywhere in the works, which makes it the de facto .NET UI Framework, but it is so slow and buggy I wonder what Microsoft is thinking about its developers. Just look at the issue list! Once serious development started, bugs are hit left and right. I hope with WinUI we can finally have a better development experience.
Re: F#

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Yes, it's always F# that get separately tracked and ignored again. Just look at UWP and .NET Native - both didn't have F# in mind and the community at large had to figure everything out. 🙄 After 4 years, F# still is unsupported on .NET Native.

For F# suggestions/questions I created a dedicated issue:
https://github.com/microsoft/microsoft-ui-xaml/issues/740
Please feel free to direct F# discussions there.
We're definitely not ignoring the feedback on it - having a dedicated issue just helps us organize and track it.
The team is discussing how it could fit into the roadmap for 3.0 and beyond and will update the new issue with any developments.

RE: cross-platform UI:
Thanks everyone for the points raised so far, and for the passion about .NET and Xaml.
I just want to say again that we're listening closely to all the feedback, and we'll share our thoughts and updates as we progress.
Just to reaffirm the current roadmap and some points that have come up:
WinUI is the native UI platform for Windows (including native apps, not just .NET) and for the initial 3.0 version we're primarily focused on making it independent of the OS and working toward getting it ready for open source development on a faster release cycle. We want to make sure the scope is feasible enough for us to get a preview out this year.
One of our other current short-term goals is to enable WinUI to serve as a native target for other platforms to use on Windows: for example we're also working on ensuring react-native-windows - a high performance C++ React Native implementation for Windows - uses WinUI, and that WinUI controls can be used to create native UI views in React Native apps.

I'll be perfectly honest. I have a native Windows desktop app I wrote in 2006 on WinForms that I'm still selling online today.
I have no plans to migrate this app to WPF, UWP, or use any exclusive windows UI technology. I don't care how compelling the Windows demos look. If I ever decide to work on this app again, the next major version will be some kind of cross-platform implementation that can run on MacOS, Linux, and Windows.
Currently, that would probably look like Blazor + .NET Core + Electron.
I think @Mike-EEE makes some great points. The UX/platform that allows me to leverage my C# skills to reach the greatest number of audience is the more likely technology I'll be picking.
Microsoft should focus on empowering developers to leverage their existing skills to reach a greater audience with their apps. I think that's a winning strategy and will keep Microsoft in the game.
The writing on the wall is that Operating System software is becoming more like a commodity. That being, people can pick any OS they want and get the apps they want to use. I think this will become more apparent as time moves forward as the world's software vendors continue to focus on cross-platform.

In economics, a commodity is an economic good or service that has full or substantial fungibility: that is, the market treats instances of the good as equivalent or nearly so with no regard to who produced them. https://en.wikipedia.org/wiki/Commodity

Microsoft has to decide, does it want to be part of the developer tooling story? Or does Microsoft invest millions of dollars into a new Windows-only UX stack that will just end up joining the graveyard of UX stacks that fewer and fewer people use?

This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.

It's a tough position to be in for sure. But times have changed. The world today is very different than the world that was in 1995. The way I see it, there's a couple of options:
You could hire more people to expand that knowledge beyond Windows.
Or, use that team's knowledge to build UX plumbing inside Windows that enhances compatibility for cross-platform UI application frameworks to run better on Windows.
Just like WSL did for running Linux on Windows.

Use the team's knowledge to make GTK run 200x faster.
Use the team's knowledge to make QT apps run 200x faster.
Use the team's knowledge to make Electron apps render faster than any other OS.

There's a lot of work that can be done to enhance the Windows cross-platform UX compatibility story. But investing in a whole new UX stack and hope that we all switch (without any cross-platform features) is a pretty big bet. Ya'll gotta break this habit creating new UX frameworks only for Windows.
Just my two cents. :moneybag:
:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (Official Movie) ft. Billy Ray Cyrus

@bchavez

Ya'll gotta break this habit creating new UX frameworks only for Windows.

-- Not only that. Even the habit of breaking Windows own internal XAML portability. WPF, Siliverlight, UWP all on their own fork... This kind of thing is pushing more and more people away from Windows dev tools in general which I personally would like to keep using in the future. The more push back from Windows dev tools means the less and less C# is relevant and for me its what I care about when I get down to it.

RE: cross-platform UI:
... WinUI is the native UI platform for Windows (including native apps, not just .NET) and for the initial 3.0 version we're primarily focused on making it independent of the OS and working toward getting it ready for open source development on a faster release cycle. We want to make sure the scope is feasible enough for us to get a preview out this year.

Add a +1 for the idea of updating the visual look for WinForms, MFC, WPF controls running with WinUI 3.0 to better match the Fluent/FabricWeb control styles.
Sure different control sizes (anything not WinRT XAML should probably match their metrics to the Compact version of the UWP controls) but one coherent and consistent polished look.
Add a WinUI 3.0 dependency into WinForms and the controls change.
WinUI 3.0 WPF apps detect and use Fluent.Light.xaml or Fluent.Dark.xaml control Themes.

I just installed Flutter on my PC, let's start experimenting.

@weitzhandler I understand your sentiment. I hope to never have to touch javaScript, and similars to do this cross-platform GUI. I dislike even thinking about starting a project using electron, angular, dart, flutter.
I hope we can have a solution soon with .NET 5, that will bring the Universal XAML dream. Microsoft XAML can WIN, Web, Mobile, Desktop and IoT.
Silverlight almost did it, for many use cases.

@TonyHenrique You're right. But years go by. There was just another Build that brought 0 news about the xplat UI field.
And per the conversation here and the feedback from the people here it looks like xplat UI ain't coming to C# and .NET anytime soon. They only show love for Electron and JS or whatever refugee languages that controls the market, while 💩ing on the native citizens' heads.
It's some sort of masochism that they keep on doing over and over.

Ya'll gotta break this habit creating new UX frameworks only for Windows.

WinUI 3.0 will never get released if we've got to wait for (an inevitably compromised on all platforms) cross-platform support. WinUI should be the lowest level UI framework on Windows, and if you want cross-platform ability, build on top of that (or use React Native, Xamarin, etc).

Ya'll gotta break this habit creating new UX frameworks only for Windows.

I'd just like to clarify that we aren't trying to create a new UI framework with WinUI 3.0.
Our initial goal is to:

remove barriers to using the existing modern native technologies (Windows 10 Xaml UI and compositor) by decoupling them from the OS and enabling them to work across existing app models (win32 and UWP), languages, other frameworks (via islands), and Windows versions

update our engineering process to be open source

@mdtauk, @MarkIngramUK etc.
Ya'll are right, this is not the right place to ask for xplat UI. No place is, cuz doesn't look like anyone at MS is listening anyway, @Mike-EEE's Ubiquitous .NET has been the top rated issue since ages ago. No progress.  I've been close to giving up so many times. Maybe it's about time.

WinUI 3.0 will never get released if we've got to wait for (an inevitably compromised on all platforms) cross-platform support.

Man... If you really believe on that, you mean that successful frameworks like Flutter doesn't work...
I don't like Dart either, but they DO released a pretty descent product which is evolving and getting tracking REALLY fast.
I'm frustrated that WinUI will become only a Windows things...
.Net needs a UI framework that match the awesomeness of .Net Core cross platform capabilities just like we just got for Web with Blazor (client and server-side).
I think for now, we still have to rely on community-driven efforts.
I understand what your team is trying todo @jesbis... It is just that many of us are tired of seeing UI on .Net/C++/UWP/MFC/Windows a silo'ed thing that only run on Windows while all the world (ofc except Apple and OSX) are going the opposite way offering developers better and better cross platform solutions. Like you mentioned the React and Rect-Native (for the record I don't like either, just mentioning they are evolving).
So what we have now is just community driven initiatives like Avalonia or even Uno and other frameworks (like FluSharp that I'm working as mentioned) that evolve very for obvious reasons...
My suggestion is that rather than just lift the XAML and compositor out of Windows codebase and make it a Windows-only, to get it and make proper abstractions so it could work on multiple platforms. Just like we had with .Net Core, which was initially Windows-only but that community driven efforts made it work pretty fast on Linux, OSX and even on ARM devices...

(an inevitably compromised on all platforms) cross-platform support

I really don't think this will be a problem, given that cross-platform design is, and has always been, a key aspect of UWP's XAML UI, and Fluent Design. There are definitely some controls where the visual design is different between Windows versions - this is handled seamlessly, you get native UI that matches the device's OS.
For example, Acrylic and Reveal built into controls, accent colours on Pivots and NavigationViews - these things don't appear on the Creator's Update, but do on FCU and newer. Zero changes required.
Obviously there is a lot more complexity behind-the-scenes to rendering the UI on an entirely different OS, but in terms of actually designing the UI, I don't think there's any new considerations that need to be taken, than there ever was with UWP and WinUI.
I think the big concern is what the long-term plans truly are. Based on responses from @jesbis it seems like they're only focusing on the short-term right now, and long-term plans are still open for discussion.
That much is understandable, the scope of such a project is huge. I could absolutely understand if it wasn't the short-term plan, but rather the endgame plan. Transparency is important here, it's clear that no one wants to support a platform without a clear future.
It's clear that MS as a whole is focused on cross-platform - we see this with Fluent Design (which now has examples for iOS, Android, and web), a large number of MS-made apps on other platforms - so shared UI is really just a big missing link. And that is why it would be so disappointing to not see it happen - I think a lot of people like the idea of a MS-made universal app platform, but it doesn't make sense to support, if we don't have a complete solution for it.

The point is... As with material.io and Cupertino, we could (and I'm not surprised if Google isn't already doing that!) have the "theme" on flutter for fluent design language...
And that is my point when I said that a truly cross-plat UI framework would not care about that and would just work, like Flutter does... I don't see where we have compromises on that...

.Net needs a UI framework that match the awesomeness of .Net Core cross platform capabilities just like we just got for Web with Blazor (client and server-side).

If I'm to choose between Blazor and Flutter I go with Flutter, because I hate HTML and CSS with passion. It's either XAML or another pure .NET-oriented language (i.e. UI annotation with C#, like in Dart), or it's not for me.

@weitzhandler I don't like HTML for native apps either. Otherwise I would be using Electron with React 😄
I'm just not being passional here, and just being rational instead.

I'm just not being passional here

😂 I've been like that since the death of Silverlight.
Let's wait a little more and see if we get an official response or update on MS steps. Google surprised big time latest IO, Microsoft didn't.

I am really looking forward for the WinUI 3.0 and I would use it immediately for a new C++/WinRT Windows desktop project. And I hope that the next major version after 3.0 will introduce a portable runtime for hosting the WinUI applications (like the Flutter runtime). For a significant number of LOB application and Photoshop like application, the GUI can be the same on each platform, but the key is the performance. And I also think that the xlang project is a great idea and promises some good news in a future.

I suggest users here take time to listen to Scott Hunter after BUILD 2019 on how Win UI, Xamarin Form, UNO, Web Assembly could come together.
.NET Core 3 and Beyond with Scott<EMAIL_ADDRESS>Rock
Both Xamarin Forms (XAML) and UNO (XAML) were created with the vision for cross platform. In the case of UNO (n addition to iOS, Android, XAML for Web through Web Assembly).
UWP was created with no vision of beyond Microsoft ecosystem e.g Web, Android, iOS. All the impressive Fluent design effort has little take up due to slow adoption of UWP
As @Mike-EE pointed out, droid  and iOS have 2~ and 1.5~ billions while Win10 has 0.9 billions. Most of which developers are still reluctant to jump from WinForm and WPF to UWP.
WHY? The UWP controls, from commercial and Microsoft, are INCOMPLETE!!!!!  compared to those in WinForm and WPF. There is no effort by Microsoft to help that transition. XAML Island will not address this AS LONG AS MICROSOFT has BLIND SPOT as what are missing that developers NEEDS to transition to UWP from winForm and WPF.
With these missing UWP Controls, now significant effort is putting on bringing Win UI to React Native for Web. ??????  We need these missing Win UI Controls for UWP so we could lobby for transition from WinForm and WPF to UWP.
One such control is Diagram Control. All data intensive business app needs diagram control by Microsoft for UWP.
==> I understand the need to decouple UWP UI.  This only makes sense to spread Fluent Design branding to other platforms e.g. iOS, Android, Web.
==> Please focus on delivering better 3D model control and Diagram Controls (both 2D/3D)
It only makes sense to staying and wait for NET5 when ALL BCL from (mono is merged with the native of Windows, for Web Assembly etc ) , because I SEE THE FUTURE OF HOLOLENS creative 3D UI.
For that we need 2d/3D Diagram Control for UWP and 3D model control that is not just merely displaying model but not allowing developer to access the skeletal/vertex animation.
Please put more people into these USP (unique selling points) of Win UI for UWP.

@weitzhandler
This issue was created to discuss the WinUI 3.0 Roadmap.
@jesbis made a clarifying statement:

WinUI is the native UI platform for Windows (including native apps, not just .NET) and for the initial 3.0 version we're primarily focused on making it independent of the OS and working toward getting it ready for open source development on a faster release cycle. We want to make sure the scope is feasible enough for us to get a preview out this year.

Your first two comments were on-topic.
The following six were a combination of non-productive and derogatory, and you are close to breaking the Microsoft Open Source Code of Conduct.
This should remain a productive, professional conversation with Microsoft.
// I'm not following this conversation to listen to some guy vent all day.

@kmgallahan
You're right.
Gonna delete them all.

I think there's some great comments here, although it seems there might be two seperate discussions. I'll keep it short because most of it has been said before.
Cross platform & web
.NET Core is great. We can finally target every platform and touchpoint with great tooling and an awesome language.
 For max comparability it would be great to have a framework that allows desktop devs to migrate to web and beyond with the same skills, tooling and language (Xaml and C#). Tbh, Silverlight did a great thing there - it just worked). I'm not sure if WinUI needs to be that framework, but please raise the issue internally. Basically Flutter for .NET devs, and targetting web would be the biggest advantage.
Not sure if Xamarin could be that platform, but if so - make sure the Xaml is aligned as much as possible across WinUI and Xamarin.
WinUI
This needs to happen. There should be one common Xaml stack to create the best experiences possible on the Windows platform. Ideally the missing gaps from WPF in terms of controls and functionality should be filled.
HoloLens and beyond
With Lite coming up, and new super exciting form factors such as HoloLens  one could argue that UWP is not ready for it in terms of UI. Yes, we can run them on a HoloLens which is nice, but I'd like to see a way to really optimize apps for 3D without going full Unity.

WinUI is way ahead Xamarin. But Microsoft Team just push Xamarin 4.0 out...
I am personally like Xamarin more as it is lowest denomination for Cross Platform, there gonna rising number of Native Apps for SaaS in future.
Other than Xamarin, there is some alternative.

Why not embrace UNO platform and make the web rendering using SkiaSharp?
@zezba9000 You need an agnostic rendering backend like game engines use to start with. Actually I kinda acknowledge it....

Maybe Microsoft push WinUI more, because there is non open source code trace inside unlike other cross platform solution: Xamarin, UNO, might have UNIX libraries...
Anyway, may the force be with you.

@jkoritzinsky , One thing the WinUI team should watch out for with the WinUI 3.0 rename: If you rename any of the types that are projected in .NET, then the projections won't work (and we aren't planning on adding any more since it's not a maintainable extensible system). Here's a list of the types that we project: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h
Any changes to different types than these types will require users to wrap their objects in new objects that implement the new interfaces or copy their data into the new types. In particular, the INotifyPropertyChanged and INotifyCollectionChanged types are of interest with respect to XAML Islands and providing downstream support.

I agree and I'm glad you brought up this issue, although I'd like to add that I think these projections are a bit of a unfortunate evil. We don't project every single API that probably should be (thinking about the System.IO APIs), so we should either remedy that, or think differently. One thing that comes to mind is to not add types that are similar, but different, to .NET types in a different namespace. Instead, we should enable our C++ developers to also use System.ComponentModel.INotifyDataErrorInfo. This is sort of what we did with C++/CLI, but this wouldn't require loading the CLR for a pure C++ application.  I don't know if that would be more confusing, but it feels like we're leaking the fundamental and underlying differences in the .NET and WinRT technologies at the API layer, which makes things feel incoherent.

@meir-pletinsky. NET is only one framework you can use to make apps with UWP XAML. They want text field validation available for Devs, no matter what framework they use

This is right on the money, we do have C++ developers that we care about. Although like I mentioned above, I would love us to not cause confusion in the .NET community just to make this happen.

@mdtauk , no, WinUI Desktop (previously Xaml Desktop) allows you to use Xaml with Win32 directly, without the use of the island.

I think @meir-pletinsky was referring to .NET/C++, unless I'm missing something?

@MarkIngramUK  I believe we're talking about two different projects here. WinUI needs to be the Win32 replacement. People are asking for a cross-platform solution, which is reasonable, but I don't think it should be this project.

Yes, I totally agree! To me, WinUI is about defining the most modern, performant, just all around best UI for Windows. Xamarin should be the cross-platform story from Microsoft and should evolve to be on top of WinUI.

@mdtauk Add a +1 for the idea of updating the visual look for WinForms, MFC, WPF controls running with WinUI 3.0 to better match the Fluent/FabricWeb control styles.
Sure different control sizes (anything not WinRT XAML should probably match their metrics to the Compact version of the UWP controls) but one coherent and consistent polished look.
Add a WinUI 3.0 dependency into WinForms and the controls change.
WinUI 3.0 WPF apps detect and use Fluent.Light.xaml or Fluent.Dark.xaml control Themes.

I don't really want to see MS investing time and resources into those frameworks to make them look like native Windows 10. That's why there will be WinUI 3.0. You want Windows 10 look & feel in WPF/WinForms apps? Use WinUI 3.0.
MS should much rather invest their resources into closing existing (and blocking) gaps between UWP/WinUI and their Win32 counterparts, than re-visit their older frameworks. Especially given that WinUI 3.0 is meant to become the presentation framework for Windows...

I'd like to ask for clarification on WinUI and Microsoft's intentions on UI/UX:

Does WinUI replace ALL of the following (hypothetically?): Win32, ATL, MFC, WinForms, Silverlight (I know), WPF, UWP and/or XAML Islands? I recognize that these technologies will continue to exist, and will continue to be supported for some indefinite amount of time; I just want to clearly understand that this is what Microsoft is saying is "the way forward", and that (for example), we should consider WinForms and WPF the same as we consider Win32 or MFC.

Does WinUI derive from UWP? (Or, how similar are the two?) How similar (or different) is WinUI as compared to UWP, XAML Islands, or WPF?

As a professional C# and C++ developer, I started working with WinForms, and then moved to WPF, and then moved back to WinForms simply because I could design UI/UX for business purposes in WinForms roughly twice as fast as I could in WPF. WPF gave much more flexibility, performance, and looked much better—but the XAML mangling that occurred as soon as someone touched the interface via the Designer instead of hand-editing the XAML was awful. In some cases, I think WinForms (using the Designer) was orders of magnitude faster than hand-constructing a XAML form or control that was similar.
Personally, I would love a UI that's available and identical across Microsoft's products. A framework that can be leveraged by Win32 or .NET in a similar fashion would mean consistent, modern looking applications for ALL Microsoft developers, and would also mean that common questions and problems can be solved in sessions that target a single technology—for example, when asking a question about a control, the answer would be identical (if not nearly identical) for a Win32 developer OR a .NET developer. That would make learning "WinUI" useful for either stack for any given developer, and would also make access to information online (StackOverflow, etc.) much more valuable, regardless of where you're developing. Although I don't use Xamarin, if Xamarin could be made to follow in these footsteps (as an extension of WinUI?), then the above statement could be applied not only to Windows developers, but also those targeting Android, iOS, etc.
What kind of applications would I be excited to use WinUI for?