search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.34k stars 675 forks source link

Discussion: WinUI 3 Strategy for Existing Developers & Apps #3639

Closed robloo closed 1 year ago

robloo commented 3 years ago

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 & Discussions

robloo commented 3 years ago

image

robloo commented 3 years ago

No comments from Microsoft and I'm watching these concerns play out in real-time. It does appear to be progressing the same as UWP at this point and several of the same mistakes are being repeated (along with a repeat of most of the promises).

I'm directing my company to plan migration to Avalonia UI and start the initial ground-work. If there is no change in course by the end of the year WinUI and the UWP app model (and by extension Uno) will likely be dropped entirely. Avalonia has it's own set of missing features and rough edges but it's better positioned as the UI stack that should have been the follow-up to WPF. It also has far fewer "gotchas" and bugs in practice and is more-or-less production ready now.

HppZ commented 3 years ago

NEED UWP .NET 5 SUPPORT!

sherman89 commented 3 years ago

Is there any practical difference between a WinUI 3 desktop project, and a WPF project that uses XAML Islands for WinUI controls?

I'm planning to start developing a desktop-only application (maybe tablet support in a few years) and I want to have that modern Windows 10 look, but I feel like choosing WPF will be safer for now as it's mature and stable.

I hope the upgrade path then to pure WinUI from WPF will be smooth...

Thanks! I also appreciate the work being put into WinUI 3, I'm quite excited about it!

robloo commented 3 years ago

Microsoft Confirmed UWP support is NOT going to be in WinUI 3.0 version 1.0 release AND they confirmed there are no plans to take UWP out of experimental. This essentially closes this issue as Microsoft won't support UWP with WinUI3 going forward. They are badly hurting UWP developers/companies here but obviously there aren't enough of us for it to matter from a financial standpoint. Does reputation mean nothing anymore?

https://youtu.be/9EOKxjFyY68?t=3055

UWP is now so far out to pasture I can't see it. Everyone is strongly encouraged to move on to other frameworks. UWP will likely never get .NET 6 support at this point although the project reunion team hasn't explicitly said no to .NET 6 yet (they said no to .NET 5). I wait to see what the plan is for XBox/HoloLens apps.

I recommend everyone actually start considering other UI frameworks than those provided by Microsoft. It is still possible to build a WinUI3 app with the classic Win32 app model (like WPF) and .NET6; however cross-platform XAML is already here. Microsoft has now burned every company that chose to follow them one way or another (first with WPF, then with Silverlight, now with UWP). It is no longer prudent to invest in Microsoft's UI frameworks and expect them to be supported for more than a few years.

Here is a comparison of the framework options we have right now: https://github.com/robloo/PublicDocs/blob/master/XAMLFrameworkComparison.md

Is there any practical difference between a WinUI 3 desktop project, and a WPF project that uses XAML Islands for WinUI controls?

