If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit.
This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation; (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.
> despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation
That's inherent on the way current computers manage the memory. And I don't know if the gains are enough to pay for the loses of guaranteeing encapsulation.
One could reach for static analysis, but that would imply some restrictions on the machine's assembly. Those are probably worth it.
> a piece of code has different behavior depending on the identity of a function
I have written my quota of "find the latest caller on the stack with property X, verify if it has access", on different languages. Some times a function can't in any way be just a function.
A good argument for allowing and working with minor platform differences instead of trying to micromanage every little aspect to force inter-platform consistency and/or perfect compliance with the mockup.
> (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.
Note that most definitions of extensionality don't consider the number of steps to achieve the result as an observable property, although in practice it is.
> (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation;
That's why its a good idea to strip a symbol or provide a linker script. This way you can also properly version the code.
Abuse of private APIs means that your public API is incomplete. And that people dislike how your system behaves so much, that they're willing to muck with its internals.
"Not Apple's fault" is up for debate; even if Electron shouldn't be doing this, Apple arguably shouldn't be pushing out updates that cause issues with wide-swaths of software that users use regardless.
Notes from the Google bug tracker linked by the GitHub issue: applying this command to each Chrome/Chromium app impacting your system will workaround the underlying macOS resource leak (EDIT: which only occurs when Electron mucks with private APIs to fake having native UI):
That command’s equivalent is being patched into Chrome and will have to ripple downward into Electron apps; directing complaints to each electron app impacted with a link to the relevant Google issue workaround will give them sufficient data to mitigate it, if they bother to.
pps. Manually applying this workaround without scheduling its future removal has a slight but non-zero risk of someday breaking OS-linked autofill in your electron apps in weird or unexpected ways.
ppps. I don’t work for anyone, school for another three years minimum.
This affects some of the most widely used applications on the platform, including "productivity" applications such as Slack that Apple uses internally. How did no-one at Apple notice this and do something about it prior to macOS 26 being released?
I stopped using the Slack Electron wrapper as soon as Safari added support for "installing" web apps (File > Add to Dock…). Wouldn't be surprised if people within Apple did similar.
I know it's a defacto complaint to leverage against Electron apps, but memory usage notwithstanding, I've never run into much lag issue on any major Electron app.
No, they typically do not interfere with performance at the OS level. They may be wasteful with resources that are limited — CPU/GPU/RAM/IO — but for them to interfere with system function at this level is not the usual bloatware problem.
I’ve never noticed anything before, though I’m sure their performance is worse than native apps. I think the M series has so much headroom at this point that you can get away with a lot.
Discord and VSCode work smoothly for me on an M4 MBP -- not sure if it's a compatibility difference or just performance hiding the problem, though.
But Spotlight file search is completely broken, rebuilding the index doesn't help, and web results are the only thing it returns. After 20 years of intense research, Apple finally caught up to Microsoft in race to make search broken and useless.
It's very possible that the hardware performance is hiding the issue. I upgraded from my 2020 intel 13" mbp (16gb of ram, 4-core i5) to 16" M4 Pro for a variety of reasons, but the basic processes of MacOS were making it nearly inoperable periodically throughout the day. I gifted the old one to my gf, and I can hear the fans spin up from across the apartment when nothing else is happening but indexing. I recall regularly being irritated that I'd just have to wait a while for the indexing process to finish before getting anything done. Idk wth is going on, but it puts far more strain on the system than anything else I could throw at it except games and Docker. Even ProTools doesn't seem to produce audible noise unless a bad plugin or a rendering is taking place.
Aside from that, the Settings menu memory leak (or whatever it the problem is) is very much more apparent on the older mac than it is on the new one, but it's still reproducible. Neither computer is running Tahoe yet, these issues were already present, but based on on your comment, they might now be functionally worse in addition to being a performance and user experience joke.
My new Mac is still amazing hardware-wise, and since those issues seem to just be compensated for, perhaps by having efficiency cores that they're able to delegate background processes to, but the sluggishness and in-adequacy of frontline processes and apps must be embarrassing for what I presume to be smarter engineers than myself who probably just don't get to allocate time or energy toward any of the problems, especially with things like Xcode and SwiftUI also having major issues, and the mac being a relatively small market.
The instructions for fixing a Mac's corrupted spotlight index are amazing. I was planning to do it earlier this year, but the number of manual actions was just too ridiculous. Then, after it was broken for months, it spontaneously started working again.
Strangely the WindowServer issue is a constant issue on my personal MacBook Pro, but I've never seen it on my identical work MacBook Pro. It seems like there's some other factor that is necessary to trigger the problem.
Just imagine you are investigating a bug and everyone is trying to express their opnion on whose fault is this. What happened to not having a blaming culture?
I started experiencing massive overheating issue on latest version of Zoom and on macOS 26 and now 26.1 beta as well. Haven't experienced what you're describing, it's really odd.
Could possibly just hotpatch my existing app, add this to the packed in javascript .asar resource file and not having to make a new build with updated Electron version.
It seems odd that Apple could release an update that breaks common software, and not go to the trouble of at least contacting the developers of the software and discussing the issue.
Before I left Apple ~10y ago, it was pretty common to drop linked-on-or-after hacks into AppKit and UIKit to keep popular software chugging along. Assuming they're still doing that sort of thing, this was either missed or deemed not high-enough priority to add such a check (or maybe one was added, and the only reason this issue has been noticed is because Electron and Electron apps are now being built against the macOS 26 SDK).
The most inefficient solution (in both space and time complexity) being suggested to build desktop apps is now shown to be causing widespread sluggishness.
So much for interviewing developers for algorithms and data structures. Also Rust won't save you or make Electron faster either.
The most inefficient solution (in both space and time complexity)
Those are not the only qualities / metrics to optimize for. Developer eXperience, cross platform, open standards, easy compatibility with websites, easiness to keep updated etc. can be far more important
Individuals used to make sophisticated native apps as shareware for $10 back in the 1990s and today big teams rely on crap like Electron. The enshittification of everything.
I’m surprised to see so little pushback in press to iOS/macOS 26.
I’ve been part of the public beta and it’s been so weird going from “this sucks but it’s a first beta” through “it really isn’t improving much as time goes by” to “we’re a week from launch, there’s no way they release this after the Apple Intelligence fiasco”.
And yet here we are. Performance issues, ui inconsistencies and garish design everywhere.
I was going to wait for a few bugfixes until I upgraded, but I was forced to update to iOS 26 because the AirPods Pro 3 that I bought required it for some inexplicable reason (which I didn't know until I tried to pair them). The AirPods are just fantastic in every way and a huge leap forward, I don't regret buying them for a second. But sheesh, none of the OS updates were ready for release. I found 3 obvious bugs (non-functional UI elements, invisible labels due to incorrect handling of dark mode, soft locks caused by guided access) not to mention a distinct pause when unlocking the device, GPU issues with Safari. It seems like the pendulum has swung from Apple making mediocre overpriced hardware and reliable software, to making best-in-class hardware and garbage software. I'm hoping that with the end of Intel support we get a "Snow Leopard" style polish and bugfix of the entire stack, but with their recent track record it seems unlikely. It's just inexcusable for a company with Apple's focus on consumer products and market cap. At least Microsoft has the excuse that they have a sprawling empire to oversee.
You are describing every single macOS release. I still remember their permissions disaster which broke the majority of critical apps in people's workflows at launch. It's always best to wait a few months to upgrade.
It's possible that the majority of people are fine with it. I thought it would hate it but I love iOS 26. It adds much needed depth and allowed me to turn off accessibility options.
- Button Shapes: Buttons actually look like buttons.
- Reduce Motion: Animations are a lot more fluid and the parallax effects are more subtle. They don't trigger motion sickness like the previous ones did.
- Larger Text: The worst areas of the UI have better contrast.
- Reduce Transparency: While there's more transparency effects, they're a lot better.
- Increase Contrast: If I do need to turn this back on it is a much better integrated effect than previous version.
The changes in macOS 26 are half-finished. Anything with raised glass looks like plateaus in the middle of a flat desert. Only half the apps have the new rounded corners on window and they do not match the rounded corners in the rest of the interface. They even cut off parts of the interface like the bottom of every scrollbar.
It's disappointing. I loved Windows 7's aero theme.
c-hendricks|5 months ago
https://github.com/neovide/neovide/issues/3225
Other Tahoe issues with non-Electron apps:
https://github.com/zed-industries/zed/issues/33182
https://github.com/wezterm/wezterm/issues/7255
mrtesthah|5 months ago
mikamika83|5 months ago
nateb2022|5 months ago
kccqzy|5 months ago
If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit.
This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation; (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.
marcosdumay|5 months ago
That's inherent on the way current computers manage the memory. And I don't know if the gains are enough to pay for the loses of guaranteeing encapsulation.
One could reach for static analysis, but that would imply some restrictions on the machine's assembly. Those are probably worth it.
> a piece of code has different behavior depending on the identity of a function
I have written my quota of "find the latest caller on the stack with property X, verify if it has access", on different languages. Some times a function can't in any way be just a function.
cosmic_cheese|5 months ago
Zanfa|5 months ago
SkiFire13|5 months ago
Note that most definitions of extensionality don't consider the number of steps to achieve the result as an observable property, although in practice it is.
tyteen4a03|5 months ago
x0x0|5 months ago
Also, this in the comment:
> [a user] Please try any way of getting in touch with Apple engineers you can. As a project, we don't have a better connection to Apple than you do.
>
> One approach might be the engineer who replied to the Bluesky post that someone linked to above about the input issue.
Pure incompetence. Major projects have no way to do anything but ping randoms on socials.
1718627440|5 months ago
That's why its a good idea to strip a symbol or provide a linker script. This way you can also properly version the code.
cyberax|5 months ago
snarfy|5 months ago
wk_end|5 months ago
altairprime|5 months ago
That command’s equivalent is being patched into Chrome and will have to ripple downward into Electron apps; directing complaints to each electron app impacted with a link to the relevant Google issue workaround will give them sufficient data to mitigate it, if they bother to.
Apple is already aware — https://x.com/ian_mcdowell/status/1967326413830472191 (apologies for the Twitter link, but it’s an Apple employee). EDIT: Someone else has traced the issue to Electron messing with internal OS APIs! Courtesy of https://news.ycombinator.com/item?id=45377253 —
> It turns out Electron was overriding a private AppKit API (_cornerMask) to apply custom corner masks to vibrant views.
ps. This issue was discussed a week ago here:
https://news.ycombinator.com/item?id=45292019
pps. Manually applying this workaround without scheduling its future removal has a slight but non-zero risk of someday breaking OS-linked autofill in your electron apps in weird or unexpected ways.
ppps. I don’t work for anyone, school for another three years minimum.
mikamika83|5 months ago
ThePowerOfFuet|5 months ago
https://xcancel.com/ian_mcdowell/status/1967326413830472191
FTFY :)
bdash|5 months ago
cosmic_cheese|5 months ago
alberth|5 months ago
https://xcancel.com/mitchellh/status/1970944369336475713#m
mirthflat83|4 months ago
mikamika83|5 months ago
huijzer|5 months ago
nkozyra|5 months ago
GuinansEyebrows|5 months ago
https://github.com/electron/electron/issues/48311#issuecomme...
nottorp|5 months ago
"Application should use all cores and all available memory."
In the past few years, the only applications i've seen run amok with memory usage at least were of course Electron based.
However, note that this problem is on Mac OS "users had too much contrast so we ruined it" 26 Tahoe. It's part of the early adopter experience.
altairprime|5 months ago
mcintyre1994|5 months ago
unknown|5 months ago
[deleted]
schmidtleonard|5 months ago
But Spotlight file search is completely broken, rebuilding the index doesn't help, and web results are the only thing it returns. After 20 years of intense research, Apple finally caught up to Microsoft in race to make search broken and useless.
brailsafe|5 months ago
Aside from that, the Settings menu memory leak (or whatever it the problem is) is very much more apparent on the older mac than it is on the new one, but it's still reproducible. Neither computer is running Tahoe yet, these issues were already present, but based on on your comment, they might now be functionally worse in addition to being a performance and user experience joke.
My new Mac is still amazing hardware-wise, and since those issues seem to just be compensated for, perhaps by having efficiency cores that they're able to delegate background processes to, but the sluggishness and in-adequacy of frontline processes and apps must be embarrassing for what I presume to be smarter engineers than myself who probably just don't get to allocate time or energy toward any of the problems, especially with things like Xcode and SwiftUI also having major issues, and the mac being a relatively small market.
jeffbee|5 months ago
jama211|5 months ago
duskwuff|5 months ago
I had the same issue; killing Spotlight processes fixed it. (A reboot would probably do the job too.)
jks|5 months ago
Doesn't seem to be updated for Tahoe yet, and even the Sequoia version isn't notarized, so it's not really clear if it has a future.
tw04|5 months ago
unknown|5 months ago
[deleted]
OGEnthusiast|5 months ago
Etheryte|5 months ago
bdash|5 months ago
OfflineSergio|5 months ago
unknown|5 months ago
[deleted]
electric_muse|5 months ago
I've had this issue on my M1 and now my M4 mac for about a year now, and I can't figure it out. Uninstalling and reinstalling hasn't helped.
Literally, someone can reliably send me a slack notification in a meeting (even when DND is on) and cause my Zoom outbound video to get gummed up.
Edit: I ask because I wonder if it has to do with this.
skfist|5 months ago
frays|5 months ago
I shouldn't have updated to MacOS Tahoe on my Macbook knowing that it was a .0 release. They need to fix this ASAP.
unknown|5 months ago
[deleted]
efitz|5 months ago
taroth|5 months ago
`browserwindow.setHasShadow(false)`
inDigiNeous|5 months ago
Could possibly just hotpatch my existing app, add this to the packed in javascript .asar resource file and not having to make a new build with updated Electron version.
trothamel|5 months ago
cjk|5 months ago
wg0|5 months ago
At least I notice fan going jet speeds with VSCode lately.
rvz|5 months ago
The most inefficient solution (in both space and time complexity) being suggested to build desktop apps is now shown to be causing widespread sluggishness.
So much for interviewing developers for algorithms and data structures. Also Rust won't save you or make Electron faster either.
ttoinou|5 months ago
IgorPartola|5 months ago
2. What better cross platform GUI alternative do you suggest?
wiseowise|5 months ago
urbandw311er|5 months ago
rayiner|5 months ago
inDigiNeous|5 months ago
These days if you want to support macOS, Windows, Linux: I say good luck to you, Electron can save you there.
Electron is not crap, but many javascript developers are crap. You can make fast and memory efficient apps in Electron, if you know how to code.
(Note: Slack or Discord developers don't have that skill)
system7rocks|5 months ago
kridsdale3|5 months ago
urbandw311er|5 months ago
nntwozz|5 months ago
reaperducer|5 months ago
Not awesome if you're in a large company where you have to communicate with others and don't get to choose the medium.
unknown|5 months ago
[deleted]
kace91|5 months ago
I’ve been part of the public beta and it’s been so weird going from “this sucks but it’s a first beta” through “it really isn’t improving much as time goes by” to “we’re a week from launch, there’s no way they release this after the Apple Intelligence fiasco”.
And yet here we are. Performance issues, ui inconsistencies and garish design everywhere.
Fwirt|5 months ago
_0xdd|5 months ago
pier25|5 months ago
b_e_n_t_o_n|5 months ago
unknown|5 months ago
[deleted]
coolspot|5 months ago
paxys|5 months ago
unknown|5 months ago
[deleted]
wswope|5 months ago
Hasn't that been Apple's norm for a few years now?
Not trying to land a cheap dunk here; I've honestly been running into rough edges and bad design with every major release for a long time.
rpgbr|5 months ago
kayodelycaon|5 months ago
- Button Shapes: Buttons actually look like buttons.
- Reduce Motion: Animations are a lot more fluid and the parallax effects are more subtle. They don't trigger motion sickness like the previous ones did.
- Larger Text: The worst areas of the UI have better contrast.
- Reduce Transparency: While there's more transparency effects, they're a lot better.
- Increase Contrast: If I do need to turn this back on it is a much better integrated effect than previous version.
The changes in macOS 26 are half-finished. Anything with raised glass looks like plateaus in the middle of a flat desert. Only half the apps have the new rounded corners on window and they do not match the rounded corners in the rest of the interface. They even cut off parts of the interface like the bottom of every scrollbar.
It's disappointing. I loved Windows 7's aero theme.
unknown|5 months ago
[deleted]