Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Inspecting Web Views in macOS (jim-nielsen.com)
536 points by ansh_nanda on March 12, 2022 | hide | past | favorite | 140 comments


The headline isn't technically wrong but it's a tiny bit misleading because the use of web views is limited to a small number of iCloud account screens. These aren't really "system" preferences so much as Apple cloud service settings which have been wedged into System Preferences.

(And where it is used, it's doing the barest minimum. The preference window itself, the top bar, and the iCloud sidebar are all still native UI.)


We've reverted the title now. Submitted title was "macOS System Preferences Uses React".

"Please use the original title, unless it is misleading or linkbait; don't editorialize."

https://news.ycombinator.com/newsguidelines.html


I wasn't surprised to see the Family Sharing pane in the first screenshot. It's easily the most janky part of System Preferences that I've had to struggle with:

- Loading indicators for several seconds when switching between categories in the left sidebar, on a very decent internet connection.

- Janky animations and transitions when opening modals, like clicking the "Details..." button on a family member.

- Within the "Invite people to your family" modal, clicking "Not Now" causes the "Invite People" button (the default, highlighted action) to blink before the modal closes.

Yes while these are absolutely nitpicks, I feel that Apple has lost some of the attention to detail that set them apart.


My thoughts exactly. I never liked these iCloud system settings and now I know why. They are not native but janky web views. Same for the Mac App Store which behaves very similar.


Sounds like they need useMemo(), useCallback() and an abort pattern, lol.


Wow. I always thought the argument in favor of using web technologies on the desktop was that cross-platform became easier. And yet here is an example of the most unambiguously single-platform app I can possibly imagine, and under the hood it uses web - and React of all things! Crazy.


It has the advantage of allowing the iCloud team to update the preferences panel without the need to release macOS updates. Allowing them to decouple iCloud updates from the macOS release cycle.

Sure you could use something like SwiftUI and create some simple DSL to dynamically build a native UI. But at that point you’re basically building a slightly crappier, less flexible version of HTML. So might as well use HTML+CSS and take advantage of the decades of learnings it represents.

I’ve personally used a similar approach to power a banks fraud warning UI. Made it possible for us to quickly iterate and change our UI as various strategies used by fraudsters evolved. Meant we could go from see a new issue, to updating our ML models and deploying new UI in under a week, which is faster than the app review process.


Still, they could've probably made some strides with React Native on macOS and the win-win that entails. UX improves in these instances + arguably RN benefits from the Apple buy-in.


A settings view that is largely shared between macOS System Preferences, iOS Settings and icloud.com is not single-platform. Windows Settings uses React Native for the same reason.[1]

[1] https://news.ycombinator.com/item?id=30384494

Edit: mention iOS Settings.


> between macOS System Preferences, iOS Settings

Why don’t those both use the same UI toolkit, like the convergent GNU/Linux DEs? (macOS seems to be getting more touch-optimized with each update — eg. making sliders giant and iOS-style; why hasn’t Apple merged Cocoa and Cocoa Touch into one yet?)


AppKit and UIKit are very different. SwiftUI and Catalyst are the unification efforts, but uptake is gradual. Anyway, once you throw icloud.com into the mix it doesn’t matter.


You can already use SwiftUI to build apps that work on both macOS and iOS, so the libraries are there, Apple just needs to use.


As it turns out, React / CSS / the document-object-model are popular for more reasons than “it works on different computers.” Who knew!


who knew? it sneaked up on us.

we spent decades wedging compatibility shims into gaping functionality holes, while heroic visionaries of the web as a platform toiled and bargained to bring us the tools we needed for modularity, performance, and a modicum of basic platform services.

all while making sure <TD STYLE=FLOAT:RIGHT> continued to work.


Apple has been using web views for apps for more than a decade - recognizing that such an object is more generally usable than just "a browser" was a motivation for WebView (now WKWebView) existing as a platform API from the earliest days of WebKit being a thing that existed (The logical extreme being the original WebView API exposed an objc interface to the DOM)


And Windows pushed in this direction heavily back around 1999–2005, with things like https://en.wikipedia.org/wiki/HTML_Application and IE being used quite extensively in Windows Explorer in Windows XP and a couple of versions around it. (In fact, if it weren’t for the whole antitrust situation around the inclusion of IE, I suspect they would have gone even further in on web content on the desktop rather than letting it lie fallow for something like fifteen years.)

There’s a reason you get system colours and fonts in CSS: they’ve been round since the ’90s. You certainly wouldn’t get such useful and flexible stuff being added now.

There are very strong parallels in a lot of the progress that’s been happening in the past few years with what happened twenty years before. Probably the most obvious example is dark mode: computers had that twenty years before, then it got lost somewhere along the way, then it gets reinvented in an only slightly different form (both more and less useful: it’s far more restricted, to just one alternative theme rather than many, but for the web you can actually design for it in CSS alone this time).

Cycles.


My recollection of using the old windows HTML control was that it was very useful outside of being a basic content view - obviously there was subsequent additions to the web that made some functionality in webkit available, but the WebView controls in my extremely limited experience seemed a much better fit for minor content views in apps.

Of course that's all kind of moot because the important point is that there's a large different between a native app that uses a webview (or the windows/linux equivalent) to display some content, and a cut down browser view trying to act like a native application. Admittedly a number of the bugs in electron apps are a byproduct of their use of chromium which is very much a Mac-second engine and the actual API requires host apps to do much more work for system integration, which is a valid choice: it gives the host app much more flexibility in handling things. The down side is there are some things that apps shouldn't be trying to reimplement themselves.


that makes sense considering khtml, from which webkit evolved, was designed as a web view for the kde desktop environment.


These pages are the least performant part of the preferences application.


I expect these additional reasons can largely be summed up as "I already know it from using it in the browser, so let's use that"


I think it’s a little unfair that you’ve been so downvoted (at the time of writing), because the old phrase about hammers and nails is super applicable to software development, and the icloud team may very well know react better than cocoa.


Actually, web pages are a very declarative GUI, with an amount of reflexivity and editability that should be on any declarative GUI framework, but normally isn't.

Those properties open up the possibility of abstracting things and making very powerful libraries over it. There is nothing else as powerful out there.

Yet, everybody stops at plain react. So whatever is the reason for the success, it's not that one I pointed.


You'd probably be wrong!

Let me introduce you to https://github.com/ocornut/imgui


Which doesn't use React, CSS, or a DOM...? What's your point? ImGUI is imperative UI programming. DOMs are declarative.


ImGui makes UI programming declarative in structure the exact same way React makes UI programming declarative.

React brings to the table is the general concept of immediate mode UI programming. So does ImGUI. Reaching for React doesn't mean it's the only thing the programmers knew, it means it's a general pattern that arises in UI programming.


No, it absolutely does not. ImGUI is a completely, totally different model of GUI programming.


Sorry, but they are the same concept. They’re both immediate mode GUI tools that provide a way to declaratively describe the UI in an imperative language.


React is not immediate mode, imgui is not declarative.


I'd bet that the reason they're using React is because it's cheaper and easier to find front-end developers for the task.


I’ve been hearing this on HN and similar forums for what feels like years now: “Electron/web-based GUIs are only popular because it’s easy to find devs in those ecosystems”

Have we considered asking why it’s so much easier to find React devs? Why such a huge, huge majority of UI development today takes place on the web?

I’m a front end web developer. I’m very biased.

But I’m a little tired of the narrative that “the right way to make a UI is to build it natively, but everyone wants to take the easy way out.”

Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience. And if you spend some time exploring them, I think that becomes very obvious very quickly.


> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience.

That depends on what one values, in my opinion. Whenever I start poking around with front end web stuff it makes me want to tear my hair out. Not because it isn't technically capable, but it all feels so slapdash, duct-taped, and chaotic compared to what I'm used to writing AppKit/UIKit, even if some aspects of the experience with front end web tech are nicer. Things are solidifying around React which helps, but for me at least, it's still a hard sell to trade away the positive aspects of native development just to get the positive aspects of front end web dev.


I’m guessing you haven’t tried building something serious with SwiftUI then. Because for me React is a million times more polished than SwiftUI.

I was a native dev before I got into web stuff. The Apple APIs for native GUIs are so good, but they are extremely verbose, and with swift now they are closed source. It’s just not as easy (or fun tbh) to build things with


SwiftUI is promising, but still green (for now). So no, I was talking about just plain old AppKit and UIKit. No fancy declarative syntax, but plenty capable.

Closed source isn’t great, but I’ll take that tradeoff for how much less frequently I need to reach for a third party library or write widgets from scratch.


Seriously, have you TRIED non-web, cross platform, UI dev? It's a nightmare. At least all the things I've tried so far are. I'm trying KDE's Qt IDE out and so far it seems much better at getting a working example built, though it looks like it's missing a visual interface editor. Qt-the-company had a good visual interface editor I used in ~2018 I think with PyQt but I can't find a way to launch it anymore. It's a mess.


Qt Designer[0] (for widget-based interfaces) is still a thing, and they have added Qt Quick[1] and Qt Quick Controls (for QML-based interfaces).

Recently they’ve been integrated into the IDE but with a right click on a file (within the IDE file browser or project browser panes) you can open a .ui file in the external Designer.

[0]: https://doc.qt.io/qt-5/qtdesigner-manual.html [1]: https://doc.qt.io/qt-5/qtquick-index.html


I am insanely productive writing desktop applications with wxPython+wxWize. No GUI designer, no XML, just straight up Python code that's easy to follow and easy to refactor. I can whip up a prototype as fast as I ever could in Delphi, and it transitions cleanly into the finished app.

I guess if cross-platform needs to include mobile, then that's not good enough. But for what it does, I'm very happy with it.

Full disclosure: wxWize is my own creation.


I have, since the days of 16 bit home computers where when I wanted ultimate performance it had to code the core of the application in straight Assembly.

The only platform that offers native RAD like tooling for Web Development is OutSystems, most don't come even close, probably WebFlow.

Naturally since most devs don't like to pay for their tools, their target market is enterprise shops, so only Fortune 500 devs get nice tooling.


The GUI designer is called Qt designer - it's called designer in Ubuntu/Debian. Unfortunately Debian has really made a mess of their packaging of Qt/PyQt. They've split up everything into tiny packages and their naming scheme seems crazy - I can never work out which package to install to get what I want. In this case it's qttools5-dev-tools.


Some of us don't think much of Qt either.


I have, and I found QtQuick and QML to be a better experience for reactive UI programming.


> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience.

Native UI toolkits are light years ahead of anything the web can offer in any forseeable future.

Well, WebGL is somewhat of an exception, but then you're literaly bringing native technologies with limitations into the web.

And one major exception: deployability. Nothing can beat the web in deployment.


> Why such a huge, huge majority of UI development today takes place on the web?

Business models centered around the web, like the cloud and SaaS, and because it's the lowest common denominator when it comes to cross platform development.

> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience. And if you spend some time exploring them, I think that becomes very obvious very quickly.

QML works very nicely, it has a pleasant developer experience, it's reactive and declarative, and it even gives you JavaScript. It's similar to React in those regards, and I prefer it.


I believe the reason why so much UI development takes place on the Web is because there are a lot more people making websites and web applications than there are making desktop applications. For example, think of all of the businesses and institutions, big and small, that need a web presence. Because the Web is such an essential part of modern commerce, it makes sense that there would be much more work available for web UI development than for desktop UI development. In addition, the Web is quite possibly one of the easiest platforms to deploy an application. Want to reach much of the world? Spin up a cloud VM, get yourself a static IP and a domain name, deploy your web server, and voila!

Another thing to consider is that native app development is fragmented. For one, there are a variety of platforms. There are four major commercial platforms for consumers: Windows, macOS, Android, and iOS. In addition, each platform has multiple ways of doing native development. I don't know much about the Android ecosystem, but in Windows you have a choice between (off the top of my head) Win32, MFC, WPF, and WinRT (and I may have forgotten a few), on the Mac you have a choice between AppKit and SwiftUI, and on iOS there's UIKit vs SwiftUI. Thus, it's not enough just to hire a developer based on platform; it's important to hire based on experience with the API your application uses.

In my opinion, my negative opinion of Electron on the desktop has nothing to do with laziness. There has always been a tradeoff between developer convenience and optimal performance in software engineering; for example, this is why I write machine learning code in Python instead of fine-tuned assembly. If that's lazy, I'm guilty as charged. Rather, my negative opinion is based on these issues:

1. A disregard for conforming to the platform's UI/UX guidelines, which are in place to ensure consistency in behavior across applications. By Webifying the desktop we get rid of one of the strongest advantages of desktop operating systems, which is consistency across applications, and we turn the desktop into the inconsistent hodgepodge of user interfaces that make up the Web.

2. Accessibility problems that are caused by ignoring the native platform's accessibility APIs.

3. Performance issues caused by running instances of entire web browsers to duplicate UI rendering features that already come with the UI toolkit of the system.

4. Applications written with the Web in mind for the desktop often inappropriately use design elements that may make sense in a web browser but do not make sense on a desktop (this is related to #1).

Some would say that #1 has long been the reality for Windows and Linux long before Electron existed due to competing toolkits (especially in the Linux desktop world) and app-centric viewpoints from application vendors where the look-and-feel of an app trumps platform consistency concerns for branding reasons. I agree. However, some say we should shrug, give up the dream of consistency, and accept having inconsistent applications. I believe there should be more consistency between applications (in fact, I disagree with the notion of app-centric desktop computing in general and strongly favor a component-style model, but that's another debate for another time), and I believe one of the strongest selling points of the Mac is the high degree of consistency that existed among the platform's applications for decades. The move toward Webified desktop apps undermine this consistency, however, and that I believe undermines one of the big things that make the Mac special.


>Thus, it's not enough just to hire a developer based on platform; it's important to hire based on experience with the API your application uses.

I don't think so. I'd hire an iOS developer for a macOS job. There is enough commonality for it to be an easy transition. It's the same on Windows, the Winforms app I work on has a ton of win32 calls and a smattering of XAML/WPF.


> I'd hire an iOS developer for a macOS job. There is enough commonality for it to be an easy transition.

No. No there isn't. As evidenced by the crappy Catalyst and other mobile ports that break all possible platform conventions on MacOS.

Yes, it might be easier, but not easy.


No. That's wrong. The fact that there are poor quality catalyst apps is neither here nor there. The tooling, languages and large parts of the frameworks are common or so similar that it doesn't matter. You can go straight from writing an iOS app to writing a Mac app without much friction at all. I know because I did it.


They probably gave the icloud team, a team largely made up of web developers, full authority over that system preference pane. Their experience is in react, they chose react; makes a lot of sense. Even more so if the data here is used by similar pages on the web version of icloud.


I could see that they want the flexibility to change the web app without having to roll out a Mac update.

The results aren't good though, the whole thing is painfully slow.


Why is it crazy? Doesn’t a lot of the office tools also use react these days (maybe just the online ones but still)?

I’ve only recently started working with react, but so far it’s been the best experience I’ve had working with GUI in decades of working with different things.

I’ve always been what you’d call a full stack developer, but I’ve always very much not been the front end design developer, and react with bootstrap and font awesome is the first time I’ve been able to effortlessly create GUI stuff that doesn’t look like it should’ve been made by a front end design type.

So to me this is not at all surprising or crazy. It’s simply what happens when you have a really effective tool that a lot of people know how to use.


Definitely every one of these is sluggish at best on a very modern machine but they are also full of UI annoyances. God I am so tired of little spinners for things that would have displayed instantaneously on ten-year-old hardware with previous UI designs.

I’m also really tired of things that pretend to be single apps but every other thing you click on will jerk you into an entirely DIFFERENT app. Oh, a sidebar: logically, clicking any item on the side should always update the right-hand side, right? Nope: some of the items you click on might update the right-hand side (after displaying a stupid spinner of course); others will hurl you into the App Store app and slide in some un-Mac-like UI to display 3 pieces of information (usually with truncation that can’t be fixed in a view that can’t be resized); still others might just open a web page (one that only works in Safari of course, because to hell with your browser preferences).

Why is any of this crap necessary? It’s perfectly clear that Apple just doesn’t care at all anymore about making nice, smooth, usable experiences. More than that, they don’t seem to even know how their own desktop platform has traditionally behaved. But even if they did want to change how things behave, why are so many things behaving differently? It is a complete mess and they should be embarrassed. No leadership AT ALL on the UI front.


Source-available variants of [GNU's Not] Unix have often been on the leading edge of user interfaces, from immitating the Xerox PARC desktop metaphor before Windows did (X11 initial release: June 1984, Windows: November 1985) to adding intrusive ads to the main system menu / search around the time Windows 8 was released. But it’s interesting to see macOS’s proprietary UI now apparently following GNOME’s example of powering “native” interfaces with JavaScript.

Edit: apparently this is actually more similar to Windows, which also uses React for system settings. All this DE stuff is too complicated for a simple person like me (I just use dwm on desktop and mobile).


> [...] following GNOME’s example of powering “native” interfaces with JavaScript.

Isn't this javascript but without web tech? That doesn't really stray too far from native anyways.


Windows 98 predated both of these, i.e.

> to adding intrusive ads to the main system menu / search around the time Windows 8 was released

...active desktop's channels[0] were basically ads in your desktop

> GNOME’s example of powering “native” interfaces with JavaScript

...HTML Applications, ActiveScripting (with the JScript backend) and an embeddable MSHTML/IE engine enabled both JavaScript and "web views" in applications (in Visual Basic 4 or later all you had to do was to use the web control to get instant HTML rendering capabilities).

With "active desktop" you could even use an HTML or web page as your background, e.g. back then i had a hacker-ish background with scrolling assembly code at the side (the scrolling was done via javascript) ala Terminator - though i disabled it after some days since it was using pretty much all of my CPU :-P

[0] https://i.imgur.com/9AqdbdM.gif

[1] https://en.wikipedia.org/wiki/HTML_Application


Windows settings use react native


Sadly, at least it uses WinUI/UWP underneath.


Apple has been doing that for ages, see e.g. the iTunes music store or Apple Music.


Not really. There is a webview for certain account related stuff that gets loaded from a web page which happens to be a React app. Most other settings are native code and not loaded from a remote URL. Completely misleading post/title.


> Here’s an idea: guess at new features in macOS by using the work of Safari team members as a leading indicator.

Shh, please... we don't want WebKit releases to look like xnu releases


Hmmmm. I wonder which OS will support in-kernel JIT for JavaScript first. :v

(/s ... I hope??)


Why would it need to be in-kernel? What advantage does that serve?

For what it’s worth there’s JavaScriptCore (at least for mobile) which is the only way to do JIT on iOS. It’s constantly criticized as being slower than competing JavaScript JITs while Apple counters that it’s an important security barrier.


In kernel eliminates context switching overhead. Theoretically a perfect JIT doesn’t need hardware security.

Also, JSC has been faster on Mac than V8 until a few days ago.


What context switching overhead is eliminated? This makes no sense.


I think at some point Apple will just have to recognize that the web UI has won. I say that with a heavy heart, I enjoy them as a developer but despise them as a user.

But it's really hard to compete. On the browser side, the vendor must only implement the standards as correctly and fast as possible, while the community tries all sorts of crazy paradigms and supports the ones that eventually stick.

On the native side, the vendor must anticipate the trend, invest and support it. If it chooses the wrong one or the implementation is bad, it's years down the toilet. I fear that SwiftUI is taking that path.


I don’t think it has anything to do with trends. It’s about $$. Web UIs are infinitely faster to develop, there’s typically better tooling (larger ecosystem), and there’s many developers which means you can get them cheap.

The counter though is that Web UIs have struggled and continue to struggle with performance - specifically the RAM usage is insane for what the equivalent native UI. RAM is tightly coupled with standby time in sleep since RAM is the most expensive component at that phase. Turning off banks of RAM is important but you can’t do that if the banks are still in use.


Flutter would like to talk to you.


Elaborate please


Flutter is the most popular cross-platform mobile SDK (already handily beat react native) and its not web-tech. It's now posing a very stiff challenge to native platform-specific UI frameworks. Many folks who wrote used web-views to developer apps are moving to flutter.

https://stackoverflow.blog/2022/02/21/why-flutter-is-the-mos...

Once the desktop Flutter story kicks off, say good-bye to Electron.


Awesome! Do you know more Web Views in use?


Don't quote me on this, but I believe that Apple Music (nee iTunes) has used web views for a long time; probably over a decade. The entire thing probably isn't a web view, but my recollection is that the store components were.


Apple Music is now using a technology they developed to convert web views back to native - https://news.ycombinator.com/item?id=30648424

On macOS 12.2 Music consumes much less RAM, and no longer has a webview process.


I think your link is wrong; are you thinking of Catalyst[1]?

I'm not an Apple insider, but Catalyst looks like the thing that was codenamed Marzipan for a while. I think it's more for converting iOS apps than web views.

[1]: https://developer.apple.com/mac-catalyst/



Yes, I intended to link to the 9to5mac article, but it’s too late to edit


Still remains quite slow and unresponsive in comparison to Spotify.


Wrong link?


Library -> Albums has some onHover feedback, which I haven't seen anywhere else.

I guess the Help documents are Web Views as well, e.g. right-click on an image.


Yes, both iTunes and Apple Music. That is why they are slow, comparatively speaking.

But they are finally rewriting Apple Music app to full native.


This macOS dictionary app (Dictionary.app) also uses webviews. This will come as no surprise since it does things like in-line Wikipedia results.


Unsurprisingly the App Store is another example.


App Store was rewritten in 10.14 and it no longer uses a Web View for the main content, some Apple ID setting might still be Web Views.


I remember giving up on my Hackintosh install after the App Store started rendering without CSS, breaking update functionality. Always thought that to be a weird failure mode for a system application.


A lot of Apple apps used to use Web Views on macOS: Messages, Music, TV, App Store, for example. But they have been slowly phased out. Messages in Big Sur, App Store in Mojave, Music and TV in Monterey.

Right now they are only a bunch of settings panels remaining.


Fascinating. Thanks for sharing! In other news, does anyone know of an up to date catalog or list of all the “defaults” settings, possible values, and what they do? I looked for this several years ago and found nothing, and Apple’s documentation on MacOS was far better back then. As in, it existed. These days ask i can find is incomplete objective c docs that were auto-generated and offer absolutely nothing of value whatsoever (to me). So if anyone knows of some useful docs, please share!


This seems like a huge security risk. Are they auditing the thousands of third-party packages that make up a typical react app?


Its interesting that so many apps use web views... Is the native GUI libs really that bad?


> Is the native GUI libs really that bad

They are pretty good, especially for the simple things like preference panes.

There are just many more web developers than native developers. And when you have a hammer...


OK interesting - but why?


Looks like it's Apple's Internet offerings, which is a growing number of services which makes perfect sense to write them inside a server updatable webview.


Probably because the devs want to do something and have no properly useful tools available to them, so they use something out of convenience.

It feels a bit tacky to me that Apple would use something a bit janky, it points at a bit of a gap in tooling.


React is enjoyable to use?


As a web developer that primarily codes in React for the last 5 years, I strongly disagree. I use it because of the ecosystem and I think everyone does. It's not that fast, and it's quite verbose.

That's besides the point though, because I doubt Apple chose React because they "enjoyed" it here.

I like web tech but I also think it's not worth it for this use case (even if it is shared with the web). What naturally happens is you start asking "well if we did it for that, why not for this?" Sooner or later it invades the system.

I've worked on desktop apps where the same thing happened where webviews were not truly needed.

I don't have a hate for it in general, but Apple was extremely strong in native UI so I would have liked to see them try to stick to that, even if it meant coding it twice.


It’s definitely a bit disingenuous to call React verbose when you are comparing it to Cocoa et all.


The previous poster wasn't comparing it to Cocoa when calling react verbose.


This is something Apple has done for years. Especially with the native iTunes UI. They used to use Sproutcore pretty heavily for stuff like this, which later became Ember.js


This might explain why, although I'm not a constant user of Mac, whenever I've had to use it, the UI has felt a little (and in the newer versions, significantly) more sluggish than Windows on the same hardware. It's not hard to see how someone accustomed to that level of responsiveness could find Electron not too different from a "native" app that's actually doing much the same thing.


It's like three webviews in the system preferences app.

So probably not.


That's exactly my point. If the true native apps are just as slow as the web ones, the latter don't seem any different, and thus, Electron apps too.


Try the settings app in Windows 11. It's just as sluggish and unresponsive. At least in a VM, it has the tendency to freeze and be unresponsive to input.


The one in Windows 10 is already much worse than the one it replaced, but I don't think it uses any webviews.


Certainly consider macOS using rounded corners, heavy drop shadowing, font smoothing, and animation.


Interestingly, the screenshot doesn't show <settings-app>, but <settigns-app> [sic].


Oooh you’re right. I didn’t notice that. I wonder…


I have noticed web being used as a platform for UI in a bunch of programs, particularly within games.


It’s replaced ScaleForm (the Flash powered UI option) in many places it seems. I’d love to know what kinds of techniques are used for really flashy UIs. There are a few companies solely focused on this middleware (web-based UI in video games).


Not sure how do I feel about this, amused or horrified.


How about bewildered?


why does this matter? on GNOME i can pull up the javascript development console for the whole desktop this is nothing new.


Gnome use javascript with native UI. Apple simply use webview.


ohh wow that seems inefficient to use a browser


That explains how looking at your iCloud preferences are near the most unreliable and slow part of settings. Even more so the Apple engineers never consider someone could live outside the US.


And non-conformant UI, as well. It's like the HIG just doesn't exist anymore. Scroll up inside the Family Sharing family table. Does the interior of the table have an elastic scroll? NO! The entire Family Sharing pane instead scrolls up.

Ditto for the Details sheet. That one also doesn't honor the system-wide feature of navigating prompts with Cmd-(first letter of buttons), doesn't support Esc to leave, and doesn't have a default button to boot.

The +/- icons that appear in the Family Sharing are also completely unique to the OS. Ugh. I could go on.


> It's like the HIG just doesn't exist anymore.

It really doesn't, and Apple's own apps are the first to break all the HIGs


I've always wondered why these panes in particular felt like total garbage in comparison to the rest of System Preferences. Now I know!


Confirmation bias!


Tell me you've never used the iCloud preferences in macOS without telling me you've never used the iCloud preferences in macOS.


100%.

It's the worst.

The glacially slow UI performance is terrible. It's also unreliable in weird ways that are hard to explain in a sentence or two.


I really hate reading HN comments involving anything with JS. Probably some of the lowest quality comment sections on the site.


Yep. I click in and get ready to cringe at the weird claims. Today there’s someone claiming that nobody enjoys using React.


No wonder everything gets slower and slower every year. These people are shameless.


Quick. Hide the evidence so the ATP purists can still insist on ideological purity and in the one true belief that the only way to write Mac Applications is to do everything in Swift or Objective-C.

After all, If Apple does it....


It is using webview to display some content in an app that is native. That's been common practice in many Mac applications for a decade. WebKit exposes native NSView subclasses to make embedding them trivial enough that for some content they are /better/. Heavily formatted content? Write your own layout engine, or just use html?

The problem with electron apps is that they are entirely a single webview, that poorly implements the vast majority of standard platform affordances (if you read the other comments, you see a lot of people complaining about this specific part of System Preferences). Add to that these applications using absolutely astounding amounts of ram, huge downloads because you're essentially downloading a full copy of chrome for each app, they all have terrible launch times (because there's each is loading its own copy of chrome), the bad and laggy accessibility features, etc and the reason people dislike them becomes fairly clear.

I get that there's very little standard UI or inter app interaction on linux and windows, but historically that has not been the case on Mac - the increasing prevalence of low quality electron apps is making that less reliable.

The only electron app that is actually a good app is VSCode, and even that is always frustrating to use due to a bunch of basic platform behavior that they at best get wrong, but more often just don't even attempt.


Nothing wrong with it per se. But the developers choosing tech like Electron usually do it because it's low-effort cross-platform. With the emphasis on low-effort.

It means they're not really willing to put in the work to make it run well. They just want to cobble something together and get it out there. There's really well-performing Electron apps, like VS Code. But the very same company also produces extreme turds, like MS Teams. This app is extremely unresponsive, takes about 30 seconds to sometimes even a minute to start up on a clean M1 Mac, and often crashes or just hangs. It's really horrible. And unfortunately the app I need the most for work.

These are the apps that give these cross-platform web technologies a bad name. I understand why now that I have to struggle with this crap every day. With slack I just minded the UI not really fitting in but it performed just fine so I didn't hate the tech so much.


Note all the comments here about how that part of the UI is broken in so many ways.


GUI development is really fucking broken. I get it, it's hard to compete with a standardized platform with a probably billion man hours poured into it but I'm really hoping that Rust will make it possible to write native and web experiences from one codebase.


What does rust have to do with this?


it allows OP to farm karma effectively


Appears to be backfiring somewhat. I say that as a Rust enthusiast.


Its the first language that lends itself to be used both on the desktop fornative GUIs as well as in the browser.


What? My understanding is that there isn't a native GUI toolkit written in rust for any platform at all. At least, not one that isn't a toy project.


This post is talking mostly about CSS and it shows a document object model tree. JavaScript is also used, given that he mentions React.

Among these options, it seems that Rust is most similar to JavaScript. But this whole article would be the same if React was written with Rust instead.

So what is the broken part of GUI development, and why is Rust positioned to fix it? As I see it, not much would change if we used Rust instead of JavaScript, except that it could be harder to diagnose when ReactInRust is being used.


Amusingly, SwiftUI seems much better suited to this use case than any other lower level language, while Elm and Clojure are much more obvious contenders. In any case, the space is crowded with DSLs and the expression-based DSLs are the ones that generally keep gaining traction.


The broken part is that it is worth it to use an inefficient rendering method (lots of JS generated by React + an interpreter and GC + a render tree (React VDOM) + an overcomplicated element tree (DOM) + a rendering system) instead of an efficient rendering system (if React-in-Rust existed, it would be native executables manipulating an in memory tree for a renderer, removing at least two layers of complications). And this seems to be simply because the React+JS model works so well for DX compared to the rest that it allows for way faster feature implementation.


I’ve been working on this :) https://dioxuslabs.com/


> I get it, it's hard to compete with a standardized platform with a probably billion man hours poured into it

Are you talking about the MacOS System Preferences app, which has probably been around since Macs switched to Intel, or about React? Either could fit that description.


I'm talking about WebKit.


How about flutter? It uses native views.


As far as I'm aware, Flutter is like Qt and React Native in that its platform controls are redrawn to look like native controls.


Flutter replaces the entire views with its own rendering engine. That has caused some issues with consistency.


why Rust in particular?


I missed the /s ?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: