Winapp, the Windows App Development CLI

Posted by MaysonL 6 days ago

Comments

Comment by pjmlp 16 hours ago

I already mentioned in a few places, this is useless, probably a team having to meet some KPIs, OKRs, or whatever to show their impact value on the next evaluation cycle.

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.

Comment by irrlichthn 15 hours ago

Sounds very negative, but I can confirm - it's the truth unfortunately.

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.

Comment by pjmlp 15 hours ago

It is what happens when passionate advocates feel betrayed by all the mismanagement that has happened since Windows 8.

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.

Comment by ruicraveiro 15 hours ago

I jumped the train when they crashed the Silverlight carriage.

Comment by embedding-shape 15 hours ago

Not to mention, the code is quite obviously vibeslop...

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...

Comment by mycall 14 hours ago

I think when people heard that Claude Code is now writing itself, they thought "we could do that" and this is their attempt at it. Different people, different results.

Comment by tracker1 11 hours ago

I made a small suggeestion in VS Code's Github repo.. it got assigned to a GH Copilot bot, that did the implementation, manually added a couple weeks later and now in release... I was a bit impressed, but then started looking at some of the configs and workflows for .githug, it's impressive but I can't help but think, what a pain to setup/configure.

Comment by embedding-shape 14 hours ago

> when people heard that Claude Code is now writing itself

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.

Comment by philistine 13 hours ago

So you're saying that Winapp doesn't kick the llamas' ass?

Comment by tracker1 11 hours ago

I read it as Winamp myself at first pass. I don't care as much for the UI today, but really did like their Android app, and am sad it's no longer available. One of the better audio apps I'd tried on Android.

Comment by sandos 13 hours ago

I have no clue about GUI programming, but I eventually came to the conclusion to use Avalonia after even my LLM told me to do it.

Comment by tracker1 11 hours ago

If you're using C# this is pretty much your best bet IMO... I think MS really missed the boat by not having a Linux target for MAUI, even if it was just passthrough to GTK (Or Qt).

Comment by vjvjvjvjghv 16 hours ago

I don’t rally understand what what they are thinking but it seems MS has given up on windows desktop dev. Even Office is now moving to web technology even if it means to make these apps worse.

Comment by WorldMaker 9 hours ago

One of the many things this tool claims to be for is better automation of Electron and React Native integration. It seems like a tool designed for web stack developers that don't want to touch Visual Studio.

Comment by mycall 14 hours ago

Besides Visual Studio (WPF), much of Office 365 (or whatever they renamed it to) is using either React Native (MS edition) or Electron (Web Tech) so their latest code is a mixed bag.

Comment by tracker1 11 hours ago

Works for me, since I can use it in a browser in Linux... Though some of the new features really tick me off.

Comment by voldacar 15 hours ago

What's the best way to get into MFC or Win32 in current year? Is there a canonically best book or tutorial for those wanting to learn?

Comment by pjmlp 15 hours ago

Same as always, get one of the old books, the good ones back in the day.

Programming Windows, by Charles Petzold

Programming Windows with MFC, by Jeff Prosise

COM / DCOM Primer Plus, by Chris Corry Vincent Mayfield John Cadman

Comment by voldacar 12 hours ago

Thank you! Despite being older than me, those books look really thorough and well written. It's sort of crazy that these APIs are still as usable today as they were in 1998

Comment by kumrayu 15 hours ago

What are Microsoft's own Office Apps built on?

Comment by pjmlp 15 hours ago

Their own custom framework built on top of Win32, nowadays they also use React Native, and Webview2 with React to share code with the Web versions.

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.

Comment by kumrayu 15 hours ago

Building apps on Windows feels like a big PITA to get into. The amount of different frameworks and libraries to work with is perplexing to a new developer and I really do not want to use electron or React or even Qt.

Where do I start? Do you have a compiled version of some information on this?

Comment by pjmlp 14 hours ago

You start by using the Qt installer, and installing QtStudio alongside mingw, hardly that complicated for anyone that has ever done C or C++ development.

Since I know those languages since 1992, and have coded for Windows since Windows 3.0, I never bothered with any guide personally.

