Track which Electron apps slow down macOS 26 Tahoe(avarayr.github.io)
avarayr.github.io
Track which Electron apps slow down macOS 26 Tahoe
https://avarayr.github.io/shamelectron/
143 comments
Apple constantly misuses "private" API to give their own applications feature they don’t want to see in other applications on the AppStore.
At some point, the current situation is to be expected. It’s ok. Electron apps will be fixed and it will be all right.
At some point, the current situation is to be expected. It’s ok. Electron apps will be fixed and it will be all right.
A trusted source once told me that Mac OS 10 system libraries contain a bunch of shims so that Adobe apps may continue to misuse them the way they did in Mac OS 9. Now that they have a tight grip over the app ecosystem, they don’t even bother to help a major OSS framework that powers thousands of apps make the transition.
Seeing 1Password there hurts me. They used to be paragons of well designed native apps that they dumped with 8.
I’m not sure I’ve seen an app plummet in quality as much as 1Password. I used to recommend it to everybody and switched multiple employers to it. Now I actively recommend against it. It wasn’t just abandoning native, somehow they make it worse with every release.
It is sad how far 1Password has fallen. AgileBits used to be a Mac shop and 1Password was a great Mac application. One and a half decades later, they are slow to roll out a fix for what was their initial platform (paying Mac users made them big). Also, it has become insanely buggy. Like autofill breaks for weeks for me every now and then, usually the extension is not able to connect to the 1Password app anymore (rebooting, clearing caches, adding/removing the browser extension, etc. does not help).
I still have a subscription because the whole family uses it and I don't know yet where else to go. There are some native apps, but they are fairly incomplete. Apple passwords would be an option, but I would like to be able to access my passwords on a Linux laptop as well, and Apple passwords does not really have a good backup story.
AgileBits' reaction to criticism is just to wave everything away with a bunch of emoji.
tl;dr: it went from an app that I loved and recommended to everyone to one to one that I would really like to get rid of and never recommend anymore.
I still have a subscription because the whole family uses it and I don't know yet where else to go. There are some native apps, but they are fairly incomplete. Apple passwords would be an option, but I would like to be able to access my passwords on a Linux laptop as well, and Apple passwords does not really have a good backup story.
AgileBits' reaction to criticism is just to wave everything away with a bunch of emoji.
tl;dr: it went from an app that I loved and recommended to everyone to one to one that I would really like to get rid of and never recommend anymore.
I'm a little shocked, as my experience with 1Password across Android, iPad, Linux, macOS, kubernetes, commandline has been absolutely fantastic. I've been using it every day for the last four years or so in pretty much all of the above settings.
I’m seriously considering switching off just because I hate how complicated their app has become. But I’m not a heavy user of stuff like safe documents, ID Cards, etc so it simply adds clutter and extra taps to get to the account passwords that I want.
And obviously everything you stated as well is a disappointment.
And obviously everything you stated as well is a disappointment.
I think you can seriously improve your UX, because I don’t have any extra tap to access passwords, definitely not because of ID cards or the likes. I just search for any item (no matter what category) or it is already suggested and I don’t have to search.
I genuinely don’t mean this in a condescending way, but you must use it wrong or have a wrong setting somewhere.
I genuinely don’t mean this in a condescending way, but you must use it wrong or have a wrong setting somewhere.
My main gripe is with the iOS app. I actually think the Mac version is easy to use still and don't have that many issues with it. But on iOS, it starts on Home and if I don't already have the site favorited and can't remember the name of the website, that's 2 additional taps to get to a list of all passwords - Items in the bottom tab and then either All Items or my Personal vault - and then I can start scrolling through to find what I'm looking for. Obviously if I'm already on the site for autofill or it's something basic like Gmail, Microsoft, etc then I have no problem searching. But sometimes I search for sites that I used years ago and can't remember the name.
Actually I really disliked electron but 1Password showed me it can be done right.
I still prefer native, but the argument of smaller code base for security reasons is a valid one.
I still prefer native, but the argument of smaller code base for security reasons is a valid one.
I've been using 1P since version 6 and I do miss the native app and I was sceptical of the transition to Electron. But for the most part it has been pretty decent, it does its thing and gets out of my way for the most part, haven't felt any performance regression (even the one stated in this post). I don't even know if/what things are getting worse every release.
Truly sad, if I remember they were still migrating to SwiftUI for their iOS app.
I have an app which almost shares the same SwiftUI codebase with iOS and macOS, and I am a one-man dev. If I can do it, I believe these million dollar company can also.
I have an app which almost shares the same SwiftUI codebase with iOS and macOS, and I am a one-man dev. If I can do it, I believe these million dollar company can also.
SwiftUI is still broken for any non-simple apps, almost a decade after its introduction. Completely unacceptable for big apps. Look at OmniFocus, who inexplicably became early-adopters of it, and it's had a bunch of UI glitches and inconsistent behavior requiring app restart (like you select one list item, but the inspector shows you details for another list item) ever since.
Apple only has itself to blame for Electron's popularity.
Apple only has itself to blame for Electron's popularity.
[deleted]
> almost a decade after its introduction.
It was released in 2019, so 6 years ago at most.
> Apple only has itself to blame for Electron's popularity.
+ Microsoft with their inability to decide on a single UI framework/API for more than 1.5 years.
It was released in 2019, so 6 years ago at most.
> Apple only has itself to blame for Electron's popularity.
+ Microsoft with their inability to decide on a single UI framework/API for more than 1.5 years.
My bad, I recalled 2017 for some reason.
And of course, same problem on Windows.
And of course, same problem on Windows.
I am a one-man dev. If I can do it, I believe these million dollar company can also
They could if they wanted to. Heck, they have so many developers and money, they could even maintain a separate Cocoa app. But in all these cases, they'd rather externalize cost to the user.
Sadly, for many of these Electron apps, it would probably be better to install the iOS app, but most vendors disable that option.
They could if they wanted to. Heck, they have so many developers and money, they could even maintain a separate Cocoa app. But in all these cases, they'd rather externalize cost to the user.
Sadly, for many of these Electron apps, it would probably be better to install the iOS app, but most vendors disable that option.
> I have an app which almost shares the same SwiftUI codebase with iOS and macOS, and I am a one-man dev.
How do you crusade through Apple's appalling [lack of] documentation and dumb error messages and all the weird ＊magic＊ involved in wrangling an imperative language into a declarative framework?
5 years after SwiftUI's release I still struggle to build a simple photo viewer or expense tracker.
> Sadly, for many of these Electron apps, it would probably be better to install the iOS app, but most vendors disable that option.
If companies enabled the flag to let users install their iOS apps on Mac, it would be a better world, but some asinine companies refuse to, and Apple has to respect the dev's decision, however dumb it may be. I love how Apple worked around that by making iPhone Mirroring, which is a win for users. I actually use that over the desktop website/Electron crap for some apps. But how long before companies force Apple to remove that feature, like they did with removing an easy way to "Disable Javascript" from Safari?
How do you crusade through Apple's appalling [lack of] documentation and dumb error messages and all the weird ＊magic＊ involved in wrangling an imperative language into a declarative framework?
5 years after SwiftUI's release I still struggle to build a simple photo viewer or expense tracker.
> Sadly, for many of these Electron apps, it would probably be better to install the iOS app, but most vendors disable that option.
If companies enabled the flag to let users install their iOS apps on Mac, it would be a better world, but some asinine companies refuse to, and Apple has to respect the dev's decision, however dumb it may be. I love how Apple worked around that by making iPhone Mirroring, which is a win for users. I actually use that over the desktop website/Electron crap for some apps. But how long before companies force Apple to remove that feature, like they did with removing an easy way to "Disable Javascript" from Safari?
> How do you crusade through Apple's appalling [lack of] documentation and dumb error messages and all the weird ＊magic＊ involved in wrangling an imperative language into a declarative framework?
That's the benefit of a solo dev, one I don't have a UI/UX designer over-designing shit and secondly I stay close to SwiftUI's components, if I can't customized my own Picker then who cares.
I don't know but there's a lot of decent blogs and tutorials in SwiftUI nowadays.
That's the benefit of a solo dev, one I don't have a UI/UX designer over-designing shit and secondly I stay close to SwiftUI's components, if I can't customized my own Picker then who cares.
I don't know but there's a lot of decent blogs and tutorials in SwiftUI nowadays.
What about windows, Linux, etc.?
Just 2 weeks ago, I saw my coworker close 1password from the activity manager to free more memory, because it was using 16gb of ram.
It just means they haven't updated Electron since last week.
They mean just being Electron at all, I imagine.
you mean even with all that telemetry of opening apps they couldnt test the most used apps and frameworks/electron for bugs?
Surely this will shame them into supporting MacOS better and not push developers towards making their desktop webapp a website.
Or just dropping macOS support altogether...
The issue is already fixed upstream in electron, it was due to the overriding of an internal/undocumented system function behaving differently by the nature of just being overridden at all (the function body was empty).
Either solution is an improvement over the laggy electron app. Using Safari's web app feature on discord's website feels markedly better than trying to use their "native" app.
I just reformatted my MacBook and I was hesitant to reinstall the discord app because of how terrible it is. That sounds like a good compromise I never thought of considering discord is more of a windows PC thing for me. Thanks.
People keep saying they need Electron because keeping up with the system's native web view is impossible yet a bunch of these apps have web versions that work perfectly fine (or as you say, even better) in Safari
There's a better way - you can find all apps you really should care about, i.e., the ones you have installed locally - run the last script in a comment of the Gist [0].
Update: It appears that the author of shamelectron was influenced by the same Gist [1].
[0]: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
[1]: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
Update: It appears that the author of shamelectron was influenced by the same Gist [1].
[0]: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
[1]: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...
Thanks for the mention! Yes, I was the person who found the original bug in electron and made the PR to get it fixed. Now doing my due diligence of (nicely) asking companies to update their versions :)
Thank you very much!
Some notable apps without fixes (which I have installed locally):
* 1Password.app
* Bruno.app
* Claude.app (oh noes!)
* Cursor.app
* Docker.app
* Dropbox Dash.app
* Dropbox.app
* Element.app
* GitKraken.app
* Graphite.app
* HEY.app (shame on DHH!)
* Keeper Password Manager.app (it's not just 1Password)
* Keybase.app
* Kiro.app (come on, AWS!)
* Ledger Live.app (crypto seems to lag behind Web 2.0 still!)
* Loom.app
* Notion Calendar.app
* Notion Mail.app
* Notion.app
* Pocket Casts.app
* Podman Desktop.app
* Proton Mail.app
* Proton Pass.app (all major password manager apps are in trouble)
* Redis Insight.app
* Sculptor.app
* Simplenote.app (shame on photomatt!)
* Texts.app (although it's possibly now replaced by Beeper)
* Tonkeeper.app
* Windsurf - Next.app
* WorkFlowy.app
* itch.app
* krisp.app
* 1Password.app
* Bruno.app
* Claude.app (oh noes!)
* Cursor.app
* Docker.app
* Dropbox Dash.app
* Dropbox.app
* Element.app
* GitKraken.app
* Graphite.app
* HEY.app (shame on DHH!)
* Keeper Password Manager.app (it's not just 1Password)
* Keybase.app
* Kiro.app (come on, AWS!)
* Ledger Live.app (crypto seems to lag behind Web 2.0 still!)
* Loom.app
* Notion Calendar.app
* Notion Mail.app
* Notion.app
* Pocket Casts.app
* Podman Desktop.app
* Proton Mail.app
* Proton Pass.app (all major password manager apps are in trouble)
* Redis Insight.app
* Sculptor.app
* Simplenote.app (shame on photomatt!)
* Texts.app (although it's possibly now replaced by Beeper)
* Tonkeeper.app
* Windsurf - Next.app
* WorkFlowy.app
* itch.app
* krisp.app
What is that? Like 32x >100MB junk overhead per app? ~4GiB gone from the disk just to hold the same broken copy of some framework/library? It's quite the insanity, isn't it?
If there was one copy of that electron (e.g. installed to /Library somewhere) which all apps would simply use then you only would need to update one copy. Less disk space wasted. All apps fixed in one go.
Back in the old days on the Commodore Amiga we would just do that… install some .library to SYS:Libs/ first if a program required it. It's not like this process was so complicated nobody could do it, right?
If there was one copy of that electron (e.g. installed to /Library somewhere) which all apps would simply use then you only would need to update one copy. Less disk space wasted. All apps fixed in one go.
Back in the old days on the Commodore Amiga we would just do that… install some .library to SYS:Libs/ first if a program required it. It's not like this process was so complicated nobody could do it, right?
>It's not like this process was so complicated nobody could do it, right?
Don't underestimate the utility of write once run anywhere. Needing to ensure compatibility with a bunch of different browser engines is not simple.
Don't underestimate the utility of write once run anywhere. Needing to ensure compatibility with a bunch of different browser engines is not simple.
Ironically Microsoft had exactly this in 1999 with Internet Explorer 5:
- https://en.wikipedia.org/wiki/HTML_Application
- https://www.geoffchappell.com/studies/windows/ie/mshtml/clas...
- https://en.wikipedia.org/wiki/HTML_Application
- https://www.geoffchappell.com/studies/windows/ie/mshtml/clas...
There is not one Electron. There are multiple, they release a new version every month or so.
Some apps, like VS Code, update very quickly to the latest one. Others more rarely. So now you need to keep multiple shared Electron versions, and track dependencies and who uses what version.
And it's quite likely that everyone of your Electron using apps will be on a different version, so now you are back to square one.
Some apps, like VS Code, update very quickly to the latest one. Others more rarely. So now you need to keep multiple shared Electron versions, and track dependencies and who uses what version.
And it's quite likely that everyone of your Electron using apps will be on a different version, so now you are back to square one.
[deleted]
4gb seems quite small for all of those apps to be honest.
No F shared libraries. Seriously.
Memory and storage is cheap enough nowadays to not have to deal with the insanity that shared libraries cause. I don’t care if I use 30gb of memory to run a browser and a note taking app.
Memory and storage is cheap enough nowadays to not have to deal with the insanity that shared libraries cause. I don’t care if I use 30gb of memory to run a browser and a note taking app.
Some of us do care. Devs should respect users systems more than their own instead of crapping all over them with Electron. I’d almost go as far as to say that it’s evil. Wasting resources, energy, people’s time, and money.
I don't understand why it's all-or-nothing. We know how to version things pretty well these days, why is there no blended solution where libraries are shared but version aware? I don't mind having two different versions of electron on my laptop but I don't want 30 copies of the same version.
You're basically describing Nix.
The big issue I see with Nix is that it's solving several related & very complex problems, and isn't doing so at a particularly easy level of abstraction. It's a PITA to package software that isn't using an already-supported build system. And mixing versions is messy, instead of just `[ package1="versionA", package2="versionB", …]` sort of thing with a lockfile to convert versions to immutable IDs like commit hashes you have to specify which commits of nixpkgs had each version and then do something like `nixpkgs-versionA=GIT_COMMIT_HASH_A; nixpkgs-versionB=GIT_COMMIT_HASH_B; [ nixpkgs-versionA.package1, nixpkgs-versionB.package2, …]`. There are lots of other "warts" like that, of varying levels of annoyance.
The big issue I see with Nix is that it's solving several related & very complex problems, and isn't doing so at a particularly easy level of abstraction. It's a PITA to package software that isn't using an already-supported build system. And mixing versions is messy, instead of just `[ package1="versionA", package2="versionB", …]` sort of thing with a lockfile to convert versions to immutable IDs like commit hashes you have to specify which commits of nixpkgs had each version and then do something like `nixpkgs-versionA=GIT_COMMIT_HASH_A; nixpkgs-versionB=GIT_COMMIT_HASH_B; [ nixpkgs-versionA.package1, nixpkgs-versionB.package2, …]`. There are lots of other "warts" like that, of varying levels of annoyance.
Because in practice nobody has solved it, while everyone claims they have.
In practice every software needs a particular version of a library. Even a minor upgrade to that library might, and will break it. In an idealized world it should not happen, but here we are. In a world that we setup whole containers so that we can run software.
So no. Shared libraries do not work in practice. At all. It should be straightforward, but they just do not work.
In practice every software needs a particular version of a library. Even a minor upgrade to that library might, and will break it. In an idealized world it should not happen, but here we are. In a world that we setup whole containers so that we can run software.
So no. Shared libraries do not work in practice. At all. It should be straightforward, but they just do not work.
No shit. One major frigging selling point of Electron vs OS web view is the developer controls the browser version and has a stable target to develop and test against, rather than having many moving targets that shift after the app is shipped.
And you really think the entire ecosystem has never heard of this honking great idea named shared libraries from the good old days? Being smug about obvious things like this usually just betrays your shallow understanding.
Disclosure: I’ve criticized Electron aplenty. But these are complex tradeoffs and people dismissing them with obvious wins in their minds are clueless.
Disclosure 2: I was once a member of the maintainer team of a major package manager. Shared libraries, oh my, I can tell you horror stories all night long. If your experiences with them are great chances are a team behind the scenes has blocked and/or fixed faulty updates for you and shielded you from most of the issues.
And you really think the entire ecosystem has never heard of this honking great idea named shared libraries from the good old days? Being smug about obvious things like this usually just betrays your shallow understanding.
Disclosure: I’ve criticized Electron aplenty. But these are complex tradeoffs and people dismissing them with obvious wins in their minds are clueless.
Disclosure 2: I was once a member of the maintainer team of a major package manager. Shared libraries, oh my, I can tell you horror stories all night long. If your experiences with them are great chances are a team behind the scenes has blocked and/or fixed faulty updates for you and shielded you from most of the issues.
I find explaining browser defaults to non web-devs really eye opening for them.
The number of major companies doing half-assed javascript bullshit instead of proper native macOS apps is ridiculous. This did remind me to go cancel 1Password though, something I'd been meaning to do since they switched _to_ electron...
I'm switching away from 1Password as soon as v7 stops working. I use v8 on my work machine and it's a serious downgrade and AgileBits' handling of criticism around it has been just as bad.
Ditto. Happily using 7, but if they ever break it I’m switching to Apple Passwords.
I did that last year and haven’t looked back. And I can share passwords with my family without paying an arm and a leg.
Pity. I used 1P for many, many years and recommended it to everyone I knew. I feel like it’s completely lost the plot, though.
Pity. I used 1P for many, many years and recommended it to everyone I knew. I feel like it’s completely lost the plot, though.
It's actually shocking to see 1pass use electron. They had great first party support but that explains why the app has been absolute garage post v7.
Both MS and Apple have screwed up. WinUI3 is simply terrible and SwiftUI is a horrible headache. Is there any wonder that people are mass migrating to web frameworks ?
It’s not surprising, but the reason it isn’t surprising is abject lack of respect for users rather than framework complexity.
Meh. VSCode is a fantastic piece of software, one I never had a problem with before Tahoe.
Compared to what?
I find it telling that the original creators of electron are now writing a new editor with native code because even they can’t stand electron. It’s like they are trying to write a wrong they did to the world.
I find it telling that the original creators of electron are now writing a new editor with native code because even they can’t stand electron. It’s like they are trying to write a wrong they did to the world.
Xcode, Visual Studio (the original I mean), PyCharm et al., Eclipse, vim, emacs, Notepad++, Sublime… hmm that’s all the IDEs and text editors I can remember using significantly in a professional context. I prefer VSCode to those.
compared to... nothing... I love it. It's subjective. I love what it does and it's my favorite piece of software because it does what i need it to do, every time, all the time.
That's what happens when people use private APIs... there's no problem until there is.
Wise, applies to every piece of software on earth.
It is, true, but Zed is getting better and better every day!
Still not half of vim or a quarter of emacs.
Love my 1985 Chevy and my 2025 (insert not very hated auto make here). Each has its uses
An entire browser runtime for a password manager are you kidding me. It’s upside down world.
[deleted]
Hey - "Shame" is somewhat stronger than what I would have said but I also had similar feelings considering it was from DHH's company. And not just for outdated Electron, but for shipping Electron in the first place. For some reason I always felt DHH will write native apps for his company :)
I have absolutely lost hope from Dropbox and I am actively looking for a replacement.
BitWarden using Electron is just unfortunate and it is sluggish.
What happened to 1Password (don't use it, never did) and their Apple only-great-native-software trope I used to hear? Cost cutting?
Electron is the reason I am still using Overcast and not Pocket Casts even though it's FOSS.
Proton Mail - this app is such a mess!
Simplenote - moved away long back! When did Electron come into it? It was native, wasn't it?
I have absolutely lost hope from Dropbox and I am actively looking for a replacement.
BitWarden using Electron is just unfortunate and it is sluggish.
What happened to 1Password (don't use it, never did) and their Apple only-great-native-software trope I used to hear? Cost cutting?
Electron is the reason I am still using Overcast and not Pocket Casts even though it's FOSS.
Proton Mail - this app is such a mess!
Simplenote - moved away long back! When did Electron come into it? It was native, wasn't it?
> What happened to 1Password (don't use it, never did) and their Apple only-great-native-software trope I used to hear? Cost cutting?
They started chasing B2B/corporate, and as part of that switched their desktop app over to Electron and replaced the old UI of 7 with a generic flat blobby SaaS type design. They lost their botique app shop feel and now blend in with the usual greasy SaaS fare.
They started chasing B2B/corporate, and as part of that switched their desktop app over to Electron and replaced the old UI of 7 with a generic flat blobby SaaS type design. They lost their botique app shop feel and now blend in with the usual greasy SaaS fare.
Update: Meanwhile, Podman Desktop got fixed!
[deleted]
> * HEY.app (shame on DHH!)
There are much better reasons to shame DHH.
There are much better reasons to shame DHH.
How does the Electron alternative Tauri perform on macOS 26 Tahoe?
No issues. There was a very specific bug in electron that's now fixed.. now we just wait until companies bump the electron versions
A couple not on the list:
OpenMTP.app (Electron 18.3.15)
DiffusionBee.app (Electron 13.6.9)
OpenMTP.app (Electron 18.3.15)
DiffusionBee.app (Electron 13.6.9)
Oof, those are some ancient electron versions.
If you go back far enough, they just don't have the issue at all! Running your "detect using cornerMask" script from another comment in this post, I have an app (https://www.haikuanimator.com/) that shows up green… because it's using Electron 2.0.8!
Thats fair, I guess. But running an electron app that out of date is just playing with fire. You know, with the couple hundred chromium and electron CVE's and all :/
I see, sorry to waste your time. I thought the list was meant to be informational for people to assess which applications were problematic. I didn't realize it was more of a call to action.
not at all! thanks for the callouts, i'm sure people who have those installed will find the headsup helpful!
In general the Tahoe update has been awful for all my end users that decided to update.
It's not just electron apps that are the issue btw, just yesterday we ran into an issue with Zoom.
It was breaking prompts/popups and by extension the system settings, the Mac app store, iTouch, and a ton of other random stuff was broken in silent and inconsistent ways.
Also all my 8gb users are noticing significantly higher memory usage compared to their previous macOS versions.
It's not just electron apps that are the issue btw, just yesterday we ran into an issue with Zoom.
It was breaking prompts/popups and by extension the system settings, the Mac app store, iTouch, and a ton of other random stuff was broken in silent and inconsistent ways.
Also all my 8gb users are noticing significantly higher memory usage compared to their previous macOS versions.
I suggest that everyone here stop submitting Feedback Assistant/Radar reports. Let teenagers, college students, adults and old people buy a new Mac, experience the bugs and lack of polish and let it affect Apple's brand, consumer's preferences, and their market behavior. Apple is too big to care about anything other than market consequences. Apple is fully aware that no one likes the Radar system, that no one feels their reports count, they had an executive do a sort-of mea culpa years ago but nothing changed.
My AirPods keep going silent on my new Tahoe Mac and require a disconnect and reconnect. Will I report it? No. (Besides, if you report bugs like that, Apple collects a map of your entire filesystem, every path and filename). Apple shouldn't have fired their QA team. Let them deal with any brand damage, they've earned it. I mean, did Apple really not test their new OS with Slack, Zoom or VSCode? Really? Reckless.
My AirPods keep going silent on my new Tahoe Mac and require a disconnect and reconnect. Will I report it? No. (Besides, if you report bugs like that, Apple collects a map of your entire filesystem, every path and filename). Apple shouldn't have fired their QA team. Let them deal with any brand damage, they've earned it. I mean, did Apple really not test their new OS with Slack, Zoom or VSCode? Really? Reckless.
>Apple is too big to care about anything other than market consequences.
I’d argue this applies to a very large proportion of companies out there, they don’t have to be huge to suffer from this affliction.
I’d argue this applies to a very large proportion of companies out there, they don’t have to be huge to suffer from this affliction.
They have like ~15% market share. Thats really tiny after all these years. I bet those people are mostly people who have been burned by Windows. What do you expect them to go to? Linux?
I find the stats vary wildly. I'm seeing it's up to 31% in the US [1].
https://www.computerworld.com/article/1624976/statcounter-da...
https://www.computerworld.com/article/1624976/statcounter-da...
Too many Apple users consider Apple to be holy and will blame app vendors for OS bugs.
When said app authors use a private library that a Apple asked them to not use, is it really wrong to blame them?
From a Windows end-user perspective, the entity to blame for apps breaking after a Windows upgrade is Microsoft, even if the app was doing something it should not have [0].
[0] Search for "return policy" on https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... .
[0] Search for "return policy" on https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... .
Apple is a fashion brand, and Apple users buy it for that reason, not because of any technical merit.
This was clearly a vendor bug though.
> I suggest that everyone here stop submitting Feedback Assistant/Radar reports.
We need an equivalent of the "Windows UX Taskforce” but for macOS/iOS (it was a website that pointed out and laughed at all the UI/UX flaws in Windows)
We need an equivalent of the "Windows UX Taskforce” but for macOS/iOS (it was a website that pointed out and laughed at all the UI/UX flaws in Windows)
The real problem is Apple being so stingy with RAM.
I have 192GB of RAM on my (non-Apple) desktop and 96GB of RAM on my (non-Apple) laptop. I have never had memory issues with Electron apps, 200 Chrome tabs open, or pretty much anything, really.
I have 192GB of RAM on my (non-Apple) desktop and 96GB of RAM on my (non-Apple) laptop. I have never had memory issues with Electron apps, 200 Chrome tabs open, or pretty much anything, really.
It's not a memory problem at all. It's the misuse of a private API that's at fault:
https://www.theregister.com/2025/10/02/macos_26_electron_slo...
https://www.theregister.com/2025/10/02/macos_26_electron_slo...
But if the "private API" was the only way of fixing an issue with rendering corner smoothing, was it "misuse"?
The developer who submitted the fix thinks so:
"I need to be clear about this, Electron's "_cornerMask" override was a dirty hack that was made in an effort to fix an ancient issue with corner smoothing."
https://github.com/electron/electron/issues/48311#issuecomme...
"I need to be clear about this, Electron's "_cornerMask" override was a dirty hack that was made in an effort to fix an ancient issue with corner smoothing."
https://github.com/electron/electron/issues/48311#issuecomme...
Apple does have a 128GB laptop with M4 Max.
It starts at 5000 USD. Five. Thousand. Dollars.
It is the fastest laptop CPU in the world right now, by a decent stretch.
128GB PC laptops are not very cheap either, if you want a decent one, like a ThinkPad.
Here’s a 7000 USD ThinkPad P16 Gen 2 workstation:
https://www.lenovo.com/us/en/p/laptops/thinkpad/thinkpadp/th...
128GB PC laptops are not very cheap either, if you want a decent one, like a ThinkPad.
Here’s a 7000 USD ThinkPad P16 Gen 2 workstation:
https://www.lenovo.com/us/en/p/laptops/thinkpad/thinkpadp/th...
>fastest laptop CPU in the world
Maybe, but it's 1) ARM 2) In a Mac. Those are some colossal caveats.
Maybe, but it's 1) ARM 2) In a Mac. Those are some colossal caveats.
What caveats specifically?
I understand the problems of measuring cross-platform performance but anecdotally even on things that it's not specifically optimized for, for example running a Java Virtual Machine with 10s of GBs of memory, it's really fast, efficient and competitive to most non-Mac/ARM setups.
I understand the problems of measuring cross-platform performance but anecdotally even on things that it's not specifically optimized for, for example running a Java Virtual Machine with 10s of GBs of memory, it's really fast, efficient and competitive to most non-Mac/ARM setups.
Not 128GB, but 96GB of SODIMM is <$300 on Amazon. Don't buy it from Lenovo.
Yep. Add a usable SSD to that and it'll be 7K.
I have 8TB in my laptop (cost $500) and 28TB total in my desktop (cost ~$2K) and before you start on it, yes I do use that much space.
These are unheard-of numbers for a middle class Apple owner, but commonplace for a middle class non-Apple owner.
Looking at the Apple website their offerings start from 0.25 TB. What a joke. My phone has that much.
I have 8TB in my laptop (cost $500) and 28TB total in my desktop (cost ~$2K) and before you start on it, yes I do use that much space.
These are unheard-of numbers for a middle class Apple owner, but commonplace for a middle class non-Apple owner.
Looking at the Apple website their offerings start from 0.25 TB. What a joke. My phone has that much.
Thanks.
It sounds like the issue has already been fixed in Electron, although it will obviously take a while for all app vendors to bump versions.
I'm guessing Zoom might be hitting the same overridden system call that Electron was, although I have no firm information that this is the case.
Regardless, I've just checked my settings to ensure this upgrade won't be installed automatically because I wasn't sure how MacOS behaves with major upgrades, and will probably wait 2 - 3 months before letting Tahoe onto my system to allow everyone else time to get their fixes and upgrades done.
It sounds like the issue has already been fixed in Electron, although it will obviously take a while for all app vendors to bump versions.
I'm guessing Zoom might be hitting the same overridden system call that Electron was, although I have no firm information that this is the case.
Regardless, I've just checked my settings to ensure this upgrade won't be installed automatically because I wasn't sure how MacOS behaves with major upgrades, and will probably wait 2 - 3 months before letting Tahoe onto my system to allow everyone else time to get their fixes and upgrades done.
Why do you install the Zoom app? Seems like only a way to collect data on you vs the web version that works just great.
The question is why the app is bad, not why users install it.
Web version doesn’t handle large amounts of participants in a single call, way back when I used zoom.
I used the web version last month for an inside town hall meeting with ~1k participants and it was as smooth as it could be.
cpursley(1)
Good that I went with 64 gigs for my last mac. But I'll wait for the first patch at least for this one.
I honestly can't figure out why people upgrade to the latest x.0.0 release of macOS. Wait for the x.1.0 : by that time Apple have fixed most of their bugs and software vendors have had time to do their side too.
Because they value secure devices. Apple don’t backport _all_ security patches.
The bad ones they do, especially early on.
The ones they don’t back port are usually dumb stuff like “if an attacker has root and has you at gunpoint, a flaw in wallpaperd may allow them to change your desktop background”
The ones they don’t back port are usually dumb stuff like “if an attacker has root and has you at gunpoint, a flaw in wallpaperd may allow them to change your desktop background”
In my experience of you're on currentVersion - 1 the security is just as good.
All I was saying is it's (imo) madness to upgrade immediately to the latest .0 version of macOS.
The long key press for diacritics is completely broken on Tahoe : white text on a white background.
All Electron apps are a bit broken until the vendors update.
There's probably more problems.
All I was saying is it's (imo) madness to upgrade immediately to the latest .0 version of macOS.
The long key press for diacritics is completely broken on Tahoe : white text on a white background.
All Electron apps are a bit broken until the vendors update.
There's probably more problems.
Depends when, before they hit the X.1.0, yes they do backport all security patches. I’d argue they actually do until .2.0, but that murkier.
Because Apple nags you to do that via OS popups
I must have the very secret iOS and macOS versions which specifically require major updates be selected for installation otherwise it only continues to offer the minor updates for my current version.
> It's not just electron apps that are the issue btw
Electron ""apps"" were are and will always be the issue.
Don't bundle a whole freakin web browser and ravish my battery and RAM just to show me a damn text box.
A text box that won't even have all the built-in OS features or accessibility.
Downvote this to hell but Electron is a crutch for lazy Frankensteins looking for lightning to revive a monster that should have stayed dead.
Electron ""apps"" were are and will always be the issue.
Don't bundle a whole freakin web browser and ravish my battery and RAM just to show me a damn text box.
A text box that won't even have all the built-in OS features or accessibility.
Downvote this to hell but Electron is a crutch for lazy Frankensteins looking for lightning to revive a monster that should have stayed dead.
Dev UX is important, and the dev UX of Electron is pretty much unmatched.
If you want people to not use Electron, you'll need to provide an alternative that makes it just as easy to develop sophisticated, platform-independent applications. Otherwise, no amount of complaining about Electron will ever stop devs from using Electron.
If you want people to not use Electron, you'll need to provide an alternative that makes it just as easy to develop sophisticated, platform-independent applications. Otherwise, no amount of complaining about Electron will ever stop devs from using Electron.
Dev UX is only good in that we regressed to the point that there's not much left but Web, and that's what the majority of devs know as a result. The Dev UX of the Web is pretty bad, though, compared to past and present alternatives, and I'm far from having as much fun putting together UXes for the Web as I was with older tech like Qt, Swing, JavaFX, etc (the tooling was better, more efficient, they had builders for rapid prototyping that were offering a more faithful representation of the design more quickly than figma ever will, etc).
I've used Qt, Swing and JavaFX, and found all of them absolutely terrible. Qt might have at least led to some good results, but it's fairly bad to use and deploy. Especially if you want to use the latest Graphics APIs, which worked pretty badly back when I last used Qt in 2016. I much prefer Electron, or imgui for C++. I'll happily sacrifice some features so long as I dont have to use Qt.
> Qt might have at least led to some good results
You seem to focus on the outcome while what interests me is the programming model. Say what you want about object-oriented programming, the problem-space lends itself very well to it. In Qt/Swing/… components are just classes whose behaviour and appearance are determined by function overrides, taking as parameter event or graphics objects. Just like that, you cleanly solve everything that "webcomponents" stands for: interface contracts are determined by class constructors/parameters, customisation is just class inheritance with member override, look&feel customisation is plain calls into the graphics API primitives, layouting/responsive-design is taken care of at the just level of abstraction, and all of it takes place in the same language and ecosystem/stdlib (no HTML to CSS to JS references to keep in sync and mental overhead).
React reproduces some of this model, but with much more technical and mental complexity, bringing trade-offs of its own. I'm not calling this easier to work with, simpler, or easier to debug. It certainly gives more creative options, but only because the ecosystem is broader (and full of supply-chain risks).
You seem to focus on the outcome while what interests me is the programming model. Say what you want about object-oriented programming, the problem-space lends itself very well to it. In Qt/Swing/… components are just classes whose behaviour and appearance are determined by function overrides, taking as parameter event or graphics objects. Just like that, you cleanly solve everything that "webcomponents" stands for: interface contracts are determined by class constructors/parameters, customisation is just class inheritance with member override, look&feel customisation is plain calls into the graphics API primitives, layouting/responsive-design is taken care of at the just level of abstraction, and all of it takes place in the same language and ecosystem/stdlib (no HTML to CSS to JS references to keep in sync and mental overhead).
React reproduces some of this model, but with much more technical and mental complexity, bringing trade-offs of its own. I'm not calling this easier to work with, simpler, or easier to debug. It certainly gives more creative options, but only because the ecosystem is broader (and full of supply-chain risks).
I'm not a dev (by profession). I don't care about the you-ecks of developers. Electron creates objectively terrible software by every metric that matters for the end user.
>sophisticated
You confuse complexity for sophistication.
>sophisticated
You confuse complexity for sophistication.
Objectively wrong. Bad programmers create terrible software. Electron was used for some fantastic software like vscode.
You sort of have a point, but users shouldn't have to pay the price for better UX for devs, the companies making operating systems should.
Even non-power users pay the cost, they just don't realize it yet.
But as long as users still need Apple/Microsoft/Google's platforms to be able to run Electron apps, those corps won't care, specially if it takes devs away from the toolchains controlled by them.
Maybe if someone can come up with a pure Electron OS that can run on any device, it might force Windows/Apple/Android to agree on a universal native UI API?
Even non-power users pay the cost, they just don't realize it yet.
But as long as users still need Apple/Microsoft/Google's platforms to be able to run Electron apps, those corps won't care, specially if it takes devs away from the toolchains controlled by them.
Maybe if someone can come up with a pure Electron OS that can run on any device, it might force Windows/Apple/Android to agree on a universal native UI API?
Do you even know how much a modern electron app with tree shaking actually uses?
Most of my electron apps fully packaged are less than 100mb.
Most of my electron apps fully packaged are less than 100mb.
Related, three days ago:
Detect Electron apps on Mac that hasn't been updated to fix the system wide lag - https://news.ycombinator.com/item?id=45437112 - Oct 2025 (114 comments)
Detect Electron apps on Mac that hasn't been updated to fix the system wide lag - https://news.ycombinator.com/item?id=45437112 - Oct 2025 (114 comments)
This performance issue aside, which I haven’t noticed, a friend recently commented about the quality of Apple’s native apps that he would strongly prefer an Electron app for all of them because it’s a sign that they might actually work in an understandable way and not be totally broken all the time.
The fact that an application can slow down the system doesn't sound like a problem with the application, but rather it's a problem with the OS. Tracking applications that "are not fixed" is not the solution. Fixing the OS is the solution.
Otherwise I would be inclined to agree with you, but in this specific case I'm torn. These apps (ab)used a private API and the OS update meant they suddenly used it incorrectly. That's not something that's really the OS fault as far as I'm concerned. But I do agree that better separation is always good.
Historically Windows was known for not causing this kind of breakage for even “(ab)users” of private APIs, common misusers, buggy users, etc. And even working around such issues on the OS side.
Yeah, Windows is actually known for bending the OS so that backward compatibility is preserved. They even added a GUI tab with Compatibility settings.
But of course, Apple is not Microsoft, so they can do whatever they please. On Apple systems, non-working software on new macOS releases is a normal thing, maybe part of their philosophy.
But of course, Apple is not Microsoft, so they can do whatever they please. On Apple systems, non-working software on new macOS releases is a normal thing, maybe part of their philosophy.
>Windows is actually known for bending the OS so that backward compatibility is preserved
Such as... having two context menus ;)
Such as... having two context menus ;)
In this case Electron intentionally used reflection to override functionality that isn't part of the API surface, so maybe not as cut and dried as all that
Framework developers need to have a much higher standard for when to use a private API.
But I also think Apple should do more testing with Electron and proactively contribute these fixes. Scanning the framework for private API usage is easily doable for them. If Apple had sent this fix in June when they released the first beta of the new OS, it would have made it into most of these apps.