Microsoft-ui-xaml: Discussion: WinUI 3 Strategy for Existing Developers & Apps

[robloo]

Discussion: WinUI 3 Strategy for Existing Developers & Apps

WinUI 3 is a great idea. Decoupling from the OS solves a lot of problems to fix issues without compatibility concerns, ensure apps can ship with the framework they test with, and new features are available earlier - all great. Open sourcing is another huge win as well. However, this great vision is shaping up to be something less. WinUI 3 seems to be making one of the same strategy mistakes as UWP: alienating existing developers and providing a poor migration path for the last version of the tech (UWP).

WinUI 3 right now makes the most sense for developers writing new applications. Existing developers whether they be C#/C++ (F#/VB totally out of luck) or UWP/WPF will face some serious hurdles going forward. So far Microsoft is not directly addressing these hurdles. Concerns are always acknowledged but solutions seem 1-2 years away for many topics. These issues need to be brought to the forefront with Microsoft management and the strategy discussed and then clearly communicated. Otherwise, for both Microsoft and Developers, we are in for a bumpy road ahead.

Some of the hurdles we have with WinUI 3 today are below.

1. Existing developers using UWP are bound to hit a roadblock with WinUI 3 or even 3.1. WinUI is still not feature complete compared to UWP. Personally, without a solution for MapControl there isn't much I can do. There are several of these gotcha's already.
2. Microsoft is pushing WinUI 3 as the future for desktop app development and encourages WPF apps to transition. Existing WPF developers are going to encounter a lot of the same missing features the rest of us discovered 4-5 years ago when UWP first came onto the scene. A lot of effort needs to be made to close the XAML feature gap between WinUI and WPF now to make the transition smoother. There are some changes that are pretty significant on the app-side but are no-brainers to add to the framework (https://github.com/robloo/PublicDocs/blob/master/UWPvsWPF.md). In fairness Microsoft has made several improvements since UWP was first released and the WCT covers some missing features as well but there is more to be done.
3. UWP developers cannot use .NET 5 and C# 9. F# and VB have been dropped completely. Honestly, there is no excuse from Microsoft that is acceptable for UWP not supporting the latest tech. If Microsoft is willing to let UWP stagnate for years what confidence do we have in the next latest-and-greatest WinUI?
4. Existing C++/CX developers are being forced to move to C++/WinRT. However, I've read in multiple comments that C++WinRT is like development from 20 years ago with IDLs, manually copying files and no tooling support for these formats (even the WinUI library itself looks like old code). On top of that, C++/WinRT isn't at feature parity with C++/CX but is being forced to be adopted right now.
5. WinUI is going to introduce several newer bugs. This is unavoidable considering the amount of code being changed and the architecture differences pulling it out of the OS. However, Microsoft is leaving bug-fixing up to the community for the most part. What is Microsoft's commitment to address open bugs? There needs to be a 6 month stability period worked into the timeline but that isn't possible considering all the remaining missing features.
6. Features such as data validation once promised for WinUI 3 (and one of the key features driving it's need) have been pushed back indefinitely. The roadmap now just mentions "Post-3.0". Open sourcing now seems like it might be 1 year away as well. These timing slips are very difficult to work around for smaller companies.

Overall, the big changes Microsoft is taking on are encouraging to see. I know WinUI 3 and Project Reunion are also intended to bring everyone together and really support mix/match of components. However, Microsoft probably bit off more than they can chew again and I don't know when or if that vision will be met. It's more likely that the vision will never be truly realized and instead we are again left with a partially-completed development stack. To mitigate those risks we need a solution for existing developers and apps that allow a clean transition.

Microsoft needs to:

1. Provide a clear migration path for existing XAML tech (UWP then WPF) by WinUI 3.1 - no exceptions. This should be number 1 priority and is tied to feature parity.
2. Do the impossible and provide a clear schedule with deadlines but also meet those timing commitments.
3. Commit to WinUI for the next 10+ years. I want to be sure the next management turnover within Microsoft isn't going to chase the next best idea and continue the story of fragmentation leaving a trail of partially implemented good ideas.

If Microsoft doesn't address these issues I know companies, including my own, are going to seriously reconsider Microsoft tech overall. We can't keep repeating the same mistakes every few years. UWP is basically the final straw and better tech exists like ASP.NET/Blazor and React Native.

Related Links

• .NET 5 with UWP https://github.com/microsoft/ProjectReunion/issues/105
• WinUI 3.0 Developer Experience and Tooling https://github.com/microsoft/microsoft-ui-xaml/issues/1045

[jtorjo]

Agree 100%! Thanks for taking the time to write this up! I really hope Microsoft considers this, and give us a clear roadmap and strategy for us to go forward with WinUI 3.

[sukesh-ak]

Thank you for the write-up @robloo
Since we have gone through many iterations of half-hearted approach earlier from UI/UX perspective this "Commit to WinUI for the next 10+ years." becomes even more important.

I need mapcontrol and inkcanvas. Both missing without any timeline.
Works on Windows 10X is also pushed without timeline. Does that mean ARM64 is also gone?

[duke7553]

Edit: Read my comment below about why I think Microsoft doesn't necessarily need to do this

An important use-case of WinUI that the team should facilitate before general availability is moving a project from UWP -> Desktop. For instance, what if an organization started out by investing in UWP for the latest XAML UI experience, but now that this is ubiquitous with WinUI WinUI desktop and even Project Reunion, can they easily move their desktop investments from UWP to WinUI Desktop? For example: before WinUI existed, I imagine developers chose UWP because they mistakenly anticipated the addition of APIs for better integration with the Windows Shell. Developers recently learned that the goal isn't to replicate every last Win32 API in WinRT, but they may need some of those APIs for their desktop-specific project. A WinUI Desktop project is ideal for deep desktop integration like this. Guidance should be published for this area.

[groovykool]

This roadmap Clearly shows what the priorities are. Apparently the near future(2-3 Years) is Win32 with a subset of UWP/WinUI 2.X called WinUI 3. And in the far future(3 -5 years) maybe we get .Net 5 on UWP and eventually they add more of the WinUI 2.X features to WinUI 3.X. It looks like they HATE MapControl!!!

Does this strategy make sense? Are developers clamoring for a subset of WinUI 2.X on Win32? I don't see a clear path from UWP to Win32/WinUI 3.X for several years.

[robloo]

Yes, I think we are all aware of the roadmap. You're absolutely right that its quite problematic from a UWP standpoint.

Thinking about this some more, I guess it only makes sense if you are coming over from old C++ frameworks like MFC. Being overly optimistic, maybe Microsoft is internally making WinUI 3 to first modernize Windows shell and apps themselves with XAML tech. In that context things would make some sense. However, I kind-of doubt Microsoft is doing that much internally even with Windows 10X.

[pjmlp]

Apparently the near future(2-3 Years) is Win32 with a subset of UWP/WinUI 2.X called WinUI 3. And in the far future(3 -5 years) maybe we get .Net 5 on UWP and eventually they add more of the WinUI 2.X features to WinUI 3.X. It looks like they HATE MapControl!!!

Which is exactly why betting on classical WPF and Win32 seems the more sane thing to do, unless Microsoft really adresses these issues.

So far we have only gotten promises that things will get better, and I don't know why Windows 10X even keeps poping up, there is no device available with it, the Win32 sandbox was dropped from the design and eventually not even the hardware itself is going to happen (the MSDN related pages were removed).

We just need to check the ongoing increase of Reunion issues to see how many years it will take, if it ever makes it.

Also the unwilligness to address issues like not exposing COM libraries as UWP components, and then forcing us to use C++/WinRT instead of C++/CX to write our own bindings, was the final drop.

[sukesh-ak]

Apparently the near future(2-3 Years) is Win32 with a subset of UWP/WinUI 2.X called WinUI 3. And in the far future(3 -5 years) maybe we get .Net 5 on UWP and eventually they add more of the WinUI 2.X features to WinUI 3.X. It looks like they HATE MapControl!!!

Which is exactly why betting on classical WPF and Win32 seems the more sane thing to do, unless Microsoft really adresses these issues.

Will it work on all Windows powered platform? I guess the answer is NO. Which is the start of another set of issues for future.

[robloo]

A WPF/.net5 solution should actually run on all windows platforms -- arm included -- except for XBOX and maybe Hololens. That's a very reasonable tradeoff for the vast majority of apps. WPF is also known to work on macOS and Linux with some not impossible or impractical techniques. I tend to agree that I wish I stayed with WPF with a plan to move to WinUI in a year or so. However, the commitment in time and money was done years ago to move to UWP expecting that it was the future and new functionality would only be added there.

[sukesh-ak]

A WPF/.net5 solution should actually run on all windows platforms -- arm included -- except for XBOX and maybe Hololens. That's a very reasonable tradeoff for the vast majority of apps. WPF is also known to work on macOS and Linux with some not impossible or impractical techniques. I tend to agree that I wish I stayed with WPF with a plan to move to WinUI in a year or so. However, the commitment in time and money was done years ago to move to UWP expecting that it was the future and new functionality would only be added there.

Then what is the use of WinUI 3 Desktop App?

The compatibility you are talking about is here
https://docs.microsoft.com/en-us/dotnet/core/compatibility/wpf

Quoting from the above link

Reason for change

It's assumed that most users don't want a console window to open when a WPF or Windows Forms app is executed. In addition, now that these application types use the .NET SDK instead of the Windows Desktop SDK, the correct default will be set. Further, when support for targeting iOS and Android is added, it will be easier to multi-target between multiple platforms if they all use the same output type.

[robloo]

Then what is the use of WinUI 3 Desktop App?

There are still many reasons to update. For example,, Wpf was never designed for touch screens or mobile-sized devices and their input methods. Wpf doesnt have latest controls especially for Webview and the like. Uwp also has far better performance in some scenarios.

when support for targeting iOS and Android is added

I think that's bad wording. WPF is likely never getting cross platform support from Microsoft. They've been very clear on that. However, the community has got it working. They are talking about .net6 I think Which won't include a UI layer except for Maui (which is terribly inferior).

Here is what I was talking about for cross-platform WPF. A lot of recent developments were made after WPF was open sourced. https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

[ecovio1]

Then what is the use of WinUI 3 Desktop App?

There will be absolutely no reason for WinUI3 Desktop app for not being able to run on other windows powered platforms once AppContainer sandbox comes to win32 apps, win32 apps medium IL processes will need to be brokered with the system with the help of runtime broker so that it works for the AppContainer sanbox apps. AppContainer solves privacy+security issues. UWP's App LifeCycle is coming to win32 apps , x86 apps are no longer hog battery juice when it is compiled for ARM64 on arm64 devices..

Sorry, I see no reason to update a _Desktop-Only_ app when it just works for current users, and and similarly see no reason to develop a windows app if it doesn't work on every windows powered platfoms. WinRT API are so buggy and I don't have any trust in UWP. Win32 apps going universal will be ideal in 2020 both for Windows's future relevancy and for Microsoft. so that existing windows apps can update and opt into other windows powered platforms easily like UWP.

[mdtauk]

Then what is the use of WinUI 3 Desktop App?

There will be absolutely no reason for WinUI3 Desktop app for not being able to run on other windows powered platforms once AppContainer sandbox comes to win32 apps, win32 apps medium IL processes will need to be brokered with the system with the help of runtime broker so that it works for the AppContainer sanbox apps. AppContainer solves privacy+security issues. UWP's App LifeCycle is coming to win32 apps , x86 apps are no longer hog battery juice when it is compiled for ARM64 on arm64 devices..

Sorry, I see no reason to update a _Desktop-Only_ app when it just works for current users, and and similarly see no reason to develop a windows app if it doesn't work on every windows powered platfoms. WinRT API are so buggy and I don't have any trust in UWP. Win32 apps going universal will be ideal in 2020 both for Windows's future relevancy and for Microsoft. so that existing windows apps can update and opt into other windows powered platforms easily like UWP.

WinUI 3 will bring you modern UI that will scale nicely for high DPIs, as well as those controls updating outside of OS updates. Project Reunion will bring modern APIs and wrappers around older APIs. Plus both of these will be open sourced.

As legacy Windows versions are left behind, future investment and feature work will target Reunion and WinUI.

[robloo]

As legacy Windows versions are left behind, future investment and feature work will target Reunion and WinUI.

That was the UWP promise yet here we are. One of my main points was a lack of confidence in Microsofts ability to follow through with WinUI no matter how good the intentions are.

[mdtauk]

As legacy Windows versions are left behind, future investment and feature work will target Reunion and WinUI.

That was the UWP promise yet here we are. One of my main points was a lack of confidence in Microsofts ability to follow through with WinUI no matter how good the intentions are.

Many devs continue to nurture their Win32 codebases, and didn't or couldn't move to UWP and Sandboxed App lifecycles. So Microsoft is using Reunion to allow Win32 apps to access modern APIs, so they don't get left behind. And WinUI is bringing XAML UI out of the UWP sandbox, for existing Win32 apps to adopt and use.

[robloo]

@mdtauk Of course I'm well aware of that. From a UWP standpoint we are in a very poor position though. There havnt been updates in years and now I can't easily move to WinUI 3 either. Microsoft is now catering more to those win32 devs than those that followed microsofts recommendations a few years ago.

[ecovio1]

Many devs continue to nurture their Win32 codebases, and didn't or couldn't move to UWP and Sandboxed App lifecycles. So Microsoft is using Reunion to allow Win32 apps to access modern APIs, so they don't get left behind. And WinUI is bringing XAML UI out of the UWP sandbox, for existing Win32 apps to adopt and use.

there is a reason why almost most of the win32 windows developers refuse to update. _updating a desktop app to run it again on the same platform for the same userbase will kill the reasons to update in the first place. when most of the windows desktop users still do operate with the keyboard and mouse._ for me this won't worth the time to update. this is subjective but I'm being practical here and feeling the sense of most of the developers.

if I exclude win32 apps, the relevancy of windows for general consumers is non-existence. every single new and non-trivial apps are win32 and will continue to be win32. I may say that most general consumers don't use windows because it's windows but because of win32 apps and games. for newer windows platorms MS will have to leverage the win32 apps here to make windows stay relevant. so once win32 apps and users are there , newer apps will start to come.

_combining, appContainer for win32 apps, msix and winUI3, what's stopping MS to let all these existing win32 apps to run on other windows powered platforms where it makes sense?_ [yeah I know .net native will need to be replaced with .NET 5/6 on Xbox/Hololens but MS can do that with updates to corresponding platforms]

here comes the enough reasons for developers to update their desktop apps if they run other windows powered platforms :

1. if I already have a desktop app, I won't have to rewrite it from scratch rather I can easily update the app with reunion and make my app available on platforms where it makes sense.
2. I'm not limited to my current platform userbase and my userbase grows when it runs on other windows powered platforms.
3. I'll also have the possibility to go web with webassembly.

to put it mildly, honestly I do want winRT-only UWP to die, make win32-winRT-winUI the new UWP.
I may sound rude but I've tried to be honest and practical here.

[sukesh-ak]

After reading tons of github discussions on UI/UX plans, it looks like the safest bet is to use ASP.NET or web technologies.

Doesn't look like Microsoft will be ready with an answer/timeline to "what is the right UI/UX platform for new application with future support" question anytime soon.

All the current changes are to make existing apps and app deveopers stay on Windows after UWP (Phone) disaster.

[mdtauk]

@mdtauk Of course I'm well aware of that. From a UWP standpoint we are in a very poor position though. There havnt been updates in years and now I can't easily move to WinUI 3 either. Microsoft is now catering more to those win32 devs than those that followed microsofts recommendations a few years ago.

WinUI 3 at launch wont offer much different for UWP lifecycle apps, beyond more controls, which you can get through WinUI 2.X

It is Win32 apps which have been left behind (whether actually or in mindset) since WinRT in Windows 8) Even parts of the Shell have moved to Xaml.

So bringing them up to date for now, keeping UWP going in the short term - then with Reunion, merging both Win32 and WinRT - with a choice of lifecycle, or possibly even more finegrained usage of UWP lifecycle features.

And of course the UWP lifecycle is still the focus for non Desktop SKUs of Windows. (Xbox, etc)

[mdtauk]

After reading tons of github discussions on UI/UX plans, it looks like the safest bet is to use ASP.NET or web technologies.

Doesn't look like Microsoft will be ready with an answer/timeline to "what is the right UI/UX platform for new application with future support" question anytime soon.

All the current changes are to make existing apps and app deveopers stay on Windows after UWP (Phone) disaster.

If you use Web Technologies, there will be React with FluentUI or React Native which uses WinUI

[sukesh-ak]

If you use Web Technologies, there will be React with FluentUI or React Native which uses WinUI

No stuff from Microsoft with web technologies other than vanilla ASP.NET

Will have to wait and see where this WinUI stuff will go by 2025. Got burnt multiple times already from Silverlight / WPF / UWP.

[sukesh-ak]

Easiest future would have been MAUI (with all required features) with UWP backed by WinUI for Windows, to target multiple platforms.

But looking at the repo there, it looks like just an upgraded Xamarin Forms app with.NET 5/6 and no info/update on UWP story.

[duke7553]

I think what @ecovio1 is saying makes sense because the idea that developers building native apps today want a simple, streamlined API surface is an outdated one. Logically, if they expend their time and effort to develop specifically for the Windows platform, they would want access to all the tried and tested Win32 APIs regardless of OS expression. This means that most of the Win32 API needs to work on Windows 10X and HoloLens. Native app developers want to invest make one investment for the Windows platform rather than several.

Believe it or not, the best path forward here is Microsoft expanding, improving, and stabilizing the WinRT API. Being an enhanced version of COM under the hood, this app model is the best way to guarantee that developers investments in any supported language will work across every OS SKU.

I think Microsoft's current stance is consistent with this. They are planning to lift out parts of WinRT and work more openly with developers when we propose new APIs for the platform. At the same time, they want to help us modernize our existing investments gradually. This does NOT mean Win32 is the future of native development on Windows. It doesn't make sense for them to facilitate more companies investing in that aging platform. And after giving it some thought, that's why it's likely not the best idea to follow through with https://github.com/microsoft/microsoft-ui-xaml/issues/3639#issuecomment-729832485

I'd like to see more of a commitment from the team in adding APIs to WinRT which fill gaps, but if you have ideas to address pain points, the Project Reunion repo is the best place to propose them.

[ecovio1]

And of course the UWP lifecycle is still the focus for non Desktop SKUs of Windows. (Xbox, etc)

microsoft have never publicly announced the killings of anything until that technology had become obsolete enough-already dead for most of the general consumers/developers eg: Kin phones, silverlight, windows phones. but the negligence from microsoft has always pretty much signaled what to expect in future. for example- microsoft's negligence for windows itself since 2018 have always signaled that windows itself is their side project now and everybody knows that already. never wait for official confirmations for microsoft product this is what I've learned.

[duke7553]

Easiest future would have been MAUI (with all required features) with UWP backed by WinUI for Windows, to target multiple platforms.

But looking at the repo there, it looks like just an upgraded Xamarin Forms app with.NET 5/6 and no info/update on UWP story.

@sukesh-ak If you want to write apps which target non-Windows platforms as well, there are many excellent choices, but this issue isn't a WinUI hate discussion. We're discussing how Microsoft can make investing in modern Windows apps more feasible to developers.

[sukesh-ak]

@sukesh-ak If you want to write apps which target non-Windows platforms as well, there are many excellent choices, but this issue isn't a WinUI hate discussion. We're discussing how Microsoft can make investing in modern Windows apps more feasible to developers.

I am at a stage of decision making to build a great experience of my application on Windows (not just desktop) which needs future support. I intend to use Map control and ink as part of the experience.

Do you know which UI/UX platform should I pick? Of course in 2020 I expect to use part of this investment to be re-usable on other platforms as well (code reuse).

[mdtauk]

WPF is open source, and will continue working on Windows for years to come. Want to use it, you can.
WinForms is open source, and will continue working on Windows for years to come. Want to use it, you can.

Both of these will work back to Windows 7 for a while, and be able to use Reunion APIs which bring up to date versions of old Win32 APIs, and will enable access to WinRT and Win32 apps. It may also allow new features back to Windows 8.

---

Native Xaml with UWP, will continue working in Windows, and will get WinUI 2.X releases to add new controls and features.

WinUI 3 will support UWP apps and Win32 apps, with a UI framework that will get new features as time goes on, backporting to older but still supported versions of Windows 10/10X

---

React Native will allow apps that are cross platform, with the Windows versions running on top of WinUI 3.X

Electron/Chromium Edge apps can also be made and Microsoft is investing heavy in Edge and Chromium improvements.

[mdtauk]

@sukesh-ak If you want to write apps which target non-Windows platforms as well, there are many excellent choices, but this issue isn't a WinUI hate discussion. We're discussing how Microsoft can make investing in modern Windows apps more feasible to developers.

I am at a stage of decision making to build a great experience of my application on Windows (not just desktop) which needs future support. I intend to use Map control and ink as part of the experience.

Do you know which UI/UX platform should I pick? Of course in 2020 I expect to use part of this investment to be re-usable on other platforms as well (code reuse).

Map Control will not be available in WinUI 3.X for a while, so as long as you don't need low level File Access, UWP will continue to work, and WinUI 2.X will give you new controls that get added. When Map Control is supported, it should be fairly simple to move over to WinUI 3.X

[sukesh-ak]

Map Control will not be available in WinUI 3.X for a while, so as long as you don't need low level File Access, UWP will continue to work, and WinUI 2.X will give you new controls that get added. When Map Control is supported, it should be fairly simple to move over to WinUI 3.X

Just to add more info, I started using Azure Maps which doesn't have a native control because map control uses Bing API. So switched to browser control for maps, then hit the bug where you can't have any control above browser control. It's been a while going through the different issues already.

I don't need system level access and file access works in UWP with an entire new set of API's.

[mdtauk]

Map Control will not be available in WinUI 3.X for a while, so as long as you don't need low level File Access, UWP will continue to work, and WinUI 2.X will give you new controls that get added. When Map Control is supported, it should be fairly simple to move over to WinUI 3.X

Just to add more info, I started using Azure Maps which doesn't have a native control because map control uses Bing API. So switched to browser control for maps, then hit the bug where you can't have any control above browser control. It's been a while going through the different issues already.

I don't need system level access and file access works in UWP with an entire new set of API's.

You may want to test out WinUI 3 and the WebView2 web control, which is based on Chromium Edge

[sukesh-ak]

Map Control will not be available in WinUI 3.X for a while, so as long as you don't need low level File Access, UWP will continue to work, and WinUI 2.X will give you new controls that get added. When Map Control is supported, it should be fairly simple to move over to WinUI 3.X

Just to add more info, I started using Azure Maps which doesn't have a native control because map control uses Bing API. So switched to browser control for maps, then hit the bug where you can't have any control above browser control. It's been a while going through the different issues already.
I don't need system level access and file access works in UWP with an entire new set of API's.

You may want to test out WinUI 3 and the WebView2 web control, which is based on Chromium Edge

As per the previous github issue I opened, New Edge doesn't change this. But cefsharp supports it but I prefer to stick to MS component.

I have paused the development waiting for release of WinUI3 and a 3rd party component I need with that.

[ecovio1]

Believe it or not, the best path forward here is Microsoft expanding, improving, and stabilizing the WinRT API. Being an enhanced version of COM under the hood, this app model is the best way to guarantee that developers investments in any supported language will work across every OS SKU.
I'd like to see more of a commitment from the team in adding APIs to WinRT which fill gaps, but if you have ideas to address pain points, the Project Reunion repo is the best place to propose them.

this is what I also expected it to be since 2015 that more and more win32 APIs will be wrapped in winRT form but it unfortunately it didn't happen after all these years. I've a serious doubt if that will ever going to happen after looking at all these project reunion uwp proposals, and microsoft's answers there and the PRs.

This does NOT mean Win32 is the future of native development on Windows. It doesn't make sense for them to facilitate more companies investing in that aging platform. And after giving it some thought, that's why it's likely not the best idea to follow through with #3639 (comment)

I read your edited comment, the thing is what is written is written , will never be rewritten from scratch with winRT just to run on other platforms rather it will be ideal to mix match both win32 and winRT.

_this is more about leveraging the existing apps which people love, uses for years._ by the time, once these existing apps are there, winRT APIs will be fully matured. _newer and future developments can switch to winRT-only developments_ , but for now ,existing apps has to be there for general consumers.
just my two cents :-)

