Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
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.
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.
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
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.
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.
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..
What a laugh, do you want the examples on Apple's side?
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.
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,....
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.
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.
Is a fantasy you invented to argue against.
Microsoft’s 1st party offerings are an embarrassment.
Apples first party offering isnt amazing either; it’s just “ok”; but its not a total embarrassment.
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.
Option 1: spend double the effort, embrace Apple's UI
Option 2: do it once, ship faster, make more money.
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.
This experience put a major dent in my perception of the "Apple has the most intuitive UI" narrative.
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.
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
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.
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
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.
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.
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.
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.
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.
Why change what works fine? Maybe that's the definition of being too old, can't be bothered to change to new things.
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.
Neither are SwiftUI and AppKity.
But for sure they used WineLib.
This comment written before Tahoe
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.
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.
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.