Winapp, the Windows App Development CLI
blogs.windows.com
blogs.windows.com
Anything related to WinUI, WinAppSDK, CsWinRT, C++/WinRT is a sea of bugs, broken tooling, and unfulfilled promises, that no one should bother with.
Easily confirmed by going into their public repositories over at Github, or community session recordings over at YouTube.
For those using .NET, keep using Windows Forms or WPF, or reach out to Avalonia and Uno.
For those using C++, the aging MFC has much better tooling as incredible as it sounds, or use instead VCL/Firemonkey (C++ Builder), Qt, wxWidgets,....
For anything else, whatever bindings are available on top of plain Win32.
I'm a big fan of the MFC/WinForms era stuff myself, but it has one crippling limitation: it doesn't handle display scaling very well at all.
There are Win32 APIs for HiDPI configuration, the issue is that it isn't automatic, it needs to be on the app manifest or called explicitly, and handle the events for resolution changes.
Plain Win32 needs a renaissance. I worked with it and felt like a wizard. Message boxes, dialogue boxes, wizards, hammered out in pure C++. Combined with the Windows Implementation Library[1] I was writing fast, modern code.
Here is the original announcement,
https://community.osr.com/t/the-new-wil-library-for-c-code-i...
I'm developing windows desktop apps since nearly 30 years now and tried mostly everything Microsoft has thrown at us - Win32 - WinForms - WPF - WinJS - WinRT - UWP - WinUI - MAUI - not sure if that was all - and Win32 always wins. Everything else is incredible broken and stops being supported in such a short time. It's a shame really.
I switched from someone that was kind found of WinRT, as what .NET 1.0 should have been, AOT compiled languages built on top of COM, improving the VB 6 experience, to someone burned out with the experience, back into Web development and distributed systems.
However, Microsoft keeps talking as if everything was tiptop, and that angers me thus I keep track of how bad things still are, and spend time making others aware of the false promises.
For example, I bet no one is aware that C++/WinRT is actually in maintenance, and the team responsible for killing C++/CX, is now having fun with Rust on windows-rs.
Yet Microsoft talks about using C++ to develop WinUI applications, as if the tooling was at the same level as using C++ Builder or Qt/QtBuilder.
Programming Windows, by Charles Petzold
Programming Windows with MFC, by Jeff Prosise
COM / DCOM Primer Plus, by Chris Corry Vincent Mayfield John Cadman
The Web versions also consume C++ via WebAssembly, the mobile versions are a mix of the platform languages + C++.
There are some CppCon talks about how they use C++ in Office.
Where do I start? Do you have a compiled version of some information on this?
Since I know those languages since 1992, and have coded for Windows since Windows 3.0, I never bothered with any guide personally.
I hate to say but GitHub Copilot can get you started. It slurped up all of Microsoft SDK and docs and open source libs. It is a decent reference.
I'm also kinda impressed by the Debugger Agent [0] built into Visual Studio 2026.
[0] https://medium.com/@onu.khatri/copilot-squad-in-vs-2026-ca88...
In a complicated Excel sheet I had the Conditional Formatting Rules Magaer crash due to an issue in EmbeddedWebView2.dll. Renaming it helped preventing the crash without obvious decline in functionality in Excel, until I tried to join a Teams meeting which obviously uses WebView2.
It could be worse—it could be Linux, with no forward compatibility. The VC/C++ redistributable means that applications can be written on modern Windows that targets much older Windows, by simply providing a sidecar installer that brings with it a newer C/C++ standard library. This situation is basically impossible on Linux without messing with Docker.
What older windows? Everyone consumer (who are all on forced updates) has to deal with this for the benefit of the small minority on older versions of windows which are probably systems you're not installing new software on anyway.
Yet another opportunity to submit a few issues on the repos.
Why are they building CLIs and tooling in this way? Don't they realize that shipping low quality code will eventually hurt them more than whatever UX benefits it gives developers? People will give up on using this quicker than the attention you get from launching it.
Just one example that shows how little they care, since the commit message is obviously written by an agent/LLM, the code surely is as well: https://github.com/microsoft/winappCli/commit/3dead8ed147917...
They should have inspected the code of Claude Code first, and then make a judgement, because these agents are not ready to just write themselves without proper engineering-oversight. I'm guessing the technical debt and bug count will keep increasing until they realize this.
Can you add MAUI to this list? Please and thank you.
Seems Llamas will disappear as quickly as they became trendy.
Note, that "Windows" used to be a class of operating systems, not a specific one (as in an OS with a Windowed system and metaphor), e.g. X Windows also exists. The role of "Windows" in "MS Windows" is(used to be) really the same as "Basic" in "MS Basic". Also some people also have a (legal) opinion about the implications of using non-standard abbreviations of "MS Windows": https://www.gnu.org/prep/standards/html_node/Trademarks.html
I'm not a traditional app dev on Windows though, so I'm likely missing something. For those of you who are more familiar, what about this are you excited about?
I've moved on, but this looks like it will at least fix some of the paper cuts.
It's another small nail in the coffin of the monolithic Visual Studio, which is maybe exciting if you are rooting against Microsoft's paid products from their DevDiv and for their free-to-start options like VSCode.
Unlike regular Windows SDK, which lets you make use of the functionality provided by the OS, the WindowsAppSDK is entirely separate from the OS and requires the installation of a separate runtime on the user's machine. It also requires installing nuget packages on your machine to use it so good luck if you'd rather use straight CMake instead of Visual Studio.
As far as I can tell, there's no backwards or forwards compatibility, so the end user has to install the specific version of the SDK your app uses, or you need to bundle all the hundreds of DLLs with your app yourself.
A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
As far as I can tell there's no sane negative answer to this question. It's not like your app's "fluent theme" will be updated alongside the OS, it's no different from Qt or Electron in this regard.
There's no reason to do "native" windows development anymore, unless you mean using raw Win32 with no dark theme or a custom UI built on Direct2D/3D/Write. And if you are doing that, there's absolutely 0 reason to use this CLI.
Couldn't this "dark theme" stuff be mapped onto the user-configurable Win32 color schemes that have been there since the beginning? Did Microsoft break it in Windows 11?
> A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
The "good news" about this tool is that it is partly for making it easier to use WinUI3 from Electron, so that you can have both large distributions at the same time.
I thought they had solved the worst problem with WinUI2, a bit like the compatibility library in Android, so you only had to bundle the more "volatile" bits while still delegating most things to the OS.
But then they went and threw all that out the windows (pun intended) with WinUI3 which even has its own separate implementation of DirectWrite for some god forsaken reason.
Unlike the DirectX redistributables of old it's not even backwards compatible so you can't tell people "just download the WinAppSDK runtime", they have to install the specific version you used when developing your app.
You get that download "for free" if you use a .appx, but with a regular installer you're on your own. Even the way apps link to the WindowsAppSDK is a mess with a weird bootstrapping process.
Not worth the headache.
That reason I sort of understand: The Cold War that DirectX can't be bothered to support WinRT directly is fascinating from outside, and also just really, really stupid. DirectX is ancient COM. WinRT is essentially modern COM 3.0. But if DirectX supported WinRT's version of COM then "Oh No, those idiot and dirty C# and JS developers could use it directly" and where would the games industry be without excuses to force college graduates to use only the one true C++ like Stroustrup intended? /facepalm
For a library called DirectX they seem to really love being IndirectX. Someone in the Windows Division should have forced them onto the right path sooner, but Windows is too busy being in either the Azure or AI divisions these days to actually care about being a consistent OS and DirectX slipped into being protected by Xbox in ways that are backwards to how things were meant to work. (Xbox was supposed to be the way to encourage more software developed with DirectX not to protect more software developers from using DirectX directly.) That xkcd comic of Microsoft being a bunch of disconnected orgs in a Mexican standoff seems to apply here (directly).
I wonder what would be cutoff age for readers to read it correctly, I guess under 30 read it correctly, and over 40 will many read it as Winamp
I am 17 and I wasn't wearing my glasses and I was really speaking winamp until I read your comment then scrolled back again to realize it was winapp
My bet is that I spend time on HN so I knew what winamp is in more detail but if say friends my age read it & say they use tiktok more, I would say that they wouldn't call it winamp but winapp
So I guess I might be one of the few exceptions but I feel like people on HN are much more likely to read it as winamp than not & age might not be thaaat big of an impact (atleast on HN)
I reckon that the majority of the HN audience is into older (perhaps more graceful) working technology despite all the fanfare that newer, shinier stuff garners.
Couple of months ago I used some shady C# SDK to build an implementation that interfaces with a very specific hardware component. My only option was Windows Forms, which I don't love very much but I have worked with extensibility in the past.
I did not have a lot of faith, because of how weird it feels to ask an LLM to work with a design.cs file, but what I did was just sketch all the design and let Claude do the logic with certain specification on how I wanted to corral the code... App was flawless in about 2 days of work. It's in production now with zero faults.
So, hard to now give this a shot, I already got my go-to tool. Even for something has arcane and obscure as Winforms.
(ex windows dev)