Windows Native App Development Is a Mess
48 points by skobes
48 points by skobes
Do people use the modern WinUI/WinRT stuff (outside the rare enthusiast example and bizarrely, Apple)? My impression is that the only truly native Windows apps are codebases that existed 10 years ago, using traditional Win32 (or ATL?MFC) or .NET (WinForms/WPF). Everyone seems to use cross-platform frameworks, be it Qt or Electron - even Microsoft. What does developing for Microsoft's new frameworks get you over using those?
And yeah, the .NET distribution story got a lot worse (and more confusing) post-Framework IMHO.
I think deploying the .NET runtime as part of an application is basically fine. It's no worse than shipping a browser runtime for Electron apps!
And in many places with internal set of apps, preinstalling .net is just fine. I'm deploying 5 apps of my own to one company. I'm just installing the version of .net I need on all their systems and that's ok.
IMHO, Microsoft should have invested into extending and updating Win32 API (e.g., adding support for dark mode) instead of creating multiple incompatible "modern" frameworks. Joel Spolsky described this many years ago: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
Apple is still good with Cocoa, which is 25 years old and has roots in NeXTSTEP from 1980s. You don't really need to invent a desktop framework every year; the pace is much slower here than in web development.
And they really did extend Cocoa in many ways. Lots of them undocumented, confusing and proprietary, but trying to dig into some of it, does show how much they changed since taking over.
And yeah, the .NET distribution story got a lot worse (and more confusing) post-Framework IMHO.
Did it? If anything, I found it way easier being a developer on the other side of that transition period. MFC apps are ancient and only present for ancient C++ codebases. The status quo is using C#/.NET. If that is WPF, WinForms, MAUI, or some other framework, that's up in the air and team-dependent.
I mean even Microsoft doesn't want to develop native Windows applications. It's pretty embarrassing that Teams is electron (or similar).
Teams has a different requirement: run on all platforms. It makes sense why that's built on Electron in context.
All that does is make it somewhat less embarrassing. And it indicates that they haven't invested in making this (common) problem easier.
Edit to add: unclear to me how much Apple was involved in Swift's Android port, but to the degree they were, I suspect they ported it not to compete with Kotlin, but to compete with Flutter. The problem being declining quality/native-ness of iOS apps because teams had to support cross-platform. With Swift on Android, you can write a cross-platform app... but oops, it's native on iOS, and just a little foreign on Android.
But this format relies heavily on code signing certificates, which seem to cost around $200–300/year for non-US residents. The unsigned sideloading experience is terrible...Unsigned MSIX sideloads [could] use the same crowd-sourced reputation system that EXE installers get.
This is a raw nerve. Without code signing, reputation needs a fixed hash, so if you ever change the binary for any reason, reputation is reset. In the modern world, new binaries happen every couple months. In practice code signing certs are needed with no real way to get them.
Last I looked into this, there's Azure Artifact Signing, which works by asking you to send your government ID to some tiny provider that you've never heard of.
And their recent announcement of a focus on Windows quality includes a line about using WinUI 3 more throughout the OS, which could in theory trickle back into improving WinUI itself.
Perhaps, but they don't experience their third party distribution flow.
This is a raw nerve. Without code signing, reputation needs a fixed hash, so if you ever change the binary for any reason, reputation is reset. In the modern world, new binaries happen every couple months. In practice code signing certs are needed with no real way to get them.
Last I looked into this, there's Azure Artifact Signing, which works by asking you to send your government ID to some tiny provider that you've never heard of.
And even if you're willing to accept the whole ID verification thing, Azure Artifact Signing is only available to individual developers in the USA and Canada. If you're in the EU or UK you've got to be a company, and if you're anywhere else its apparently unavailable entirely. So basically for me in NZ building an open source app code signing simply isn't feasable.
Perhaps if writing native Windows apps was a pleasant experience we’d have less of the ”fuck it, just package a web page in Electron” garbage and by extension more native macOS and Linux apps… wishful thinking, but it’d be nice.
I don't understand this sentiment. Writing native Windows apps is fine. Install VS Community, spin up your C# app in WPF, it's been there for at least 10 years.
But it's not "the current" or the "lastest" or some such. My colleagues don't want to write a new app in old tech that MS has abandoned. But MS has abandoned all their GUI toolkits…
WPF is the best way to make GUI apps in Windows I've tried, and even if XAML and bindings can be a bit fiddly I think it's fine. Not perfect, but gets the job done.
However, for no reason I can understand, Microsoft has decided that even the latest versions of Windows 11 only get .NET 4.8.1 preinstalled. (The current version of .NET is 10.)
Unfortunately, I think this situation is the best compromise for what’s best for both Windows and .NET.
Windows has a strict breaking change policy - updates should not break apps.
However, .NET needed to do sweeping breaking changes to become cross-platform. Preinstalling modern .NET would’ve broken countless apps. So instead, Windows bundles .NET 4.8 as it’s bug-for-bug compatible with legacy apps.
And now that Windows doesn’t bundle modern .NET, .NET can evolve much faster than before.
However, .NET needed to do sweeping breaking changes to become cross-platform. Preinstalling modern .NET would’ve broken countless apps. So instead, Windows bundles .NET 4.8 as it’s bug-for-bug compatible with legacy apps.
No? .NET versions can coexist, there's nothing stopping them from preinstalling it and keeping it up to date with windows update. Or do you mean .NET core versions don't care about compact as much so you need more versions installed?
I think both the post author and parent commenter are confused about Windows .NET Framework, and .NET (Core) 10.
Like the author, I cut my teeth on "Beginning Visual C++ 6". I haven't followed WinRT and WinUI closely but I'm not surprised to hear that many tasks still require the Win32 API.
I do think someone building a desktop app today is likely to reach for a cross-platform framework first, because (a) desktops are not 90% Windows like they were 20 years ago and (b) the web has relaxed users' expectations of "native" UI consistency.
From this post I discovered Tauri, which looks pretty cool.
Recently I also had attempted to build a simple windows GUI app, and after getting lost in the options ended up using Tauri. I probably wouldn't go with it for a large, complex project, but for my mini-app it was a completely painless experience.
Native UI really feels like a lost art in a Preventing the collapse of civilization way.
the whole project of native Windows app development feels like it’s not a priority for Microsoft
It makes some sense though due to the likely immediate ask of any program for "How do I use this app on a Mac (or Android, or iPhone)?" Windows as a whole feels like there's been a lack of investment.