The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer instead of the design system layer. WinForms, WPF, UWP, WinUI -- each one a new framework, each one eventually abandoned.
Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
> The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer
I really don't think that's the fundamental issue.
TFA points out, and I agree, that the fundamental issue is political: competing teams across different divisions coming up with different solutions to solve the same problem that are then all released and pushed in a confusing mishmash of messages.
I haven't written a line of code for a Windows desktop app or extension since early 2014, when the picture was already extremely confusing. I have no idea where I'd begin now.
My choice seems to be either a third party option (like Electron, which is an abomination for a "native" Windows app), or something from Microsoft that feels like it's already deprecated (in rhetoric if not in actuality).
It's a million miles from the in the box development experience of even the late zero years where the correct and current approach was still readily apparent and everything you needed to move forward with development was available from the moment you opened Visual Studio.
There's just so much friction nowadays, starting with the mental load of figuring out the most acceptable/least annoying/most likely still to be supported in 5 - 10 years tech to use for solving the problem.
Honestly, things like Electron are quite literally the problem!
All of people’s modern desktop woes begin and end at the browser. Here’s why: the late 2010’s push into the cloud made JavaScript all-the-rage. A language the creator made in pretty much a weekend coding session.
There naturally is major business incentives powering this. SaaS made things MUCH easier for delivering software.
Fast forward 15 years and MSFT is full in on TypeScript. It’s a disease that starts with MsOffice and percolates to the whole OS (same as what’s happening in copilot).
.Net is actually elegant in many ways. You have PowerShell, VB .Net, C#, F# etc. languages of many paradigms all targeting the same bytecode (and supported by the OS).
And this is being replace by a fun little JavaScript thingy.
That may be how JavaScript started, but unless your claim is that JavaScript hasn't changed at all in the thirty years or so since then, your argument is a complete non-sequitur.
Yeah, thank you. Also, JavaScript today means TypeScript—an arguably extremely capable type system actively developed by Microsoft—and several, modern runtimes with a big standard library and solid asynchronous primitives. There are a lot worse scripting languages out there.
Folks misunderstand the whole point just because I mention TypeScript. Sure it’s a capable and elegant language. Doesn’t change the fact that it’s a bloated monstrosity on the desktop.
Think about it: it transpiles to JavaScript. Even if it’s the most elegant language in the world doesn’t change the fact that it’s a world of bloat.
Stacks on stacks on stacks. And yet people are complaining about .Net? Come on. Lol
Transpilation and bloat are orthogonal. Javascript being bloated or not is also a relative: consider Python, which is much slower than js, and much more memory hungry.
To further argue your original point: chrome & electron are the only reason desktop is still around, both Microsoft and Apple tried their very hardest to build a walled garden of GUI frameworks, rejecting the very idea of compatibility, good design, and ease of use, until they were surpassed by the web, and particularly Google, showing that delivering functioning applications to a computer does not require gigantic widget libraries, outdated looks or complicated downloads & install processes, but is in fact nothing more than a bit of standardization and a couple MBs of text.
All this electron & web hate is so incredibly misplaced I don't even know where to begin. Have you tried making a cross platform mac/win native app? I have, its like being catapulted into the stone age, but you're asked to build a skyscraper.
Why would transpiling change anything? C++ was once transpiled into C. I appreciate that you personally think JavaScript is poorly designed (I mostly agree!) but that doesn't mean it's slow. V8 can do miracles nowadays.
The deeper problem is that all these layers are still in use somewhere within Windows. Try to give your Ethernetcard a fixed IP Address for example. On your way to the correct setting (which has visually looked that way when I was still going to school) you will move through maybe 3 or 4 layers of UI paradigms like a freaking media archeologist. Each of the newer layers dumbed things down and kept the old thing as a fallback.
Meanwhile in MacOS they dumb things down without a fallback.
The only people who appear to make serious attempts at improving the usability of computers are the likes of KDE and other Linux desktop environments. It used to be the way that Linux was the thing you used despite its shortcomings compared to commercial OSs..
I mean Cocoa and SwiftUI are more consistent in the sense that a lot of stuff automatically adapts when Apple changes styling. And they certainly have less churn and more focus compared to Microsoft.
Basically it's been Objective-C and Cocoa since around 2000, later on Swift and then also SwiftUI. That's not too bad for 25 years.
And in contrast to MS, you didn't get abandoned when you were sticking to the official frameworks. Quite contrary, you basically got the switches from PowerPC to x86 to ARM almost for free for example.
Apple is not perfect by any means, but in this regard I truly think they are ahead of Microsoft.
Sure, if we ignore the stuff and bugs they still have, the missing features in SwiftUI and performance regressions, or the iPhonisms brought to macOS with Catalyst.
The reboot of frameworks based in OpenGL with the Metal rewrite.
And many other things I am not bothering with since all those OS System N releases, A/UX UI framework, Teligent based documents,....
If Apple products are so compelling why are so many devs using Electron, React Native and Flutter on macOS, to the point it deserved being mentioned at WWDC 2025 State of the Nation Keynote?
My point was don't throw stones when having a big glass roof as well.
Apple isn't the perfection you make out to be, also has a rich history of failures, and only did not went bankrupt due to sheer luck of doing the right decision when there were not many remaining to take.
That's a different issue. Things like Electron are popular not because native development is buggy, but because most developers these days are web developers. They know Javascript. They've never written anything in C/C++ or even the slightly friendlier Swift, Rust, or Go. Electron lets people who only know the Web make desktop apps.
> If Apple products are so compelling why are so many devs using Electron, React Native and Flutter on macOS
That is not how the decision making for cross-platform works. You choose those alternatives knowing that they are crap in many respects, yet accept the trade offs because you want to save money on dev hours.
That’s not the point being argued either, nor it being perfect. It’s just about Apple’s UI frameworks being more coherent and consistent across all their own platforms, unlike Microsoft. Even Android developers who’ve done a bit of work on iOS easily agree that Apple’s SDKs are far better designed and behave more predictably than Google’s.
This one caught me completely off guard when opening YouTube the first time on an iPad: Accidentally clicked on a wrong button and got stuck in a "please subscribe to premium" modal. No amount of swiping or tapping outside the popup would help, only thing left was killing the entire app.
This experience put a major dent in my perception of the "Apple has the most intuitive UI" narrative.
The YouTube app has non-standard and nonsensical UX on every platform. It's Google's fault, nothing to do with Apple.
Case in point: The YouTube app for Apple TV. Everything (pausing, playing, changing subtitles) has been done opposite to the standard player found in every other app. You cannot use the main button to pause and resume, for example. Recently they broke swiping. Normally, you swipe the remote to navigate between UI elements such as squares in a grid or in lists with a light touch. It's very fluid, like a touch screen. But the YT app has added severe "inertia" to touch gestures, and you now have to "fling" your finger on the remote trackpad to navigate. Everything feels syrupy and stuck.
YouTube and Amazon's Prime TV app are the two worst apps I've ever used on Apple TV. I believe they both use some non-native UI toolkit that doesn't respect native OS conventions and doesn't even try to. Pretty incredible given the size and budgets of these companies.
The YouTube app does the exact same thing on Android. I ran into this just yesterday on my gf's phone, as I'd just added her to my family plan, tried to verify the settings on her phone, and it trapped me on an upsell screen for YT Premium that I had to kill the app to get out of.
Maybe just the circles I run in but these are not evergreen questions in my experience. I don't even know what "go back" is supposed to mean here, or for that matter what it would mean in a Windows application. Is there a system level "go back" in WinAmp/Excel/SimCity/Photoshop I've never seen before?
In iOS, task manager and closure can't be overridden. You swipe right to return to previous application. You can swipe left for a couple of seconds if you didn't intend to do that.
You swipe up and remove the application from the stack, all processes of the application is killed.
Background processing has strict limits, and you need permissions to run longer than that, and for some use cases, there are no recourse. OS swaps you out or freezes the app.
If you want an app to work in the background, don't kill it, period. Push notifications are handled by the OS and is not hindered by this.
I'm not using Reddit in any capacity since they have started giving their content for LLM training, so I can't help you with that, but looking at 4-5 third party applications right now, they all have a left arrow at top left to go back.
They all are very different applications and have very different designs, yet the arrow is there.
To be honest, I baffled at your question for a second or so, because I never thought about that, yet the method is so universal that I was not thinking about it at all.
I feel that some people are just too old to get used to the swipe based ui. I mean friends of mine who just keep buying the only phones with (screen based) back and home buttons.
It's not just that you need to get used to gestures, it's that they are not discoverable at all, and that they can be awkward to perform with mobility issues, old hands, short fingers, etc. It's easy to make the wrong gesture, eg. the phone detects a swipe down instead of left to right, more so if you are holding it in one hand, so it's finicky and frustrating to have to rely on it as the only way of doing a common action. Why is it so wrong to have a simple navigation bar, it doesn't take up any more space than the hideous notch at the top?
It's not "getting used to", I feel like that gesture is less practical. It involves or using the "circle" to assist on how to use the gesture (creating a black void on the screen that you need to plan your use of the phone around) or having the swipe that 1) is not as reliable in my opinion and 2) can be triggered accidentally
For me is like claiming that touch screens on cars are the future and people are too old to get used to it.
Maybe saying "too old" is disrespectful indeed, what I meant was more that my kids grow up with swiping everywhere but we grew up with (hardware, then touchscreen) buttons and the older we get the harder it is to get used to new use paradigms.
Swipes are of course nice because they allow for the same interactions without taking any screen real-estate. And I have to say it quite consistent across the iOS apps I use.
I could get used to touch gestures if they were more consistent and tolerant enough for wrong inputs. It may work in one app but not another. One app expects me to swipe from left to right to go back, another wants me to swipe from top to bottom for the same thing. It may mark an email as unread if I start the swipe a pixel too far away from the screen edge. On Android swipe gestures may vary even on different phones from the same brand.
In iOS, tapping the top edge of the screen means scroll to the top. Except in the Photo app, where it means "scroll to the top of the current section, or almost the top, or do nothing and make the user guess if they just tapped the wrong way".
Meanwhile when there's an X button or arrow to the left I always know what it's going to do aside from one or two overly creative Android apps.
I feel that some people are just forgetting what the reason it's easy for them is because they learned that "swipe based UI" ages ago.
When I get handed iPhone I have no clue on how to even open an additional tab in Safari and any finger gestures do not do the things what I expect nor there is a lick of indication on how to do something. It's all just a memorized magical incantations at this point. But hey you are familiar with them so it's easy to bash on everyone who is not in yours eco-system.
Is that what's going on? So many touch gestures seem to rely on landing in the right 2mm diameter area, but the minimum reliable resolution for touch seems to be a 4mm diameter circle. It's even worse for my father, even though cognitively, he would have no trouble understanding the hypothetical requirement. It's also noticeably worse during the depths of winter.
Hmm, would explain that frustrated pokey interaction I see elder people often throw at touchscreens... you know, chin up, peering down through their reading glasses, going for a 4th, 5th try at something...
You can't just take 40 years of Win32 apps and add the Metro design language, touchscreen compatibility, or dark mode system-wide. WPF nowadays has a skin that imitates WinUI, so at least Microsoft is trying.
WinForms is a layer built on top of raw Win32. So it's not portable.
Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.
True, but: Microsoft haven't made a better UI framework that's portable to Windows yet. Everything after WPF has near zero adoption, including (critically important!) by Microsoft itself.
Mono used to have libwine embedded. You know, libwine exists as a library running and compiling Win32 natively under Unix. Instead of PE binaries you would run ELF Linux ones, but with nearly the same outcome.
Every time I tried following alone with the winelib/winemaker documentation, I always ended up with an ELF that had to be invoked using "wine" to run. Nothing that could self-load any of the wine dependencies.
Snide and subjective comments aside, you’ve clearly missed their point.
Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board.
Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time.
The size and losition of the traffic lights control is not dependent of the os the app runs on but on the os the app was compiled on. So things are not updated across the board
It’s still dependent on the OS it runs on AND the SDK it compiles against (not the OS it was was compiled on).
But that is legacy bridging behaviour, and is not compiled into the app. Apple can and do change those with time.
For example apps that compile against macOS 15 are not opted into Liquid Glass when run on macOS 26 but will be once on macOS 27 according to their transition docs.
I don’t think Microsoft’s approach to perpetually support old apps is unequivocally a good thing. It seems to be getting them into a deeper and deeper mess over time.
As a consumer I prefer Apples approach. If I were an industrial customer relying on old software to operate my machines i would prefer Microsoft’s approach.
Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.