Discussion: Reasons for having a UWP and a Win32/.Net version of the same app

[benstevens48]

I recently watched parts of the recording of the latest community call, and there was a question about whether it's going to be easy to write a UWP and non-UWP (Win32/.Net) version of the same app. This seemed to slightly surprise the WinUI team member fielding the question, but it really shouldn't! I think it's important the team (and the wider UWP team) understands the shortcomings that still exist with both UWP and non-UWP app models. For example, here is my scenario.

I have a photo viewing UWP app which would greatly benefit from fast file system access (listing of files/folders), a proper file system watching API, and more flexible/less restrictive file permissions. All this is provided in Win32/.Net but not UWP. This means I'm seriously considering whether I can write a non-UWP version of the app. On the other hand, I like the trustworthiness of UWP apps and worry that I might lose some users by only having a non-UWP app, and also I deliver my app via the Store and am not sure what the rules are regarding submitting non-UWP apps.

Of course I don't really want to make two versions. I really wish Microsoft would invest more effort into solving the issues with file system permissions and file system performance. I would love to be involved in this discussion as I have lots of real-world examples of where the permissions restrictions and performance is holding back the capabilities of my app. Also, the very slow progress on this front over the years leaves me really unsure as to what the future of development for Windows is, because on the one hand if Microsoft were serious about the future of the UWP app model, surely they'd have made more progress by now, so maybe the strategy is to decouple WinUI and then expect people to write non-UWP apps, but on the other hand Windows 10X seems to imply that the UWP app model is the future. One thing that gives me hope is the squiggly line I've seen in some diagrams between the UWP and Win32 app models, meaning maybe they will become more unified. However, since these things involve permissions, they are unlikely to be able to implemented in NuGet packages, but will have to be Windows feature updates, so it would probably be a year before I could make use of them (since users would need the updated OS) even if they were released now. Hence I would really like to see some progress on this!

P.S. Others should feel free to add their reasons for for having a UWP and a Win32/.Net version of the same app.

[mdtauk]

I think it should still be possible to list the app in the store, but if it is a Win32/WinUI Desktop app, it will restrict which devices can run the app.

[shaheedmalik]

I have a photo viewing UWP app which would greatly benefit from fast file system access (listing of files/folders), a proper file system watching API, and more flexible/less restrictive file permissions. All this is provided in Win32/.Net but not UWP. This means I'm seriously considering whether I can write a non-UWP version of the app.

In Windows 10x, your program will still run in a container just like UWP apps.

[StephenLPeters]

@marb2000 for FYI :)

[Gavin-Williams]

UWP also isn't generally suited to game development on desktop - which is really a death warrant for the platform as games represent about 50% of all development on light platforms and probably a lot more on desktop. And I say that as someone working on a game that runs in UWP - I will abandon the platform as soon as .Net 5 is ready for DirectX output and we have a replacement for SharpDX. I'm totally sick of Microsoft not reacting to the platforms needs.

Reasons Win32 is still needed ..

1. Distribution on Steam, EGS and GOG
2. UWP doesn't allow disabling TitleBar and TaskBar for fullscreen apps - So Win32 has an exclusive fullscreen option, UWP does not - which is a deal breaker for many, many games.

Microsoft never bothered solving problem # 1 - they at least know it's an issue. But we will have to wait for .Net 5 on the hope they finally get it. But It's the same people pulling the levers isn't it?

It seems they don't understand the second problem. They have never acknowledged it or said that it would be fixed - It's been long enough that we now know UWP on desktop will never support games correctly. They have restricted the vision of UWP on desktop to an application platform only, rather than a general purpose platform. That's a huge mistake, and the movers and shakers should be berated by Phil Spencer or Chuck Walbourn or somebody that knows why games are important.

It's all such a shame, because UWP achieved great swapchain and rendering surface integration into Xaml. It was much better than what we had before. UWP promised C++/C# interop though it didn't quite deliver, C++/CX was pretty good but the interop story has since been misled by C++ archanists. No offense to those people, they have their own agenda, but the interop was meant to make it easier for C# to consume C++ and these days it's getting further from that dream except for expert teams to employ.

I'll leave this graphic here to help people understand why games shouldn't be ignored and why Win32 is still needed ..