Hacker News Reader

Comment by vsskanth | Hacker News Reader

How is MacOS able to maintain such a consistent UI even with massive changes in their design language ? Is Windows UI not a separate layer or something that they can update ?

Or is it that the UI elements somehow get baked into the program at the time you build it, so if you didn't update you are just stuck with that particular version of UI you built the program ?

View on HN

The biggest thing is that a much larger percentage of Mac apps are written using the native UI toolkits, which receive most of the aesthetic changes for "free" (even in lieu of updates/recompiles). There's also stronger expectation from users for apps to fit in, so even devs who write in foreign toolkits (e.g. electron) are more likely to put in the effort to mimic the native toolkit, because failure to do so makes their app look crusty and outdated relative to the rest of the system and other apps.

Under Windows, the rule has been that basically anything goes, and that's been true for upwards of two decades. Anybody who used Windows 98/2K/XP can probably name several apps they remember using totally custom UI off the top of their heads. That never really changed. Custom UI has become a lot less wild looking, but it's still custom (which means no "free" updates), and on top of that there's no incentive for developers to update their apps to match the latest look.

> Under Windows, the rule has been that basically anything goes

Those rules were set by example by microsoft.

But the programs we are discussing here are parts of windows written by Microsoft with their own toolkits.

macOS isn't afraid to deprecate or completely remove things even if that means old things won't work. Windows demands 16 bit apps from the 90s should have a very decent shot at running on Windows 11. That level of "it'll always be there" means for the vast majority of old UI it has no technology pressure to be redone, only pressure of what most average users will see day to day. E.g. nobody at Windows is going to dump control panel (need 3rd party add-ons to work) and nobody is going to rewrite it in a backwards compatible way when most users can do everything via Settings these days and it works with all quirks for legacy apps as is.

That's not to say a lot of the Metro stuff shouldn't/couldn't be made to be Fluent but it also isn't as out of place as some of the older stuff. The only one that is really surprising is File Explorer - but again a lot of legacy app integration that wouldn't work with a new one (though maybe it is time anyways).

> Windows demands 16 bit apps from the 90s should have a very decent shot at running on Windows 11.

16 bit applications never worked on any 64 bit Windows.

32/64 bit is a compile time option not a separate codebase and unlike macOS they haven't discontinued 32 bit even in the latest versions.

Not natively, but ntvdmx64[0][1] and otvdm[2]/winevdm[3] work fine, albeit a bit slowly.

[0]: http://www.columbia.edu/~em36/ntvdmx64.html

[1]: https://github.com/leecher1337/ntvdmx64

[2]: http://www.columbia.edu/~em36/otvdm.html

[3]: https://github.com/otya128/winevdm

---

For those interested, Wikipedia says there's no native/builtin 64bit NTVDM due to

> In an x86-64 CPU, virtual 8086 mode is available as a sub-mode only in its legacy mode (for running 16- and 32-bit operating systems), not in the native 64-bit long mode.

...

> The NTVDM is not supported on x86-64 editions of Windows,[31] including DOS programs,[32] because NTVDM uses VM86 CPU mode instead of the Local Descriptor Table in order to enable 16‑bits segment required for addressing[33] and AArch64 because Microsoft did not release a full emulator for this incompatible instruction set like it did on previous incompatible architecture.

https://en.wikipedia.org/wiki/Virtual_DOS_machine#Windows_NT...

---

Personally, since Microsoft still releases 32bit builds of Windows 10, I just dual boot 32bit (~48GB)/64bit (~900GB) partitions and run the 16bit programs natively on an old Thinkpad.

I think it relates to how their internal structure is set up and their brand positioning. Apple has only one design team and design system I think, and only caters to folks who prefer simplicity over power features.

I suspect that Windows is more like compilation of what different teams produce at MS, each with their own design opinions and target audience.

I can only imagine how challenging it is to serve beginners and power users with the same UI at the same time in Windows, which kinda implies different UI densities depending on the part of the OS or type of widget.

Apple has the advantage that they get away with simplifying things and have built a brand image around being easy to use.

> macOS only caters to folks who prefer simplicity over power features

This is said quite often, almost as a given, but I never thought it reflected reality. macOS has an abundance of useful features for power users — system services, automator, AppleScript, tons of productivity touches like titlebar proxy icons and universal drag-and-drop support... not to mention it's all built on Unix so a terminal is right there for anything not exposed in the UI.

Sorry I meant the UI, not the "hidden" stuff.

Right, but everything I mentioned exists in the UI. Just not the very last part.

Built-in Windows controls, like buttons, scroll bars, etc. are updated with each system release. However, they are relatively inflexible, and no one uses WinApi anyway, so most frameworks and apps build their own components, with varying dedication to emulating the "native" style. Built-in controls also don't perform much in the way of layout (I believe the only way to position child HWNDs remains manual absolute positions?) so while your button might look native, your collection of two buttons won't.

My guess is MacOS's consistency comes from some combination of developer incentives, and UI toolkit design.

> I believe the only way to position child HWNDs remains manual absolute positions? so while your button might look native, your collection of two buttons won't.

I thought the native APIs provided some kinds of constraints, like ‘these go into corners, and this is next to that’? Such approach is sorta necessary when windows can be resized. And I thought that UI builders like Visual Basic depended on these constraints. However I didn't do much manual UI, so perhaps the programmer indeed has to recalculate everything in pixels when something moves or is resized—like we did back in the day before we knew better.

Which is the "native" API - win32, MFC/ATL, Form builder, WPF, or MAUI? If you're dealing with HWNDs directly, it's either win32 or MFC/ATL, but those haven't been touched in tens of years in favor of the current .NET APIs.

Win32 does not do automatic layout.

Mac UI elements don't move around much—afaik they use about the same positioning that was decided when OSX was made. So the looks change but the layout not so much, and thus apps don't break on updates. Big Sur is probably the biggest change in the layout, in all these years.

Whereas MS keeps rearranging the layouts that were perhaps too complex to begin with. Especially the toolbars, with the row upon row of buttons and whatever other stuff MS crammed in there. My pet theory is that MS treats all UI as tables of various sizes, because it's easy for devs to just slap whatever they think up into rows. Apple was much better at the ‘proximity principle’ so avoided cramming from the start.

It also helps that MacOS is slimmer in terms of GUI apps—there's no ‘management console’ for admins and such heavy stuff. My litmus test of GUI environments is the control panel—and it's much lighter and more comprehensible in MacOS. (A similar telling exercise is comparing control panels of Gnome and KDE, at least it was when I last touched KDE in the 2000s.)

That’s what I wonder… understood that the windows internals are developed to maintain backwards compatibility, but why are they not able to change the user interface?

The Vista control panel being the second layer of the Windows 10 control panel is one of the weirdest. Other than maintaining the same layout for users, why is the second layer of their settings panel just the exact settings panel from the OS 14 years ago?

This. It's not about backwards compatibility for Windows itself; it's about investment. They don't want to pay to update all their menus and settings screens.

Easy. They never design their system with compactibility in mind. Also, since they own their own software and only allow to be installed in their own hardware, they have full control on everything.

I think it is because breaking API changes are introduced often, and most apps only work across a narrow window of 2-3 major releases.

Reply on news.ycombinator.com