> look native to the OS
Is that a problem? A button with a legible label is a button. The host OS doesn't have to look exactly like the applications it runs.
> look native to the OS
Is that a problem? A button with a legible label is a button. The host OS doesn't have to look exactly like the applications it runs.
Consistency is a large factor in any good design, UI design more so.
They have internal consistency. The iOS version looks like the macos version which looks like the web version, etc.
This upsets HN users but the rest of the world decided that apps looking like windows built ins doesn't matter.
It's more like developers decided - nobody asked the users.
ironically the only group of users I've found that actually care about native UI, are other developers and Mac purist.
I have seen users having trouble with pixel soup UIs. They may not think "This should be in a native toolkit", but they do think "How the hell do I subscribe to a folder in the new Outlook?".
Right, but bad UI's was not uncommon before webviews, if anything the spartan-ness of the web often simpified patterns whilst reliance on weird hotkeys in desktop apps isn't uncommon.
>reliance on weird hotkeys in desktop apps isn't uncommon
The only examples I can think of are actions that are intentionally not easy to reach. How exactly it's done is platform-specific, but the (mis)feature doesn't come from the platform and can be implemented in other ways on other platforms.
- Apple UIs hide some power user functionality behind obscure hotkeys
- Similar: Shift-Delete to permanently delete (Windows, KDE) - Similar: Shift-right click to "Open With..." (Windows, KDE)
- In desktop apps that FOR SOME REASON try to look more like web apps, the hidden menu bar can be restored with Alt or Alt-M (Firefox, KDE)
The problem in these usability cases is pretty much always layout and constant redesigns rather than the exact theme the button has. I've seen plenty of unusable native ui soup UIs and very clean and simple custom UIs.
You could call it the exact theme when a clickable UI element looks just like regular text (it was not inside any kind of button-like shape in the Outlook case that I saw), but it's super common to have that in web-based UIs.
(And of course, nobody changed any theme in the outlook case)
> ironically the only group of users I've found that actually care about native UI, are other developers and Mac purist.
One group of people who routinely carry the can for poor product usability and another who by definition care about the Mac platform; entirely what would be expected.
Consistent like what? Like maybe a decade ago one could say that osx was consistent, but nowadays even SwiftUI and cocoa is visibly different, let alone every second app that uses electron. And people don't care.
Windows has like 4 frameworks available on a bare new, latest OS install, just go deep enough in the "settings" or whatever they call it, and you can reach down to winforms. And on top the start menu is a react element!
(And in Linux you have the gtk and the qt world, and everything else)
> SwiftUI and cocoa is visibly different
Do they render different looking buttons?
OS-level consistency is also consistency. It depends what we value. A lot of apps’ design could’ve been basic, OS-like UI. Apps such as GymBook or WhatsApp are internally consistent while still adopting many elements from the system’s design, instead of reinventing the wheel.
Within OS consistency is much less of thing a thing than Web design conventions. Windows by itself has had several different UI frameworks over the years, so different "native" Windows programs can look completely different from each other.
> Within OS consistency is much less of thing a thing than Web design conventions.
Sorry, are you saying that two random web apps will typically share more UI consistency than two random Windows apps? Because, although I'm not currently familiar with Windows, I would be amazed if that were true.
There are two types of consistency in this context: consistency within an OS and consistency across them. I, too, prefer the first because I only really use one OS, but this preference varies. I don't think it's right to say that the first case = "ui toolkit", but the second case doesn't.
Consistency as a design virtue applies to a single user's experience. This means consistency within the OS.
A foolish consistency with terribly designed shallow superficial desktop user interfaces dreamed up by overpaid cocaine addled corporate boutique brand designers with not only no experience but actual burning contempt for usability and human factors and accessability and affordances is the hobgoblin of little minds.
https://daringfireball.net/2025/12/bad_dye_job
Yes, Dye botched [mac/i/tv/etc]OS 26.
That doesn't say anything about the value of whatever UI kit is in place, being shared consistently by apps. A virtue that, apparent from this thread, is no longer universally shared.
That’s why HN users constantly advocate for Vim, a program in which every single thing works completely differently from every other modern application.
Yes, if there's one lesson from historical UI research that still holds, it's that mode switching is expensive. That's why people install vi plugins everywhere.
Wait...
Vi plugins don’t even exist for the vast majority of applications.
The last resort is to switch to ROU mode (key combo for entering it is :wq)
Consistency is the reason why Electron is great. Consistency of the UI across operating systems.
Great for the developer. The user doesn’t use Mac, Windows and Linux. Just one for work and one at home, with mostly different apps, so they couldn’t care less if it looks the same on different platforms.
They may care, however, if they get anything at all. I do not have the resources to target something to all platforms, so the alternative wouldn't be "Users get UI targeted towards their OS", the alternative would be "Users get nothing since developers don't have the time to also target their system".
> I do not have the resources to target something to all platforms
Some speculate that agentic engineering will enable the return of native apps
> I do not have the resources to target something to all platforms
What resources is actually needed? More often than not it just requires good engineering. You do not have to duplicate everything across platforms.
Time. I have the time to maintain a single GUI. I do not have the time to maintain three GUIs. Of course they'll be 99% the same, but checking that this 1% difference behaves and looks fine accross systems adds a substantial amount of effort that I simply can not support. And for what exacatly? I want them to be identical accross systems, not different.
> And for what exacatly? I want them to be identical accross systems, not different
For your users. Engineering is about designing things for the convenience of the builder, but for the convenience of the user.
If you think operating systems have nothing to offer in terms of UI patterns or guidance, then yes, that's a different type of consistency.