Comment by Manfred 14 hours ago

Even following their own "getting started" tutorials you get stuck at step one trying to find Visual Studio or whatever it's called nowadays.

Comment by bitwize 14 hours ago

Oh, you mean Visual Studio 2026 Copilot App 365 & Knuckles?

Comment by mycall 14 hours ago

> Where do I start?

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...

Comment by bob1029 13 hours ago

Raw win32 isn't actually that bad now that we have LLMs. I don't even use the cswin32 project anymore because chatgpt is good enough today. I think win32 from modern C#/.NET is a very happy blend when you need that low level access.

Comment by TheAceOfHearts 15 hours ago

Looking back on the history of Windows, one of the things that most stands out to me as a user is the utterly insane UX around the C++ redistributable. They really should've figured out a better solution than having every single application ship their own copy along with a separate installer, and then having the installer run always because the developer cannot be sure if it's installed correctly. As I understand it, this might still be a problem with the latest version? If someone like Steve Jobs had been responsible for Windows he would've fought with managers, lawyers, and engineers until the problem was resolved.

Comment by whywhywhywhy 11 hours ago

This is absolutely baffling that you can't just make an api request and windows deals with installing those redistributables, must have seen that installer pop up close to 80 times in my life. I understand why maybe it was that way pre-internet but really they should have rolled it into windows and made it automatic by now if their dev tools team and windows team can't figure out how to just compile software on their own OS without shipping another bundle beside it.

Comment by pjc50 12 hours ago

The newer .msix apps are supposed to be able to handle this, and WinUI3 is supposed to come with a package-dependency that uses the package system to automatically make sure you have the 100+MB library up to date. However, this is the new cool system that nobody uses and doesn't help ordinary devs. They should just ship it in the OS.

Comment by pjmlp 10 hours ago

And has lots of interesting bugs to explore, depending if the application uses only C++, only C#, a mixture of both, is packaged or expanded, ships the language runtimes along the MSIX, or depends on the store for dependencies,...

Yet another opportunity to submit a few issues on the repos.

Comment by delta_p_delta_x 14 hours ago

> the utterly insane UX around the C++ redistributable

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.

Comment by whywhywhywhy 11 hours ago

> means that applications can be written on modern Windows that targets much older Windows

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.

Comment by bossyTeacher 13 hours ago

> Anything related to WinUI, WinAppSDK, CsWinRT, C++/WinRT is a sea of bugs, broken tooling, and unfulfilled promises, that no one should bother with.

Can you add MAUI to this list? Please and thank you.

Comment by pjmlp 12 hours ago

Sure, I keep forgeting it even exists.

Comment by actionfromafar 16 hours ago

Or just plain Win32, no wrappers! Maybe with coding agents it can have a renaissance.

Comment by delta_p_delta_x 15 hours ago

> plain Win32

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.

[1]: https://github.com/microsoft/wil

Comment by pjmlp 15 hours ago

As side note, WIL was originally introduced for writing drivers in C++ in kernel mode, then expanded to support other workloads on userspace.

Here is the original announcement,

https://community.osr.com/t/the-new-wil-library-for-c-code-i...

Comment by pjc50 15 hours ago

Annoyingly many of the new features are WinRT only, so you have to deal with that horror.

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.

Comment by pjmlp 15 hours ago

Only AI stuff, there is hardly anything else that depends on WinUI/WinAppSDK.

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.

Comment by pjc50 15 hours ago

Even if you do that, and carefully work in "points" internally rather than pixels, the results seem to be bad. Win32 dialogs are generally not resizable or "responsive". This is even visible in settings dialogs from Windows itself.

Comment by pjmlp 15 hours ago

Still much better than dealing with WinRT, and its "ATL is great!" attitude, with the endless amount of bugs that never get fixed.

Comment by tcfhgj 15 hours ago

I have been using WinRT and Win32, and I find WinRT much more pleasant to use

Comment by pjmlp 15 hours ago

Until you will bump into one of those bugs that have been open since Project Reunion was announced.

Comment by asah 17 hours ago

But does it whip the llama's ass ?

Comment by reddalo 17 hours ago

