This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Discussion: WinUI 3 Strategy for Existing Developers & Apps #3639
Comments
ghost
added
the
|
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. |
|
Thank you for the write-up @robloo I need mapcontrol and inkcanvas. Both missing without any timeline. |
|
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. |
ranjeshj
added
product-winui3
|
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. |
|
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. |
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. |
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. |
|
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 Quoting from the above link Reason for changeIt'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. |
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.
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 |
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. |
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. |
|
@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. |
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 :
to put it mildly, honestly I do want winRT-only UWP to die, make win32-winRT-winUI the new UWP. |
|
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. |
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) |
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. |
|
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. |
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. |
@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). |
|
WPF 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. |
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 |
|
It means UWP is DoA.
|
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. |
|
@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. |
|
@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. |
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 🙁 |
|
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. |
|
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
|
|
Performance considerations |
|
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. |
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. |
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 , 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. |
|
@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. |
|
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. |
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 |
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. |
@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... |
@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. |
@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? 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! |
|
@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. |
|
@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). |
|
Commenting to keep this open because Microsoft strategy is still quite poor due to missing features. |
|
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
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:
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
The text was updated successfully, but these errors were encountered: