Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
Edit: Thank you for giving such a nice summary of the current landscape of UI dev in Windows native development.
I wonder why nobody's created a "XAML projector" to allow you to create Windows UI applications the same way — by writing some platform-neutral app in Java or whatever, that needs no native libs loaded into it, but rather just knows how to generate XAML and, when told it's running on Windows, expects to be connected to over a socket by an also-XAML-speaking client.
Or I could say the same about Qt's QML.
(In fact, at this point I have to wonder: if modern UI frameworks almost always use an intermediary "view definition language" to communicate with the application anyway, then why are they even designed to load as native libraries resident inside the process? Why not just reinvent the X protocol on a higher level — have the UI toolkit be a local (socket-activated) daemon, and then all the things that use it are just clients that speak its protocol? I know, you can't directly draw to the screen from your backend this way. X11 DRI worked, though, and IMHO was a very good idea — SHM buffers are way easier to get working in most language runtimes than an FFI binding of some C++ UI toolkit is. Or maybe we can do one better, these days: just expose WebGL commands addressable to WebGL canvas objects over the toolkit's protocol.)
I, for one, never stopped developing in WPF.
Modern JavaFX theme: https://github.com/mkpaz/atlantafx
Modern Swing theme: https://github.com/JFormDesigner/FlatLaf
And these days Compose Multiplatform: https://www.jetbrains.com/lp/compose-multiplatform/
I tend to use Kotlin rather than Java but of course Java is perfectly fine too. You can also use Clojure.
If you use any of those frameworks you can distribute to Win/Mac/Linux in one command with Conveyor. It's free for open source apps and can do self-signing for Windows if you don't want to pay for the certificates or the Store (but the Store is super cheap these days, $19 one off payment for an individual). Also supports Electron and Flutter if you want to use those.
From those frameworks you can then access whatever parts of the Windows API you want. Flutter even has WinRT bindings these days! So it's not quite so bad.
But hey, from all the warts, and screw-ups, the other gardens aren't much better.
Worst part of WPF for me was the tooling that crashed whenever you so much as looked at it wrong.
Avalonia, React (Native) and Flutter all seem to be doing pretty well as alternatives as well. All with cross platform support and less friction than the Microsoft solution(s) for this. That MS didn't support MAUI with at least Linux+GTK/Gnome from the start, who knows, it was a massive miss for a lot of devs imo.
As it turns out, Windows is nothing without Win32 which developers and users want. Consequently, Win32 has subdued every single attempt from Microsoft to replace it. Every. Single. Attempt.
The recent moves back to Win32 are essentially Microsoft finally throwing in the towel, though the jury is still out if they understand why Win32 keeps on slaying them at every turn.
And while I'm not aware of any way to sandbox Windows Installer itself, I'm curious if AppContainer isolation can be applied to applications and services installed via MSI, which would still be quite useful even if the installation process itself is unrestricted.
Alternatively, now that MSIX supports service installation[2], I wonder whether an MSIX including a Windows service and a collection of client applications can be configured so everything runs within one AppContainer, isolated from the rest of the system, and whether permission to access specific external directories chosen by users in a configuration GUI can be transparently (to the user) delegated to the related service.
Alas, none of this is useful to me unless it's compatible with at least the most recent version of Windows 10: very few of my customers are running Windows 11, and I suspect many won't upgrade until Windows 10 is no longer supported (optimistically; as of last year, I was still getting occasional support requests from customers running older versions of our software on Windows Server 2003 R2).
[2] https://learn.microsoft.com/en-us/windows/msix/supported-pla...