At first I was like... what does Winamp have to do with apps development?

Comment by martijnvds 17 hours ago

Llamas are hot again.

Comment by embedding-shape 15 hours ago

Well, was. Then Facebook AI made a side-step, and stopped focusing on downloadable LLM models, and Ollama is now trying to squeeze their users so they can show profits. r/LocalLlama is also a former shadow of itself, with the top moderator trying to move the community off reddit.

Seems Llamas will disappear as quickly as they became trendy.

Comment by mhitza 17 hours ago

They must be either incapable of binging for matching names, or its a sneaky strategy to bury, by influence, the existing winapps project https://github.com/Fmstrat/winapps

Comment by pjc50 16 hours ago

Microsoft are incapable of naming things. This is the "Xbox one series X" of desktop development.

Comment by anonymous908213 17 hours ago

I don't honestly think it's unreasonable to ignore third-party projects that are polluting your own namespace, so to speak.

Comment by 1718627440 16 hours ago

Their own namespace starts with "Microsoft ...".

Comment by anonymous908213 16 hours ago

By this logic the Linux WinApps namespace starts with fmstrat and there's no namespace conflict.

Comment by 1718627440 15 hours ago

I am talking about the namespaces of terms in natural languages, not about some random website answering on github.com .

Comment by anonymous908213 15 hours ago

If you're talking about "namespaces in terms of natural languages", it's obvious that "Windows" and the shorthand "Win" are their own namespace, eg. Win32, WinUI, WinRT, and that the developer of Windows has every right to consider it their own namespace?

Comment by pseufaux 16 hours ago

I read though the GitHub readme but I'm still unsure what "new" this brings this brings to the table. It seems like a thin wrapper over existing tools. Since Microsoft rarely deprecates and removes anything, this feels like just another unnecessary complexity layer.

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?

Comment by pjc50 15 hours ago

It is, but it's like "dotnet new" templates: a means of getting to a working minimal setup that jumps through the Microsoft hoops for you. MSIX and Package Identity are definitely headaches to get set up.

Comment by ripley12 14 hours ago

Yes, Package Identity was the bane of my existence for a while. It's wild how MS gated important APIs behind it and then made it so difficult+impractical to work with (I honestly think this is a large part of why WinRT was mostly ignored by developers).

I've moved on, but this looks like it will at least fix some of the paper cuts.

Comment by WorldMaker 9 hours ago

It's a CLI for especially web developers that prefer CLI tools over graphical installers and needing to have big IDEs installed like Visual Studio.

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.

Comment by sirwhinesalot 15 hours ago

For those unaware, the current recommended way to develop "native" apps for Windows is to use WinUI3, distributed with the WindowsAppSDK.

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.

Comment by WorldMaker 9 hours ago

WindowsAppSDK (and its direct predecessor) was installed only by the OS in Windows 8 and early Windows 10 and everybody hated the OS updating it and needing to know things like which specific Windows 10 update a user was on to access features. It's a mess either way it is installed.

> 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.

Comment by sirwhinesalot 6 hours ago

I remember the problems with the WinRT APIs being tied to specific Windows versions (still are, just a smaller surface area, so less of an issue). With the old service pack model it wouldn't be an issue but with constant OS releases it was too much churn.

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.

Comment by WorldMaker 1 hour ago

> own separate implementation of DirectWrite for some god forsaken reason.

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).

Comment by ptx 14 hours ago

> Win32 with no dark theme

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?

Comment by sirwhinesalot 14 hours ago

If you use classic unstyled Win32 controls (Windows 95-2000 style) then you can do that. If you use uxthemed Win32 controls (Windows XP onwards) then there's no official dark theme support.

Comment by jxdxbx 7 hours ago

WebView on Windows is pretty good, and Chromium-based, so I think that something like Tauri is preferable to Electron.

Comment by ludovicianul 17 hours ago

It's the second time I see it on HN and read Winamp.

Comment by Markoff 17 hours ago

obvious mistake, same here

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

Comment by sh3rl0ck 13 hours ago

I'm 20 and I read Winamp, ha.

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.

