Detect Electron apps on Mac that hasn't been updated to fix the system wide lag
gist.github.com136 points by tomaskafka 5 hours ago
136 points by tomaskafka 5 hours ago
Running this made me realize that Ollama GUI is about 15 versions out of date. I'm not sure how often you are supposed to update your Electron package, but seems like it should be more often than that.
I have Version 0.12.3 which seems to be the most recent release: https://github.com/ollama/ollama/releases/tag/v0.12.3
It doesn't show up with a laggy Electron version.
I didn't use homebrew, but that version is also up-to-date: https://formulae.brew.sh/cask/ollama-app
I just checked latest Ollama and it seems to be native (or at least not electron).
The Ollama Mac app has essentially not changed since early 2024: https://github.com/ollama/ollama/commits/main/macapp
Electron team backported the fix to 2 previous versions, so that’s some datapoint about what they think people should be using.
Thats fine, but i have plenty of electron apps on absolutely ancient versions of the library that I don't expect will be fixed anytime soon. This is why you don't use private apis.
For a static analysis approach, I wrote a NPM package called which-electron: https://github.com/captn3m0/which-electron
It uses an automatically update package listing the hashes of all files in electron releases: https://github.com/captn3m0/electron-fingerprints
I’ve been meaning to improve the detector to use ELF info.
Thank you, but I'd like to keep it simple, and we only need to detect electron apps and extract version from last 4 versions.
Is there any kind of list somewhere of similar MacOS tweaks you can do to increase performance? When I'm using my Mac for work I don't care about anything except pure perf. Can we turn off animations? Fancy rendering? Background indexing? Other stuff?
I can’t live without Dock appearing without delay:
Show dock instantly:
defaults write com.apple.Dock autohide-delay -float 0.0001; killall Dock
Undo:
defaults delete com.apple.Dock autohide-delay; killall Dock
The only Electron app that is showing the green light is Siyuan which they updated today. Everything else if affected. But most important I deleted some apps I don't know why I was keeping.
In all those years Electron still did not manage to separate runtime from applications, so updates would be smaller and security fixes would reach all applications much faster.
So happy I haven’t updated yet. I always wait a few months for things like this to get fixed.
Monitoring Chromium CVE patches is a good way to find N-days in Electron apps based on unpatched versions of Chromium.
I was quite a bit surprised how old versions are used even in software like Cursor that's updated almost daily.
Wait... Resolve uses Electron? It's not for the main GUI, is it?
When I do scripting for resolve the UI API feels a lot like QT. Unless they made a very QT-like wrapper around JavaScript code.
I wonder if instead there's small parts that are done in electron but most of it is qt
My guess would be that they wrapped the help/docs website into an Electron view.
Doesn't QT have a webview component though? Why bring in the full weight of Electron?
what else would it be for? it makes sense they'd look for a way to use something that could use the same code on all platforms. never thought it would be electron though. it does look too polished to be a qt type of build though
> what else would it be for?
Could be for a small part of the UI, for example the start page / project selection thing.
that over the top annoying screen that gets dismissed as quickly as possible requires the weight of running electron on top of the heft of the actual program? ::face-palm:: if the entire UI was using electron, that would be one thing. but if as you suggest it is just a bolt on for a splash screen, ¡ay caramba!
before updating docker desktop:
X Docker.app: Electron 34.5.4 (Contents/MacOS/Docker Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)
X Docker.app: Electron 37.2.6 (Contents/MacOS/Docker Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)I always refuse to use their official desktop app, I'm not making an account / scrambling to remember my username / password, for the one time in a blue moon I need docker to evaluate a piece of software.
Nobody forces you to log in when using docker desktop. Perfectly usable without an account, unless you want to push images to their registry.
That must have changed recently, it always asks me to login and I dont keep any images on their registry, that or they present it as a dark pattern where the option to NOT login is non-obvious. Even so, I'll stick to just not using Docker, I never have any use cases for it outside of as I said, evaluating software that requires it for whatever awful reason.
Has anyone been able to confirm if the macOS 26.1 developer beta is affected? I updated to it pretty quickly and haven't been able to reproduce the lag on it.
Msty.app LM Studio.app ComfyUI.app Signal Beta.app Poe.app Visual Studio Code.app Trae.app Obsidian.app Kiro.app
That haven't been updated.
Sigh
Source title is "Detect Electron apps on mac where the Electron hasn't yet been updated to fix the system wide lag" which is also quite wordy.
Microsoft Azure Storage Explorer
Big shock.
[flagged]
Delete the lines that are checking for specific version, and just report all of them, and you can :D
That’s another use for the script :) - it lists all of them, but none shows the green check so far.
I cleaned a few as well.
mdfind "kMDItemCFBundleIdentifier == 'electron'"
edit: that missed some of them. This works better:
find /Applications -name "Electron Framework.framework" 2>/dev/null | sed 's|/Contents/Frameworks/Electron Framework.framework||'
vscode
spotify
slack
discord
figma
microsoft teams
postman
signal
chrome?
good luck!
Very funny to call Chrome an electron app. For the sake of words meaning things, it isn't one.
Althought Electron uses the same core components as Chrome, the Chrome UI is not built with Electron.
strange, Teams is not on my list. Maybe you are not using "(new) teams (for business and school) v2 (new)"
Damn it I thought I had done then I remembered WhatsApp desktop. And then there were Tuta, Dropbox, BitWarden, ente - all turned up and all of them using outdated f/w as well.
Then I wondered - is WhatsApp Electron based? Not only it didn't turn up in the script result, I had heard they migrated to Catalyst and have the same iOS app running on Mac. Isn't that so?
Figma has an app? Wouldn't count chrome.
Yeah, the Figma desktop version is basically just a wrapper. It's okay but not super useful.
vscode signal mullvad balenaetcher
Im surprised whatsapp showed up for you, its not for me. I had thought whatsapp was a native app
Yes, they basically got the ios native version to also run for macs [0]. The perks of apple silicon I guess. It is a bit ironic how going to ARM architecture initially was initially thought of a burden for developpers having to maintain both x86 and ARM versions, while as it turns out, for those who target both ios and macos it makes it easier.
I am not sure if the old electron-based whatsapp is still available, maybe the one from the website, vs the one from app store, is still electron?
[0] https://9to5mac.com/2024/09/04/whatsapp-discontinue-electron...
VS Code I have but never use, Discord I have, Teams only on work machine, and Signal.
Man I'm not doing too bad!
I prefer Zed over VS Code, or just flat out Visual Studio proper (2026 has gotten snappy!), as for Slack, I rarely use it, but I can use the browser, they are forcing non-profits out of Slack and into Discord anyway.
It's surprising and disappointing that Apple didn't catch a bug like this in QA. This affects popular apps, and many people will have at least one of these apps with outdated Electron frameworks.
It was Electron causing a shadow repaint, not Apple:
https://github.com/electron/electron/issues/48311#issuecomme...
Put it this way: if I were in charge of a major OS, and I having one of the major app frameworks used on my OS tested on for my annual upgrade, I'd feel pretty embarrassed, even if there's a figleaf excuse why it's not my fault.
This doesn't exactly instill confidence in Apple's competence.
Apple doesn't care, they know their users will eat anything they throw at them.
Electron used non-public pieces to workaround an issue with Apple code which Apple knew about and was not interested to address, now it's broken after it changed. Nothing new.
That's how you end up with windows.
This. Would it really be better if macOS accumulated workarounds for buggy apps?
if I were in charge of a major OS, and I having one of the major app frameworks used on my OS tested on for my annual upgrade
Each program contains its own version of Electron. How is Apple going to know the version of Electron your particular version of your particular app that you installed on one particular date perhaps years in the past works?
n apps in the world × n versions of Electron
The problem isn't Apple. It's that the developer of your program is using an outdated version of Electron, or it's put out an update and you haven't updated.
They only needed to test with the latest Electron at the time of release (or indeed, any chance version - they're all affected - but latest is a reasonable baseline). If they had, they would've seen this.
There are patches out now, but only after Apple released the OS to the entire team world and people reported the issue to the Electron team.
Imo, Electron is sufficiently popular that somebody should test at least one Electron app on a major new OS version sometime before releasing it as done! Any app would've worked, and there's plenty of popular ones, as this post shows.
There's just no way for Apple to maintain and run comprehensive test suites for all the different software platforms out there, even "popular" ones.
That's why they release betas early -- that gives each project an opportunity to run their own test suites, however comprehensive they may be.
It's a little hard to hold Apple responsible when there are a lot of app teams in a better position to catch this than Apple, and apparently none of them did.
(Maybe it was a late change in Tahoe? Still, no one found it in the RC either it seems.)
It only became an issue when Apple's update made it an issue. This is on Apple.
Why is it on Apple to make sure that their private APIs (as in you SHOULDN'T USE THEM, because they will change without regard to your software) are backward compatible?
It’s not on Apple. They explicitly warn developers not to do this because stuff exactly like this can happen. If it were an issue involving public APIs, then yes, it would be on Apple.
I get it. I’ve used private APIs in some of my Apple apps. But when you do, you take on a certain level of risk and responsibility when you’ve got customers.
The bigger question is why none of these Electron app developers, particularly larger outfits like Slack, didn’t catch this issue in the last 3 months they had access to Apple OS betas.
Do they have a QA process? Perhaps they should start.
For all we know, they could have filed radar issues with Apple months ago.
They could have, but the most likely response is "Do not use private APIs. They are not intended/ready for third-party developers yet."
Because ultimately Apple is making software for its users. Something that negatively affects their users experience is something they should factor in with new releases no matter whose "fault" it is. Such is the pain of making operating systems.
You're right in the purest sense: use a private API, get burnt. But when it's something this widely used and depended upon you could argue Apple should have made it into a public API by now.
It's on both. Apple should probably have caught this in beta considering how widespread Electron apps are, and have worked with Electron to fix it or they should've worked around it (which Microsoft would probably have done).
Electron updates already exist, it's the individual apps that need to update their version of Electron.
If they're not supposed to be used, why can they be used? Hyrum's law strikes again!
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (https://www.hyrumslaw.com/)
It's not surprising. It's sadly predictable that forced annual scheduled OS updates that must ship ready or not will ship when they're not ready.
Apple abandoned any commitment to QA as soon as they committed to mid-September becoming a magical date, practically written in stone.
What does Apple even get out of it? I don't think anyone is clamouring for new MacOS releases, so I can't imagine it drives hardware sales. MacOS is no longer a paid product either.
The regular update cadence and the lack of stability for developers sets an expectation that developers must be active (forever) or their product will stop working.
That way, they never have to deal with fallout from breaking a 20 year old program like Microsoft got for breaking whatever version of GTA. There's no way a 20 year old program still runs on current macos, so nothing to worry about.
I worked on some Mac security software. WWDC and that first macOS beta in June dictated whether we were going to spend the summer on features, or on compatibility with the new platform. There were a few crazy years, like file protection in Mojave, system extensions in Catalina, and Apple Silicon and other changes in Big Sur.
The Windows team never faced anything like this. Not only did Windows change slowly and with backward compatibility, but the users didn't upgrade right away, even if they were buying brand new laptops. But in the Mac world, a laptop bought in September/October is going to have the new macOS on it no matter what.
They even have to provide separate updates for people that refuse to jump on the latest and greatest - NOW WITH LOW CONTRAST - version.
Too bad their competition is worse. It's not like they're good any more.
Btw I just checked and the assholes preselect the update to Tahoe, not the update to 15.7.1.
I'm not sure. Perhaps Tim Cook just likes schedules, which fit naturally in his MBA brain. Or it could be that Apple previously set the expectation of annual releases and now can't stop, because getting off the update train would be a kind of indicator or admission to stockholders and the media that Apple is falling behind somehow. On the other hand, annual OS updates with updated system requirements would provide a convenient way to implement planned obsolescence of hardware.
In any case, Tim Cook clearly doesn't have the same standards as Steve Jobs did. Cook will never complain, "This is shit!" As Jobs reportedly lamented, Cook is a not a product person. So QA problems are not necessarily a problem for him. I suspect that Cook actually believes everything is mostly going well, and perhaps some "metrics" tell him so, though the metrics likely ignore the fact that developers have been disillusioned and alienated by Apple's hostile bug reporting system. If I thought Apple cared and would do something, I'd file literally thousands more bug reports.
it's been a while since you used macos? apple has completely stopped giving a shit, extremely basic functionality like spotlight and settings search have been completely broken for years now...
As a daily driver of MacOS, I've not notice anything being wrong with spotlight or settings. Is there something specific that is broken?
I use spotlight constantly for everything, but I admit I don't use the search feature in settings all that often.
It’s not uncommon for me after installing apps that spotlight wont find them for a while.
Unfortunately on machines doing a lot of software development, the various dependency cache locations need to be excluded from indexing, otherwise Spotlight is essentially doing full text search over millions of lines of code
For me newly installed apps from outside the Appstore are excluded from Spotlight until I manually open them and trigger the 3rd party “untrusted” confirmation dialog. After confirming with Open they show up.
Ironically, macOS 26 has a bunch of improvements for Spotlight, including a fix for this very issue.
MacOS 26 actually has some really great new features around Spotlight, from actions to clipboard history, and the heretofore-underloved Control Center has been really improved (and is clearly being positioned as the new solution to the plague of ever-increasing menu bar icons). There are improvements to Shortcuts automation. And, for nerds (hi), Terminal finally got 24-bit color and support for Powerline fonts.
I see a lot of "ugh, Tahoe is just the iOS-ification of macOS" on HN, which, on the surface, I get -- the visual changes by and large make things worse, and ironically I think they're actually not as good as the changes on iOS. But the Mac got stuff that the iPad didn't, and there's still a lot you can't do on the iPad that you can on the Mac. I don't think the two are merging any time soon, even if they're becoming more visually similar. (Actually, I don't think the two will ever merge, strictly speaking, but that's another post.)
It's possible that happens to me, and I've not noticed it. I don't add new applications that often, so I can't recall the last time if it showed up immediately or not.
The search in Settings not working is an issue Apple carried over from iOS (where it was broken for years) into macOS. One of my pet peeves is all the Catalyst apps (like Reminders) that don’t work well with keyboard navigation.
I just can't believe how dysfunctional something as basic as search over settings is now.
Specifically?
You can't ask them questions like that, they don't have any actual answers, just handwavey 'it's bad'.