Electron-based apps cause system-wide lag on macOS 26 Tahoe • Hacker News Board

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#61

Post by ryandrake » Thu, Sep 25, 2025, 7:36 PM UTC

marcosdumay wrote: post #34

kccqzy wrote: post #2

https://github.com/electron/electron/issues/48311#issuecomme... 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…

> 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. Thos…

I don’t understand what goes through the developer’s mind. A method is marked as private. It’s documented as not to be used by developers. Further documentation says that using it may break your application in strange ways now or in the future. Despite all this, the developer concludes: “yea, I think it’s a good idea to use this API!” Then, later when something breaks, it’s Shocked Pikachu all around.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#62

Post by cyberax » Thu, Sep 25, 2025, 7:37 PM UTC

kccqzy wrote: post #2

https://github.com/electron/electron/issues/48311#issuecomme... 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…

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.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#63

Post by cosmic_cheese » Thu, Sep 25, 2025, 7:37 PM UTC

snarfy wrote: post #51

kccqzy wrote: post #2

https://github.com/electron/electron/issues/48311#issuecomme... 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…

It's all pretty terrible. For problem (1) why does the language allow it? And why are they doing it this way? Did Apple not provide an official way?

With Objective-C's nature as a dynamic language, there's no way to make APIs fully private and unusable to third parties. Despite heavily embracing Swift in recent years, much of AppKit and UIKit are still written in Objective-C.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#64

Post by hluska » Thu, Sep 25, 2025, 7:37 PM UTC

arcfour wrote: post #49

nkozyra wrote: post #8

Earlier quoted context omitted.

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.

Surely there is a more effective way to write an app than to bundle an entire end-of-life browser and Node.js runtime into a 600MB monstrosity.

Of course there is, but not every decision in computing is (or should be) about raw efficiency.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#65

Post by ThePowerOfFuet » Thu, Sep 25, 2025, 7:37 PM UTC

altairprime wrote: post #14

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): defaults write com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool false https://issues.chromium.org/issues/446481994#comment17 That com…

>hxxps://x.com/ian_mcdowell/status/1967326413830472191 (apologies for the Twitter link, but it’s an Apple employee)

https://xcancel.com/ian_mcdowell/status/1967326413830472191

FTFY :)

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#66

Post by asqueella » Thu, Sep 25, 2025, 7:39 PM UTC

tom1337 wrote: post #24

wk_end wrote: post #19

Earlier quoted context omitted.

"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.

So you're blaming because they've changed a private API which electron not only used, but also seemed to have patched?

No, for "pushing out updates that cause issues [with very common software]".

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#67

Post by c-hendricks » Thu, Sep 25, 2025, 7:40 PM UTC

It's not limited to Electron applications:

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

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#68

Post by bdash » Thu, Sep 25, 2025, 7:40 PM UTC

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?

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#69

Post by modeless » Thu, Sep 25, 2025, 7:41 PM UTC

reaperducer wrote: post #60

nntwozz wrote: post #33

I'm a simple man, I see Electron I don't install.

Awesome if you're a one-man-band. Not awesome if you're in a large company where you have to communicate with others and don't get to choose the medium.

I find Slack and Discord to work fine in browser tabs and never felt the need to install their desktop apps. VSCode/Cursor is the only Electron app I felt actually provided value.

Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe

#70

Post by stalfosknight » Thu, Sep 25, 2025, 7:41 PM UTC

ryandrake wrote: post #61

marcosdumay wrote: post #34

Earlier quoted context omitted.

> 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. Thos…

I don’t understand what goes through the developer’s mind. A method is marked as private. It’s documented as not to be used by developers. Further documentation says that using it may break your application in strange ways now or in the future. Despite all this, the developer concludes: “yea, I think it’s a good idea to use this API!” Then, later when something breaks, it’s Shocked Pikachu all around.

And there are people who's default setting is to hate/blame Apple because it's fashionable to do so and they are defending not just the use of but also overriding an API explicitly marked as private.

I don't get it.