Comment by Imustaskforhelp 16 hours ago

> 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)

Comment by dd_xplore 17 hours ago

I think this uses dockur to run the windows VM. That's also an awesome project.

Comment by lostmsu 12 hours ago

Looks interesting, but no mention of GPU acceleration

Comment by pelagicAustral 16 hours ago

I'm already sold to Claude Code for Windows Desktop development.

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.

Comment by catapart 16 hours ago

this looks very plainly like "oh shit, devs are having a really hard time actually integrating with our AI services! That must be the only reason we are seeing adoption so slow. quick - throw a wrapper around some boostrappers that can get a green field project prepared for integration with our AI services (and whatever else can be done when you get that set up)."

Comment by codeulike 17 hours ago

Great, thats not going to get confused with "Windows App" which is the new confusing and impossible to google name for Remote Desktop

Comment by pseidemann 16 hours ago

How is such a product decision even possible? Genuinely curious.

Comment by pixelpoet 16 hours ago

Ask the marketing department that destroyed one of the most famous brands on earth, MS Office, and renamed it to "Microsoft Copilot 365 app": https://office.com

Comment by luckman212 16 hours ago

This is so bad it doesn't even seem humanly possible. Maybe this decision was made by Copilot itself.

Comment by pixelpoet 16 hours ago

One could say the error was [puts on shades]... unprompted.

Comment by tomaytotomato 16 hours ago

https://youtu.be/DA1-haV0qWU

Comment by cobolexpert 16 hours ago

Copilot wanting to name everything Copilot is a funny thought, for some reason.

Comment by copilot_king 16 hours ago

This isn't true. Copilot is AGI.

Comment by 16 hours ago

Comment by a_rahmanshah 17 hours ago

Or Winamp. I read it couple of times before I noticed it is not Winamp.

Comment by imathew 17 hours ago

Winapp, it really whips the LLMas ass

Comment by rootnod3 16 hours ago

God damnit...that definitely deserves the upvote.

Comment by sgt 16 hours ago

@dang can't we have a feature on HN where you vote a comment into the "hall of fame" or such?

Comment by dang 9 hours ago

For now you have to email us to add a comment to https://news.ycombinator.com/highlights. Eventually yes, we want to make this more built-in.

Comment by tracker1 11 hours ago

+100 ... We definitely need a "super upvote" that you can use say 100 pts of karma to give to a comment.

Comment by nacozarina 17 hours ago

baaa BAAA-aaaaa

Comment by Markoff 17 hours ago

I just realized it now after reading your comment, I opened first comments to find out what's new about Winamp before opening the site

Comment by ivanjermakov 17 hours ago

Windows App is the biggest naming blunder in history. Impossible to find relevant information.

Comment by einr 16 hours ago

It's perfectly clear: if you need to run a Windows app on another Windows PC, you just open the Windows app store on your Windows PC to download the Windows app Windows App, a Windows app that lets you connect to and run Windows apps on other Windows PCs.

Comment by creamyhorror 15 hours ago

Windows PC? I think you mean "Windows app host" (once we all move to thin clients due to consumer PCs becoming unaffordable)

Comment by ttoinou 16 hours ago

I develop C++ software for Windows and couldn’t understand the point of this

Comment by pjmlp 16 hours ago

Nevermind, this was probably a team meeting some KPIs to show value, this is useless.

Comment by lloydatkinson 17 hours ago

I read a Reddit comment on the thread for this where they suggested this was only made because of the old "windev vs devdiv" rivalry.

Comment by dgxyz 17 hours ago

If their stack wasn't so fucked up it wouldn't need this wrapper.

(ex windows dev)

Comment by reddalo 5 hours ago

I miss Win32 APIs.

Comment by holoduke 15 hours ago

Why am I reading winamp. Took me a minute to figure out.

Comment by grougnax 16 hours ago

Once again, a useless, bug-ridden, layer of complexity by Microsoft on an already messy stack. What could possibly go wrong?

Comment by nalekberov 17 hours ago

Seriously, bring Winamp back! It will really whip the Llama’s ass.

Comment by Markoff 17 hours ago

Winapp, NOT Winamp!