search

microsoft / microsoft-ui-xaml

WinUI: a modern UI framework with a rich set of controls and styles to build dynamic and high-performing Windows applications.
MIT License
6.38k stars 683 forks source link

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

Closed robloo closed 1 year ago

robloo commented 4 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

jtorjo commented 4 years ago

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 commented 4 years ago

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?

lukeblevins commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ghost commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ghost commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

ghost commented 4 years ago

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.

lukeblevins commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

ghost commented 4 years ago

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 :-)

robloo commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

ghost commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

pjmlp commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

ghost commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Noemata commented 3 years ago

@mdtauk , I don't think you realize how muddled and compromised the messaging has become. Use WPF, but only if you don't need x or y, use UWP but only if you have to, use Win32 and hope for the best. It's not a good message.

The promise of UWP was huge. It's extremely disappointing to see Microsoft back peddle on all those promises. You can't have it any way you want these days. UWP should have been the path forward in my view, and that coming from a dev that was very invested in WPF and found it painful trying to convince Microsoft that some WPF features like DataGrid were essential for UWP.

The bottom line, Microsoft does whatever it wants and doesn't really pay attention to customers when that doesn't align with internal objectives. Prove us wrong on that perception by keeping the very public promises made regarding UWP. The tech reboots aren't working. WinUI is months away from being viable. And I'm sure the resources being expending on WinUI are very much at the expense of moving UWP forward.

I don't see nearly as much consternation and plain bewilderment on Google or Apple dev forums.

Don't just double down on UWP, bet the farm on it. It will work out.

Noemata commented 3 years ago

The simplest solution of all would have been to provide an unboxed execution context for UWP, with it having full access to Win32. One way to author everything, and the Win32 folks can either choose to come on board the UWP train or stay where they are. I never did see a reason why WPF couldn't have been ported over to UWP.

Noemata commented 3 years ago

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.

Tragically, the timelines for this are so uncertain, that you have to wonder where everything will land. There was a pretty good rationale for UWP (secure and trusted sandbox execution model), automatic compatibility with multiple Windows platforms and CPU architectures, consistent UI, etc. ...

The implication is that WinUI throws all of that out the Windows window. That won't work out. A trusted execution context is more important than ever. As is the ability to easily deploy to different types of devices without having to worry about the UI or underlying architecture of the hardware. I get other devs responding to me on why UWP is relevant and the preferred forward looking posture. Not Microsoft. Microsoft staffers are very quiet on this little detail and have been for months.

llothar commented 3 years ago

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.

No it's so much easier. The big changes like the jump to Swift or SwiftUI or even Storyboards are purely optional. You still can use Objective-C as i do. For other parts the path was always incremental. Microsoft has the write it once and never touch it again strategy for backward compatibility. Why is desktop developing so heaven like on Apple? Why are the best Desktop apps now only happening on macOS? Because they improved for 20 years. I would love to have an API for PDF handling as perfect as PDFKit on windows.

sjb-sjb commented 3 years ago

Maybe MS needs to start thinking in terms of communities of developers and the way forward for each of them. No community should be built up as "the way forward' and then later told to stay on hold for a few years while everyone else advances. That is what has happened to the UWP community.