[duke7553]

@ecovio1 I agree completely. Just wanted to address people's perception that Win32 API should be the default for all new native apps.

[robloo]

I don't mind if UWP dies as long as there is a clear migration path for those of us invested in it and access to current technology during the transistion -- which there isnt without struggles at this point. That said, UWP isn't going anywhere. Microsoft has been clear about that as well. I understand what Microsoft is doing now is good for Win32 and C++ devs overall. However, UWP and C# apps have been stagnating for years due to lack of tooling updates. Addressing the UWP aspects is what i originally hoped this discussion would focus on.

[mdtauk]

I don't mind if UWP dies as long as there is a clear migration path for those of us invested in it and access to current technology during the transistion -- which there isnt without struggles at this point. That said, UWP isn't going anywhere. Microsoft has been clear about that as well. I understand what Microsoft is doing now is good for Win32 and C++ devs overall. However, UWP and C# apps have been stagnating for years due to lack of tooling updates. Addressing the UWP aspects is what i originally hoped this discussion would focus on.

WinUI 3.X will support everything UWP can do in time. WinUI 3.0 is not Win32 API only, and work being done in Reunion and WinUI 3 - are for both UWP lifecycle and Win32.

So there should be one version of XAML, one set of controls, and one API surface area including Reunion - which both app lifecycles can use.

