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.
Doesn’t matter how it changed if every desktop app ships its own browser.
Remember we’re talking about GUIs. Typescript is great for the browser but it should stay there.
Now, JavaScript can be okay for example: Qt Quick/QML it works quite well in the desktop. But that’s purpose-built scripting.
Being a 70's child, in computing since the mid 80s you made me almost spill my Monday coffee.
What a laugh, do you want the examples on Apple's side?
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,....
Come on, you think SwiftUI has more bugs than the ten different Microsoft frameworks?
There are just more people encountering them because the developers are concentrated on using one thing.
It’s not perfect, but a compared to Microsoft, calling Apple out for having bugs is a little rich isn't it?
I pose to you, if the Microsoft offerings are so compelling, why are the serious players using 3rd party wrappers like QT and Avalonia?
It’s because the first party offerings are not compelling. They’re a disaster dumpster fire. And buggy.
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.
Nope, it is the same issue now being worded around to sell the Apple is shiny story above.
> 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.
The whole point was the greatness of Apple platform.
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.
They use React Native and Flutter because they want to target more than just MacOS/iOS
Meaning they don't worship Apple UIs as the ultimate design?
It's about the tradeoff.
Option 1: spend double the effort, embrace Apple's UI
Option 2: do it once, ship faster, make more money.
Nobody in this thread is claiming Apple is perfect, just ahead of MS in UI consistency and _less_ buggy
"Ahead" with yes but attitude.
None of the UI frameworks is perfect. Neither the ones from Microsoft, nor the ones from Apple, nor Qt, nor GTK (lol...), nor the web-based ones.
I'm just saying that in my personal opinion and experience, the ones from Apple have the best yay-to-wtf ratio. Your mileage may vary.
The evergreen question of "how do you go back and/or close an app on IOS?"
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.
How is bad UX in the YouTube app Apple's fault? You can mess up Android's back button as well.
Because Apple does not enforce uniformity
If Ah, yes, problems with the UI on the OS which for 99% consists of modals is not the OS vendor problem, noted.
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?
I was referring to IOS, not MACOS
Androids do have universal back button at the bottom on the phone or the same swipe gesture if you want but iphones do not.
Sometimes swipe (the direction and position is a guessing game), sometimes and x (right or left ) and the behavior is inconsistent too (back or close)
There are some guidelines but more often than not seems like every app has it's own method and you need to get used to it
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.
What about going "back" INSIDE an application?
Think for example reddit, you open a thread, how do you go back?
You open the "reply window, now ho you ho back? Maybe close it directly?
I Android this is all handled by the same function and is often ranked as the most frustrating design choice in IOS
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.
There is a common way to go back (swipe from the left edge of the screen). Some apps just don't integrate well and ignore the platform patterns.
I believe swiping from left to right is common for both Android and iOS.
Android has both a swipe gesture or a widget that simulates buttons that used to be at the bottom of the screen
...and iOS has both an arrow at the top left and a swipe gesture. I can't see how they are that different.
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?
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.
It's not just mental, as you age you lose moisture in your skin and with that accuracy with touch devices.
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...
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.
Android has an option to enable these buttons on a toolbar at the bottom, I always turn it on.
Why change what works fine? Maybe that's the definition of being too old, can't be bothered to change to new things.
I'm in that group.
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 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.
It's still easier than Windows CE though.
You swipe backward. Been that way for twenty years.
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.
Sure, but you could have had a uniform design language for the last 3 or so frameworks.
Right, but you can make basic adjustments to the theme to fit the rest of the system better, which took them all the way until Windows 11 to realize.
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 agree. Except that WinForms has not been abandoned. In fact, it's one of the supported paths in the modern .NET stack.
It lacks hardware acceleration.
Does it need it?
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.
>WinForms is a layer built on top of raw Win32. So it's not portable.
Neither are SwiftUI and AppKity.
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.
Mono supported WinForms. But IDK how did they integrate it with the CIL.
But for sure they used WineLib.
> Apple solved this
This comment written before Tahoe
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
This is incorrect.
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.
That doesn’t really negate the OPs point.
I found this out when I tried running an old app I compiled on MacOS several years ago, it still has the old title bar gradient and traffic light.
That's a bad thing. It breaks apps. Apple has decided to stop supporting apps that aren't continually updated. Microsoft hasn't.
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.
Insightful comment