I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid.
Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that:
Enumerating the machine’s displays and their bounds
A few API calls. Probably a few hundred bytes.
Placing borderless, titlebar-less, non-activating black windows
Creating non-functional windows is trivial. Another few hundred bytes at most.
Intercepting a global keyboard shortcut
A few dozen bytes to call SetWindowsHookEx.
Optionally running at startup
Write to the appropriate registry key. A few hundred bytes.
Storing some persistent settings
Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size.
Displaying a tray icon with a few menu items
Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls.
Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead.
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare.
MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell.
I think it's fair to say that the entire story for native app development is a mess - which is most likely why Electron became so popular. There just isn't a practical sane alternative.
The sane alternative is macOS because there is one thing that Windows lacks; a community. Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.
> Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
Microsoft has had even more people working on Windows software..
"Developers, Developers, Developers!" - Steve Balmer
Microsoft has always had vastly more developers and development of software for Windows.
Apple still after all these years has a tiny market share of overall platforms, software, all of it really.
Not sure how you can suggest Apple is somehow the bastion of software development. If you write mac software, you'll be targeting a platform with 15-20% market share at best.
Isn't software development about making money? On phones, if you want to make money you have to target iOS, since this is where you have the people with money to spend on software. Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
At a previous workplace, we released certain software targeted at media/videography professionals for macOS first. The immediate response at conferences was, 'do you have a Windows version? We all use Windows.' Once we ported our software to Windows, the uptake was easily 1.5 orders of magnitude greater than for macOS.
The era of 'macOS is a better media computer' is long gone.
>On phones, if you want to make money you have to target iOS
It's funny that you think Android users are broke-ass nobodies. That's some reality-distortion-field fanboi nonsense. And it's also hilarious that you think phone apps are useful software that costs lots of money.
Most people in tech with high-paying jobs that I know are using Android, because it's actually pretty awesome compared to the locked-down walled-garden that is Apple. More than half my friends use Android or Windows. They use Android because it isn't as locked-down as iPhone. They use Windows because it runs all the software they want it to run. We also really don't care about Apple's blue bubbles.
No, Apple users are not the only ones with jobs. Plenty of Android users have plenty of disposable income. It's a ridiculous argument to make that Apple users have more money to spend.
>Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
I don't have to believe it, the market believes it. People vote with their dollars, and they aren't voting for Apple all that often worldwide. Plenty of wealthy people use Android and Windows. I'd wager that most big companies are still run on Windows - and I know this experientially, from back in the day setting up computers for major corps, it was 85% Windows, 15% Apple. Always was, always will be.
Way to go with anecdata to try and disentangle your feelings from reality. Come back when you have cold hard facts. With 27% of the market, they make twice as much money on their app store.
Making money does not equate to popularity. It only means their users are suckers for overpaying. $1000 for a monitor stand? $700 for 4 tiny wheels? Yet people pay these absurd prices for their niche over-hyped and over-priced hardware. "A fool and their money are soon parted."
Then how do you square that Apple has a billion worldwide users? They're all fools? Everybody who bought an iPhone is an idiot? There's no way an 900$ iPhone is a good purchase when the equivalent device that Samsung advertises as a competitor is over a thousand bucks?
You lost my interest when you suggested that iPhone was the platform to target because those users have all the money to spend. This pointless internet interaction is over.
I've been a fulltime Linux user for years but there are tons of excellent Windows-only apps.
Here are some that I miss: Directory Opus, ShareX, Wiztree, Everything, AltDrag, AutoHotkey, Paint.NET, irfanview, SumatraPDF. I'd add Keepass2 as well but fortunately KeepassXC is a thing.
Those are all feature-filled (in the bloat-free good way) and they've all been around for over a decade (from memory). Most are free and open source to boot.
MyLifeOrganized was the biggest thing I gave up when I switched to Mac in 2013. Still miss it -- nothing else (Omnifocus, Things, outliners, etc) has been as effective as a system for me. They've been talking about a potential Mac app for year, I'm on the waiting list, but I've given up hope that it'll ever come. Even if it does, I doubt it'll be as good as it is on Windows.
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs
IDK man, I wonder how TF did the creators of Winamp do it? Were they so much smarter than the programers of today? And Winamp 2.95 still works on WIndows 11 today.
IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.
If you don't want to spend quite so much time byte shaving, and you don't want to deal with memory safety or _UNICODE, you can do it in .Net Framework in half the time.
A couple of weeks ago, I decided to write a GUI utility to propagate my new PuTTY default settings to existing sessions. I took the Go Walk package, which is Win32, and was done in several hours, most of those spent hunting down an obscure layout bug. So long with memory-unsafe languages.
I made an app using Win32 in Golang. It controls my monitors' brightness and "true-tones" them to match the sun cycle via DDC/CI. It has autostart, global hotkeys, persistent settings, sits in the tray, silent auto updates etc.
The hard parts were seeded by Claude Code. Happily maintaining and modifying it for close to 3 months now. Just a data point, especially about not needing C++.
There were decent and reasonably thin layers over that to solve the immediate practical issues (e.g. Delphi, MFC), but they're no longer fashionable and nothing seems to have replaced them in the same space. Maybe we need a "NoFramework" phase to get back to RAD again?
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.*
Eh. I spent many years writing cloud/backend software on the JVM, in between stints writing desktop software. When I was first writing desktop software, it was all in C and C++, and I got used to it, but it wasn't pleasant.
When I came back to writing desktop software in C again (just a few years ago), after writing in memory-safe languages for so long (Java, Scala, Rust, Go), I found going back to C to be just so tedious and annoying. It's just incredibly unpleasant to be chasing down segfaults and data races and crap.
So I think saying it's a "crime" is hyperbole, but even for apps that don't have untrusted input, it's still much more pleasant writing in a language that doesn't let you write memory safety bugs.
(Absolutely agree with you on how it's possible to make nice, small, non-trivial Win32 apps, though I haven't done Windows app development in a couple decades. But I think a lot of people would save themselves a lot of time and headaches if they reached for .NET or something higher level.)
This is the way. Everything is fine if you are a responsible dev that writes secure code. You can very clearly see the pattern of shitty framework after shitty framework coming and going. Why bother when the C++ code will outlive whatever shitty framework is coming next?
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.
Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:
1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
Again, unless you have existing Windows 8/10 applications that were written against WinRT, UAP or UWP[0], that make use of WinUI 2.0, forget about touching anything related to WinUI 3.0 or WinAppSDK, stay away from the marketing.
Exception being the few APIs that have been introduced in Win32 that instead of COM, actually depend on WinRT like the new MIDI 2.0 or Windows ML.
Keep using Win32, MFC (yes it is in a better state than WinUI 3.0 with C++), WinForms, WPF, if using Microsoft only tooling.
They were even forced to revamp WPF status at BUILD 2024, given how bad WinUI 3.0 was back then, and it isn't if it got any better, apparently it is in the process of being open sourced, to see if the community can take over the mess a $4 trillion valued company cannot fix.
Really, stay away from WinUI, unless you're a Microsoft employee on the Windows team without any other option.
[0] - Can explain by the nth time the differences, if one feels like it.
The lessons I've learnt building and shipping a few a Windows apps at scale are basically:
(1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They're not that scary.
(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt. Literally anything is better. Ideally choose a toolkit that doesn't prevent layering in Win32 tweaks on top, otherwise you'll end up hitting cases the toolkit developers didn't think of and you can't fix. You're going to need a custom WindowProc eventually. You need to have access to the underlying Win32 window lifecycle and handles.
Let me chime in and say that plain Win32 API is a perfectly viable option if you are using C++ (or another "OO" language) and if you are willing to sink a couple of weeks into writing your own MFC-like wrapper.
Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuances of the UI, yours to extend and mend as you wish.
If there's one thing that Microsoft is really good at, it's ensuring deep backward compatibility. So anything that's based on Win32 API is going to be stable. If it works now, it will work later.
I have some examples from 10+ years of development updates accumulated here - https://bvckup2.com/wip
> And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration.
Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article shows. But as a user I don't see that problem. I do see ever worsening apps though. Like the total mess that is new outlook and teams.
> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
I disagree, the GUI layer is far from behind a safety critical component, and C++ is a battle-tested choice for everything from GUI, videos games, to industrial applications. If C++ is safe enough to control airplanes and nuclear reactors when used well, it is certainly safe enough for something as trivial a GUI.
The article also fails to mention frameworks like Qt, arguably the best way to write GUI apps in 2026. Qt is native (C++), has built-in memory safety features (but no GC), and is cross-platform.
Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment?
It's another example of how they have completely abandoned any attempt at providing a good user experience across their products
Really nice article, thanks - yes I found the same myself recently when trying to write a trivial (I thought) Windows app.
I first investigated the Windows native options and was pretty bamboozled; I wanted to use the "mainstream" "up to date" option (presumably c# and some framework) but as TFA describes, it wasn't at all clear which that was.
I ended up doing it in python with pyqt then finding out a clean deployment was a pain, so revisited the .Net options and remembered why I'd discarded them in the first place...
It is indeed a complete mess (at least coming in anew) and a very strange situation for the world's main desktop environment to be in.
It had been many years since I last developed a desktop app. A couple of weeks ago I used Tauri to create a simple app for Windows and Mac. Developing the app was easy with Claude. Building the app for different platforms and architectures was easy with GitHub Actions.
But after I had the msi and dmg files, my non-techy colleagues couldn't install the apps because they weren't signed. The workaround for Mac was fine (remove the quarantine attribute on the installer) but for Windows my colleague had to disable Smart App Control (SAC), which cannot be re-enabled without re-installing Windows.
I get the point of these protections, but the difficulty of getting past them surprised me. I thought that on Mac you should just go to settings -> security and click 'Allow Anyway'. And that on Windows you'd get a GUI warning that would need admin privileges to get past. But MacOS needed a terminal command, and Windows needed a control panel setting change.
I'm glad people still care about stuff like this. It drives me insane that the simplest form-based software that I build and compile ends up being 50-100 MiB; several times video games from the 80s that I grew up with that did much more complex work, graphically and computationally, on a tenth of the space.
The answer to your question of "why not Electron" at the end is: because then your app will suck. You've laid out the reasons why native apps are harder to make, but the reality is that Electron trades your ease of development for the user having a crappy experience. If you care about producing a good product, then you have to suck it up and make the native app even if it is harder.
Also, I think C# is miles better than TypeScript, but that's just my preference.
> 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.
.NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET as a runtime like Java or Python.
---
Regarding tray icons, 1Password, Signal, and Discord are all Electron apps, so they are using Chrome’s UI toolkit, and its menu component.
Myself, I’m happy with WPF. Starting with .NET 9, it comes with a really good WinUI-style theme.
It has been a mess for 15 years and Microsoft keeps making it worse by adding new frameworks without retiring the old ones. Win32, WPF, WinUI, MAUI. Nobody knows which one to pick.
This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit.
My first thought was MFC. Basic, fast, well understood.
But then maybe WxWindows so we can cross-compile it (from Linux) and use the same UI on other platforms? It could probably be compiled statically although I've not tested it.
Or Mono, but that needs a runtime?
Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
It’s been a long time since I had to touch Windows development. If I had to do it over again, I would use React Native for Windows UI where possible and low-level Win32-React Native module bridges for user space code.
The last time I had to do Windows development was about 15 years ago. I used a library called WTL (I think a couple comments here mention it). I couldn’t use any of the newer stuff that Windows 8-10 were pushing because it needed backward compatibility. It seemed way less bloated than MFC, but not as annoying to use as ATL or rawdogging Win32 APIs.
Ironically, I was developing a Win32 app to build a cloud bridge to a Rails app (talking to Quickbooks COM API which was hell on Earth, with XML and XML definitions) on Mac, using VMware on Mac to talk to Quickbooks Windows. I was so annoyed with Win32 development I used the Chrome Embedded Framework library to build the UI for the Win32 app so I wouldn’t have to wrestle WTL for UI and just have browser-based views to drive UI.
I think it was very tempting to drop C/C++ development for .NET code, but I didn’t want to drop off user adoption by requesting users to download a huge .NET runtime if their computer didn’t already have it.
This was when I was building Levion, a Quickbooks Windows to Cloud Rails app…
The Windows code signing experience has prevented me from shipping apps that otherwise run perfectly fine on the platform. It is a nightmare and I cannot believe it wasn't called out in the "We want to fix Windows" blog post.
Just do exactly what Apple does. Charge me $100 directly from you and let me build an .exe that I can distribute on my website.
Most of the desktop applications I have wrote over the years have been in other languages like Java and Go as I have wanted them to mostly be cross platform. In these cases I have always used the Software UI, which in Java is Swing and in Go is Fyne. These are usually reasonably fast, don't necessarily look native depending on how its themed but ultimately fit the language better than trying to bridge to Win32 or GTK/QT.
I write .NET Framework 4.8 apps. And I will until .NET has an actual support lifetime. 4.8 will still be supported and receiving security updates in ten years, .NET 10 will be gone in 2.
Hobby projects should not be built on a platform that is constantly changing underneath.
"So when I went to work on my app, I was astonished to find that twenty years after the release of WPF, the boilerplate had barely changed."
Such is the benefit and the curse, I guess, of having the Windows API being locked in the distant past for backwards compatibility.
I've always been surprised that Microsoft didn't do a full operating system refactor and provide a compatibility layer for running old binaries. Perhaps they figure it would be better to just transition everything to software as a service using web tech? But I just don't see how that strategy is gonna work long-term.
469 comments
Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that:
Enumerating the machine’s displays and their bounds
A few API calls. Probably a few hundred bytes.
Placing borderless, titlebar-less, non-activating black windows
Creating non-functional windows is trivial. Another few hundred bytes at most.
Intercepting a global keyboard shortcut
A few dozen bytes to call SetWindowsHookEx.
Optionally running at startup
Write to the appropriate registry key. A few hundred bytes.
Storing some persistent settings
Ditto. Another few hundred bytes. You can use a .ini file too, for around the same size.
Displaying a tray icon with a few menu items
Most of this size of this will be the icon itself - a few kilobytes; the next biggest contributor will be text strings; and the rest is accomplished with a few hundred bytes of API calls.
Add another few hundred bytes of (not much) logic, round up to a kilobyte and add maybe another for general overhead.
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell.
I think it's fair to say that the entire story for native app development is a mess - which is most likely why Electron became so popular. There just isn't a practical sane alternative.
When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.
> Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.
Microsoft has had even more people working on Windows software..
Microsoft has always had vastly more developers and development of software for Windows.
Apple still after all these years has a tiny market share of overall platforms, software, all of it really.
Not sure how you can suggest Apple is somehow the bastion of software development. If you write mac software, you'll be targeting a platform with 15-20% market share at best.
The era of 'macOS is a better media computer' is long gone.
>On phones, if you want to make money you have to target iOS
It's funny that you think Android users are broke-ass nobodies. That's some reality-distortion-field fanboi nonsense. And it's also hilarious that you think phone apps are useful software that costs lots of money.
Most people in tech with high-paying jobs that I know are using Android, because it's actually pretty awesome compared to the locked-down walled-garden that is Apple. More than half my friends use Android or Windows. They use Android because it isn't as locked-down as iPhone. They use Windows because it runs all the software they want it to run. We also really don't care about Apple's blue bubbles.
No, Apple users are not the only ones with jobs. Plenty of Android users have plenty of disposable income. It's a ridiculous argument to make that Apple users have more money to spend.
>Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?
I don't have to believe it, the market believes it. People vote with their dollars, and they aren't voting for Apple all that often worldwide. Plenty of wealthy people use Android and Windows. I'd wager that most big companies are still run on Windows - and I know this experientially, from back in the day setting up computers for major corps, it was 85% Windows, 15% Apple. Always was, always will be.
https://appleinsider.com/articles/24/06/05/app-store-just-ha...
I've been a fulltime Linux user for years but there are tons of excellent Windows-only apps.
Here are some that I miss: Directory Opus, ShareX, Wiztree, Everything, AltDrag, AutoHotkey, Paint.NET, irfanview, SumatraPDF. I'd add Keepass2 as well but fortunately KeepassXC is a thing.
Those are all feature-filled (in the bloat-free good way) and they've all been around for over a decade (from memory). Most are free and open source to boot.
Also, I am pretty sure that SumatraPDF is available for Linux as well. I am not at a computer but I think it is in the AUR.
But I agree that most of the boutique stuff on Windows gets drowned in all the enterprise software a bit.
With electron this is much easier because nothing is native and it looks and feels just like the website.
Of course, if one is a web developer, even attempting such a feat this could result in a brain-melting experience.
MacOS is not quite so simple: https://news.ycombinator.com/item?id=40085237
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs
IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.
Here's the source code for those who are interested: https://github.com/sergeax/stamputty
The hard parts were seeded by Claude Code. Happily maintaining and modifying it for close to 3 months now. Just a data point, especially about not needing C++.
>>
But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.*
Eh. I spent many years writing cloud/backend software on the JVM, in between stints writing desktop software. When I was first writing desktop software, it was all in C and C++, and I got used to it, but it wasn't pleasant.
When I came back to writing desktop software in C again (just a few years ago), after writing in memory-safe languages for so long (Java, Scala, Rust, Go), I found going back to C to be just so tedious and annoying. It's just incredibly unpleasant to be chasing down segfaults and data races and crap.
So I think saying it's a "crime" is hyperbole, but even for apps that don't have untrusted input, it's still much more pleasant writing in a language that doesn't let you write memory safety bugs.
(Absolutely agree with you on how it's possible to make nice, small, non-trivial Win32 apps, though I haven't done Windows app development in a couple decades. But I think a lot of people would save themselves a lot of time and headaches if they reached for .NET or something higher level.)
Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:
1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
Exception being the few APIs that have been introduced in Win32 that instead of COM, actually depend on WinRT like the new MIDI 2.0 or Windows ML.
Keep using Win32, MFC (yes it is in a better state than WinUI 3.0 with C++), WinForms, WPF, if using Microsoft only tooling.
Otherwise, Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI,....
They were even forced to revamp WPF status at BUILD 2024, given how bad WinUI 3.0 was back then, and it isn't if it got any better, apparently it is in the process of being open sourced, to see if the community can take over the mess a $4 trillion valued company cannot fix.
Really, stay away from WinUI, unless you're a Microsoft employee on the Windows team without any other option.
[0] - Can explain by the nth time the differences, if one feels like it.
The lessons I've learnt building and shipping a few a Windows apps at scale are basically:
(1) Learn Win32 and use those ancient APIs if possible, they're extraordinarily stable and you'll probably need to reach for them anyway. They're not that scary.
(2) Don't use any Microsoft-owned UI toolkit, you'll get burnt. Literally anything is better. Ideally choose a toolkit that doesn't prevent layering in Win32 tweaks on top, otherwise you'll end up hitting cases the toolkit developers didn't think of and you can't fix. You're going to need a custom WindowProc eventually. You need to have access to the underlying Win32 window lifecycle and handles.
Clearly this is not an option for those who are just starting up with Windows GUI work, but with little experience it is really a matter of 2-3 weeks of ground work and then you have full control over all nuances of the UI, yours to extend and mend as you wish.
If there's one thing that Microsoft is really good at, it's ensuring deep backward compatibility. So anything that's based on Win32 API is going to be stable. If it works now, it will work later.
I have some examples from 10+ years of development updates accumulated here - https://bvckup2.com/wip
> And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration.
Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article shows. But as a user I don't see that problem. I do see ever worsening apps though. Like the total mess that is new outlook and teams.
> But, in 2026, writing a greenfield application in a memory-unsafe language like C++ is a crime.
I disagree, the GUI layer is far from behind a safety critical component, and C++ is a battle-tested choice for everything from GUI, videos games, to industrial applications. If C++ is safe enough to control airplanes and nuclear reactors when used well, it is certainly safe enough for something as trivial a GUI.
The article also fails to mention frameworks like Qt, arguably the best way to write GUI apps in 2026. Qt is native (C++), has built-in memory safety features (but no GC), and is cross-platform.
It's another example of how they have completely abandoned any attempt at providing a good user experience across their products
I first investigated the Windows native options and was pretty bamboozled; I wanted to use the "mainstream" "up to date" option (presumably c# and some framework) but as TFA describes, it wasn't at all clear which that was.
I ended up doing it in python with pyqt then finding out a clean deployment was a pain, so revisited the .Net options and remembered why I'd discarded them in the first place...
It is indeed a complete mess (at least coming in anew) and a very strange situation for the world's main desktop environment to be in.
But after I had the msi and dmg files, my non-techy colleagues couldn't install the apps because they weren't signed. The workaround for Mac was fine (remove the quarantine attribute on the installer) but for Windows my colleague had to disable Smart App Control (SAC), which cannot be re-enabled without re-installing Windows.
I get the point of these protections, but the difficulty of getting past them surprised me. I thought that on Mac you should just go to settings -> security and click 'Allow Anyway'. And that on Windows you'd get a GUI warning that would need admin privileges to get past. But MacOS needed a terminal command, and Windows needed a control panel setting change.
> 9 MiB
I'm glad people still care about stuff like this. It drives me insane that the simplest form-based software that I build and compile ends up being 50-100 MiB; several times video games from the 80s that I grew up with that did much more complex work, graphically and computationally, on a tenth of the space.
Also, I think C# is miles better than TypeScript, but that's just my preference.
> 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.
.NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET as a runtime like Java or Python.
---
Regarding tray icons, 1Password, Signal, and Discord are all Electron apps, so they are using Chrome’s UI toolkit, and its menu component.
Myself, I’m happy with WPF. Starting with .NET 9, it comes with a really good WinUI-style theme.
My first thought was MFC. Basic, fast, well understood.
But then maybe WxWindows so we can cross-compile it (from Linux) and use the same UI on other platforms? It could probably be compiled statically although I've not tested it.
Or Mono, but that needs a runtime?
Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
The last time I had to do Windows development was about 15 years ago. I used a library called WTL (I think a couple comments here mention it). I couldn’t use any of the newer stuff that Windows 8-10 were pushing because it needed backward compatibility. It seemed way less bloated than MFC, but not as annoying to use as ATL or rawdogging Win32 APIs.
Ironically, I was developing a Win32 app to build a cloud bridge to a Rails app (talking to Quickbooks COM API which was hell on Earth, with XML and XML definitions) on Mac, using VMware on Mac to talk to Quickbooks Windows. I was so annoyed with Win32 development I used the Chrome Embedded Framework library to build the UI for the Win32 app so I wouldn’t have to wrestle WTL for UI and just have browser-based views to drive UI.
I think it was very tempting to drop C/C++ development for .NET code, but I didn’t want to drop off user adoption by requesting users to download a huge .NET runtime if their computer didn’t already have it.
This was when I was building Levion, a Quickbooks Windows to Cloud Rails app…
Just do exactly what Apple does. Charge me $100 directly from you and let me build an .exe that I can distribute on my website.
Hobby projects should not be built on a platform that is constantly changing underneath.
Such is the benefit and the curse, I guess, of having the Windows API being locked in the distant past for backwards compatibility.
I've always been surprised that Microsoft didn't do a full operating system refactor and provide a compatibility layer for running old binaries. Perhaps they figure it would be better to just transition everything to software as a service using web tech? But I just don't see how that strategy is gonna work long-term.