None that I'm aware of. Keep in mind however that XAML islands isn't working yet for consuming WinUI 3 controls in WPF and there is no time commitment on when that will be added (if it happens in 2022 I'll be a little surprised).

robloo commented 3 years ago

@mdtauk

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

"The future plans could get canceled at any time." https://github.com/microsoft/microsoft-ui-xaml/issues/3639#issuecomment-731623812

Update: Those future plans were cancelled yesterday.

mdtauk commented 3 years ago

@mdtauk

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

"The future plans could get canceled at any time." https://github.com/microsoft/microsoft-ui-xaml/issues/3639#issuecomment-731623812

Update: Those future plans were cancelled yesterday.

Indeed it does seem that way. UWP is now a road that leads to a dead end at a certain point.

Let's see what plans may emerge post WinUI 3. At some point Microsoft will want to remove UWP stuff from Xbox or future Windows version, so they will need to decide what to do with UWP apps, and whether the sandbox should be extended to allow Win32 apps to opt in

pjmlp commented 3 years ago

@mdtauk They already did, although the WinUI team kind of missed it on the community call. Apparently they don't talk with each other.

The XBox Game Developers SDK, recently made available, as means to let everyone use the same tools as AAA studios, clearly deprecates the WinRT based tooling for anyone moving forward.

Reading between the lines, UWP on XBox has been placed on the same road as XNA, Win32 + GDK is the new path.

https://github.com/microsoft/GDK

mdtauk commented 3 years ago

@mdtauk They already did, although the WinUI team kind of missed it on the community call. Apparently they don't talk with each other.

The XBox Game Developers SDK, recently made available, as means to let everyone use the same tools as AAA studios, clearly deprecates the WinRT based tooling for anyone moving forward.

Reading between the lines, UWP on XBox has been placed on the same road as XNA, Win32 + GDK is the new path.

https://github.com/microsoft/GDK

The GDK it's probably overkill for someone building an app. Game development is an entirely different ball game.

shaheedmalik commented 3 years ago

It means UWP is DoA.

image

jtorjo commented 3 years ago

UWP is now so far out to pasture I can't see it. Everyone is strongly encouraged to move on to other frameworks.

I really really hope Microsoft finishes porting win2d to WinUI Desktop. At that point, I'll be the first to port to WinUI Desktop, and forget the UWP/WinRT nightmare ever existed.

pjmlp commented 3 years ago

@jtorjo Unfortunately the bare bones C++/WinRT tooling and C++ only nature of some APIs make that nightmare very hard to forget.

I have been advising anyone considering doing C++ based GUIs on Windows to keep using MFC, or just jump ship into either Qt or C++ Builder.

jtorjo commented 3 years ago

@pjmlp Yeah, it's really sad. And I'm using C#, so there's really no solution for me when it comes to what UI to use.

sherman89 commented 3 years ago

At that point, I'll be the first to port to WinUI Desktop, and forget the UWP/WinRT nightmare ever existed.

Isn't WinUI still natively using WinRT though? So that's not going anywhere?

I'd love to use WinUI for our new projects but we're stuck with .NET 4.8 due to third party dependencies 🙁

sjb-sjb commented 3 years ago

Well… I started out using UWP for a business app that I expected to run on desktops. I made the switch to WinUI3+desktop and it was a bit painful primarily because of the deficient app lifecycle and because at the time I didn’t see how to use the app center and store. However a little browsing now tells me that the store and app center will now both support desktop apps. So what is missing for me really is the app lifecycle and sandboxing, which I would say are “nice to haves” rather than mandatory from a dev point of view. Of course my life is simplified by the fact that I am not trying to develop for xbox and desktop at the same time.

I do feel the process has been really tough on all us (current and former) UWP devs who were not given a clear way forward.

MS should start making roadmaps for developer communities instead of for technologies.

robloo commented 3 years ago

Some new reading. The fact that they are pushing migration to WinUI3 away from UWP while the list of missing features is so long is disappointing. This list also does not capture a lot of the nuances, and more critically, bugs that prevent migration to WinUI3. It's even more disappointing Microsoft never engaged in the discussion here -- their strategy for sunsetting tech is always the same though as discussed before.

https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/overall-migration-strategy https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/what-is-supported

image

groovykool commented 2 years ago

Performance considerations Today in version 1.0 of Windows App SDK, launch speeds, RAM usage, and installation size of WinUI 3 apps are larger/slower than seen in UWP. We are actively working to improve this. We will have more information to share in the future.

Noemata commented 2 years ago

Winforms (2 steps forward) -> WPF (3 steps forward) -> Silverlight (2 steps back) -> UWP on Win8 (1 step forward, 1/2 step back) -> Xamarin (3 steps sideways) -> UWP on Win10 (2 steps forward) -> WinUI (1 step forward, 3 steps back)

Microsoft's published roadmaps regarding WinUI have turned into an odd form of fiction.

Bottom line, WPF, UWP and Xamarin are still your best choices. WinUI may eventually catch up to where UWP is today. It's more likely it will be deprecated before that happens given recent history with Microsoft technologies.

And for those Microsoft staffers that might remark we should be more positive and supportive ... please say Silveright three times in a row and accept that:

“No matter how dreary and gray our homes are, we people of flesh and blood would rather live there than in any other country, be it ever so beautiful. There is no place like home.”

― L. Frank Baum, The Wonderful Wizard of Oz

Welcome home Microsoft.

llothar commented 2 years ago

Some new reading. The fact that they are pushing migration to WinUI3 away from UWP while the list of missing features is so long is disappointing. This list also does not capture a lot of the nuances, and more critically, bugs that prevent migration to WinUI3. It's even more disappointing Microsoft never engaged in the discussion here -- their strategy for sunsetting tech is always the same though as discussed before.

Yes it is very disappointing. By the way you forgot to mention it's also much slower and memory hungry. I don't think 16GB will not be enough anymore for a windows computer.

Unfortunately macOS is in the same condition. The terrible new state of modern agile development with fixed tight marketing driven timelines. The Win11 debacle with Ryzan CPUs shows its everywhere. May God (pick your favorite) help us that neither Apple nor Microsoft ever enter the world of medical devices.

llothar commented 2 years ago

Winforms (2 steps forward) -> WPF (3 steps forward) -> Silverlight (2 steps back) -> UWP on Win8 (1 step forward, 1/2 step back) -> Xamarin (3 steps sideways) -> UWP on Win10 (2 steps forward) -> WinUI (1 step forward, 3 steps back)

Microsoft's published roadmaps regarding WinUI have turned into an odd form of fiction.

Win32 API -> MFC -> WinUI3 is so much less change. You just picked the wrong language, finally i can say this once as a C++ programmer 😂

Noemata commented 2 years ago

@llothar , I did my fair share of Win32/MFC work. The sense of control and stability is derived from the fact that you had to do virtually everything yourself. Meta level work is supposed to be better.

dylech30th commented 2 years ago

@llothar I believe that the separated development experience between UWP and Win32 had been one of the most criticized issues in Windows development, so from my perspective, the migration is really a step forward. I do believe that you can do everything that of WinUI capabilities in Win32/MFC, but the problem is not what you can do. Things like the event system and the UI design and the overall management of the app are absent in the traditional Win32/MFC development and they are pretty vital to the modernization of the app. So unless you'd like to implement them by yourself, I think the best option is to embrace modernization.

mdtauk commented 2 years ago

image

There should be a focus on closing this gap ASAP, before pushing forward. The UWP door is closing, and the hurt will persist for as long as WinAppSDK doesn't cover EVERY aspect of UWP that enticed those developers to begin with.

Privacy, Permissions, and Trust of the installation is going to be the biggest loss with WinAppSDK as it is now. Mobile platforms are doing well as both Google and Apple are chasing privacy and security. Permissions is where UWP did well from its core, and unless WinAppSDK implements that "gatekeeping" into its core, we will be stuck with Win32's security risks, and that will affect users going forward.

Also Xbox...

Xbox development will be stuck with PWAs and full on games engines - without a clean API and UI platform to design to.

dylech30th commented 2 years ago

@llothar I believe that the separated development experience between UWP and Win32 had been one of the most criticized issues in Windows development, so from my perspective, the migration is really a step forward. I do believe that you can do everything that of WinUI capabilities in Win32/MFC, but the problem is not what you can do. Things like the event system and the UI design and the overall management of the app are absent in the traditional Win32/MFC development and they are pretty vital to the modernization of the app. So unless you'd like to implement them by yourself, I think the best option is to embrace modernization.

That being said, I do agree that the lacking of functionalities in WinUI should be fixed ASAP, It seems that Microsoft wants to get rid of UWP so urgently, but as its replacement, the current WinUI 3 can hardly be recognized as a production-ready framework

llothar commented 2 years ago

Privacy, Permissions, and Trust of the installation is going to be the biggest loss with WinAppSDK as it is now. Mobile platforms are doing well as both Google and Apple are chasing privacy and security. Permissions is where UWP did well from its core, and unless WinAppSDK implements that "gatekeeping" into its core, we will be stuck with Win32's security risks, and that will affect users going forward.

All this security risks are very important features for other people. The serious restrictions of UWP are terrible and one of the main failures. You can't create a productive business environment with it. It's also why macOS and iOS are still maintained differently even when they have the same hardware now. I'm sorry but i really would love to even get my OLE2 back so i could show a office document directly in my App again. I fear this times are over but not for the benefit of the user.

Security can be well done on administration level and when you don't have a business model that lives on users installing as many apps as possible and make 30% of it.

I would love to see that we have more security virtual machines under a single Desktop GUI, so you can run your professional apps in one and games in the other and for new trial software a run once testing vm. But please never ever again force us into this tight restrictions and individual App separation we have on Android, iOS and UWP.

jtorjo commented 2 years ago

he serious restrictions of UWP are terrible and one of the main failures.

@llothar Halleluia 😁I don't have a problem with implementing restrictions, but they way they're implemented in WinRT is simply beyond words. In sweet MS fashion, no one asked us what we'd like, they just pushed it on us, nobody liked it, but they kept pushing and saying it's the "right" way.

Every bad thing related to UWP/WinRT stems from this point -- the restrictions/file system. And to see how bad they are, just look at how long it's taking MS to port them away...

pjmlp commented 2 years ago

Win32 API -> MFC -> WinUI3 is so much less change. You just picked the wrong language, finally i can say this once as a C++ programmer 😂

@llothar Only If you happen to enjoy doing ATL/WRL without any kind of VS support, just like back in 2000.

It is incredible how after four years C++/WinRT is still a shadow of C++/CX tooling, and nowhere as productive than MFC ever was.

santhoshk commented 1 year ago

Some new reading. The fact that they are pushing migration to WinUI3 away from UWP while the list of missing features is so long is disappointing. This list also does not capture a lot of the nuances, and more critically, bugs that prevent migration to WinUI3. It's even more disappointing Microsoft never engaged in the discussion here -- their strategy for sunsetting tech is always the same though as discussed before.

https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/overall-migration-strategy https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/what-is-supported

image

@robloo - I know it has been 1.5 years since this update. But just wanted to check if at this point you aware of any tooling support for WPF to WinUI3 migration? Or is it largely a manual process? I tried upgrade-assistant, but it doesn't seem to work for WPF. It is documented here that upgrade-assistant would work for UWP apps though.

We have a huge WPF (MVVM) code base where we use lots of standard WPF controls as well as many custom-built controls for which we have the source code, but also use several 3rd party controls (e.g Infragistics). We would like to upgrade to WinUI3, however the lack of tooling seems like this will be a lot of work and not sure if we get stuck anywhere in the middle due to some functionality not being available in WinUI3, that will be a bummer!

pjmlp commented 1 year ago

@santhoshk Plenty of stuff is still missing, MAUI team had to ship a webwidget maps control, because UWP one isn't there, no designer, Native AOT doesn't do GUI code, C++/WinRT is at the level of ATL/WRL, some APIs like widgets are C++ only for now, and so on.

Just keep that WPF application going, and port as much as you can into GUI independent libraries.

Possibly check Avalonia or Uno as possible migrations.

robloo commented 1 year ago

@santhoshk As stated, most all of that list is still a missing feature in WinUI 3. The WinUI team seems to be getting smaller as well and project Reunion was deprioritized it seems after being well over a year late. Bottom line Microsoft is doing again what they always do with their XAML UI frameworks. I would caution strongly against porting without doing a deep-dive analysis and WPF is still a pretty good option.

On my end the UWP code is in maintenance mode and apps are being moved to Avalonia. The situation with Microsoft XAML UI frameworks just isn't a good business case anymore.

Concerning tools to migrate -- there absolutely is no automatic migration tool from WPF to UWP/WinUI3. You are going to have a nasty time with it on a large code base as well. That is something we all went through going form WPF -> UWP years ago. Recommend taking a look at a doc of differences I put together: https://github.com/robloo/PublicDocs/blob/master/UWPvsWPF.md. UWP, generally speaking, has even more features than WinUI3 though so it's going to be harder.

My recommendation is to stay on WPF unless there is a real technical reason you need to modernize. Then I would take a long look at Avalonia instead (migration from WPF to Avalonia is generally smoother than WPF to UWP/WinUI3 as well).

robloo commented 1 year ago

Commenting to keep this open because Microsoft strategy is still quite poor due to missing features.

aliajboy commented 1 year ago

Commenting to support this issue. hope Microsoft fix this soon and guide us in migration journey. It's really hard to migrate from wpf to winui as a lot of things have changed.