Track which Electron apps slow down macOS 26 Tahoe(avarayr.github.io) |
Track which Electron apps slow down macOS 26 Tahoe(avarayr.github.io) |
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.
At some point, the current situation is to be expected. It’s ok. Electron apps will be fixed and it will be all right.
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 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.
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.
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.
Most of my electron apps fully packaged are less than 100mb.
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.
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)
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 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.
https://www.theregister.com/2025/10/02/macos_26_electron_slo...
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...
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)
OpenMTP.app (Electron 18.3.15)
DiffusionBee.app (Electron 13.6.9)
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 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.
Apple only has itself to blame for Electron's popularity.
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.
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?
* 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
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?
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?
There are much better reasons to shame DHH.
Try learning more than 1 language for everything.
(not directed personally @ anyone, just a peeve at the many factors enabling the necessity of something like Electron)
[0] Search for "return policy" on https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... .
https://www.computerworld.com/article/1624976/statcounter-da...
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.
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.
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.
And of course, same problem on Windows.
And obviously everything you stated as well is a disappointment.
I genuinely don’t mean this in a condescending way, but you must use it wrong or have a wrong setting somewhere.
I still prefer native, but the argument of smaller code base for security reasons is a valid one.
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.
Such as... having two context menus ;)
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”
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.
"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...
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).
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?
>sophisticated
You confuse complexity for sophistication.
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...
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 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.
Don't underestimate the utility of write once run anywhere. Needing to ensure compatibility with a bunch of different browser engines is not simple.
- https://en.wikipedia.org/wiki/HTML_Application
- https://www.geoffchappell.com/studies/windows/ie/mshtml/clas...
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.
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.
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.
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.
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.
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.
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.