[robloo]

@mdtauk "in time" is what I'm worried about. 1-2 in software development is a long time. Microsoft stopped updating UWP tooling around 2 years ago. Now I'm being told I have 1-2 years left to wait. In that time software can become irrelevant so some serious decisions have to be made whether the UI should be completely rewritten in non-microsoft tech to stay relevant and competitive. I would appreciate if you would acknowledge the situation UWP is in right now instead of repeating that it will improve in the future. This is not the first time Microsoft has done something like this either. The future plans could get canceled at any time.

[mdtauk]

@mdtauk "in time" is what I'm worried about. 1-2 in software development is a long time. Microsoft stopped updating UWP tooling around 2 years ago. Now I'm being told I have 1-2 years left to wait. In that time software can become irrelevant so some serious decisions have to be made whether the UI should be completely rewritten in non-microsoft tech to stay relevant and competitive. I would appreciate if you would acknowledge the situation UWP is in right now instead of repeating that it will improve in the future. This is not the first time Microsoft has done something like this either. The future plans could get canceled at any time.

UWP continues to work whilst WinUI 3.0 is developed. And if you can move over to WinUI 3.0 (don't need HostBackdrop Acrylic or MapControl etc) once the Go Live version is out, then do so. WinUI 2.X will get new controls, and will still be developed after 3.0 is released.

[robloo]

@mdtauk You are missing the point entirely. UWP is still on a version of .net core 2, c# 7.3 and now I cannot move to WinUI 3 at launch and probably for 1-2 years. Unlike you, I am not speaking hypothetically. This is all coming up as a result of developing an app in the store now. It is a real situation you can't talk away with microsoft's marketing points. You also know I've been active here for a long time, I dont want to be critical of the WinUI team but I have to speak up at this point in the hopes of reprioritizing some things. The old tooling is now starting to influence features, development speed and compatibility with other software. I also won't get latest bug fixes or access to functionality like data validation for who knows how long. It is not a good situation and you must understand that.

[ecovio1]

I would appreciate if you would acknowledge the situation UWP is in right now instead of repeating that it will improve in the future. This is not the first time Microsoft has done something like this either. The future plans could get canceled at any time.

tired of win32 vs UWP saga, I want an Unified app model where people can use Win32 API who needs it , and who doesn't need it win32 API can use winRT API , all those APIs will operate from the same app Container ~ for security+privacy reasons, win32 apps/ APIs/medium IL processes will use Brokering for IPC with the system securely and this Unified app model runs across all the windows powered platforms .

and this is something I want , can happen if appContainer-win32 apps can go cross platform where it is already a mix of win32 API + winRT API. _nothing to lose here with this approach_ with a bonus that people can focus on the web also .

[mdtauk]

@mdtauk You are missing the point entirely. UWP is still on a version of .net core 2, c# 7.3 and now I cannot move to WinUI 3 at launch and probably for 1-2 years. Unlike you, I am not speaking hypothetically. This is all coming up as a result of developing an app in the store now. It is a real situation you can't talk away with microsoft's marketing points. You also know I've been active here for a long time, I dont want to be critical of the WinUI team but I have to speak up at this point in the hopes of reprioritizing some things. The old tooling is now starting to influence features, development speed and compatibility with other software. I also won't get latest bug fixes or access to functionality like data validation for who knows how long. It is not a good situation and you must understand that.

I'm not defending Microsoft, just relaying what their intentions are. I went through Avalon, Silverlight, Windows Phone, Windows 8, and then Windows 10 dev transitions.

I agree with you that it's constantly been two steps forward, one step back. And things promised years ago, still have not emerged.

The only plus point in all this, as that once open sourced, the community can get stuck in and releases won't have to match Windows's cadence.

It may be therapeutic for people to vent their frustration, but the plan is the plan, and all we can do is wait or pick a different path.

I've just been mentioning what does directions are

[robloo]

but the plan is the plan, and all we can do is wait or pick a different path.

The propose of this discussion is not to vent frustration. It is to raise the priority within Microsoft to address it. They have been hearing more and more about UWP struggles and are starting to acknowledge it more as well. It is an important for discussions like this to shine light on areas that are being overlooked. Microsoft is now very much driven by feedback, I'm providing feedback here.

[jtorjo]

And once again, MS seems to be dead silent about this...

[pjmlp]

Given that Surface Neo disappeared from all official Microsoft sites, and the only thing that Surface channels talk about is the Android based Surface Duo, I don't get what are all those remarks about Windows 10X.

Most likely it will never happen, or it will be yet another reboot like the several others we have been going through since Windows 8 was released.

[mdtauk]

Given that Surface Neo disappeared from all official Microsoft sites, and the only thing that Surface channels talk about is the Android based Surface Duo, I don't get what are all those remarks about Windows 10X.

Most likely it will never happen, or it will be yet another reboot like the several others we have been going through since Windows 8 was released.

Accelerating innovation in Windows 10 to meet customers where they are
With Windows 10X, we designed for flexibility, and that flexibility has enabled us to pivot our focus toward single-screen Windows 10X devices that leverage the power of the cloud to help our customers work, learn and play in new ways. These single-screen devices will be the first expression of Windows 10X that we deliver to our customers, and we will continue to look for the right moment, in conjunction with our OEM partners, to bring dual-screen devices to market.

3 months after Panos Panay took over development and direction for Windows

[sukesh-ak]

3 months after Panos Panay took over development and direction for Windows

Not sure what is the future of Windows 10X. Windows 10 IoT has not seen much work on it. Now I guess its being merged with Windows 10 IoT Enterprise. Large number of device manufacturers who were using Windows Embedded have moved to Android due to lack of easy migration path.

For my project a simple & cheaper device with Windows using UWP (10X?) would be ideal since my data is coming from Azure. Waiting for 2022 and beyond (post WinUI 3 GA) to get mapcontrol & inking using WinUI 3 is a show stopper, specially when timelines are not mentioned yet and unknown.

When you are working on a new product specially hardware + software, it takes approximately 3 years for everything to come together for launch. Without timelines for required components it becomes a major issue. You don't want to invest on something now (WinUI 2 + UWP + .NET Core) and before launch again spend resources to migrate to WinUI 3 (UWP + .NET 5/6 or whatever next). This does not make business sense specially for start-ups with limited resources.

[ecovio1]

feeling the frustration of existing developers, does this issue address yours questions? can you gentlemens chime in there to address your further questions? 🙂

if MS still avoids to respond there, I'm afraid I'll have nothing rather than to completely switch to Web/apple🙁

[robloo]

I'm afraid I'll have nothing rather than to completely switch to Web/apple

Note that Apple is far worse to develop for from a compatibility standpoint. Every few years a major transition occurs requiring expensive and time consuming updates. Apple forces these changes too. That said, Apple usually makes these changes for some good technical reasons which make them easier to stomach. The biggest difference with Apple though is when they set course it is set in stone. They will follow through.

[pjmlp]

@ecovio1 Check the issues being discussed at Project Reunion, and you will see how far they are from actually delivering what is being sold to us.