Electron haters are going to have a field day over this (obviously it's not an electron issue, but why they care?).
Electron-based apps cause system-wide lag on macOS 26 Tahoe
141–150 of 227 posts
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#142How difficult would it be just to switch to Swift for some of these apps?
You're talking about adding at least $10M to the budget and a 2 year lead time for each of these companies.
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#143Earlier quoted context omitted.
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 regul…
I make a habit of turning off spotlight almost entirely. Search never returns what I want anyway, and the juice isn’t worth the squeeze. Go into preferences, spotlight and you can add folders to exclude from indexing. I add my home directory and most of the system directories and that more or less fixes the issue.
That's the way to go. Who the hell searches for reminders or podcasts or anything besides files and apps on Spotlight?
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#144Earlier quoted context omitted.
Yeah, screen time for kids is absolutely broken in iOS 26.
I think you mean “since release”. Hasn’t it always had horrible problems? I’ve never heard a good thing about it in use.
It’s just getting worse with each new iOS release.
For example before iOS 18, screen time requests from kids would come as notifications, now they are coming in as iMessages, polluting history of your actual conversations, so you can’t have functional group chat with your kid & parents.
Now in iOS 26 they messed up calculation of how much screen time is spent, so an app can have limit of 3hrs/day and still lock up after just first 9 minutes of screen time spent in that app in a day.
It seems like they have zero QA.
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#145Discord 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.
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.
It's a little heterodox, but not hard at all[1] and it takes literally less than a minute to trigger the rebuilding.
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#146I’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'm doing my job: https://manualdousuario.net/en/liquid-glass-2/
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#147https://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…
> (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.
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#148Earlier quoted context omitted.
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.
Apple has to take some of the blame from this, MacOS without Electron apps is a much less useful proposition. If they knew they were going to change this API in this release it would have made sense to reach out and offer a public way to Electron. End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs
Absolutely not. Apple has zero responsibility to anybody for changing a private API. That’s the whole point of it being marked private.
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#149https://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…
> That's inherent on the way current computers manage the memory.
You can trivially do that today by telling the linker to discard this symbol. Sure it's still not hardware isolation, but now the caller needs to disassemble the binary and hardcode locations. When its inlined before, then you aren't even able to do this.
Re: Electron-based apps cause system-wide lag on macOS 26 Tahoe
#150Earlier 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…
There's also the good old use case of "am I dealing with a subclass that overrode the superclass's implementation of the method." How do you distinguish between a superclass that always returns null/noop, vs. a subclass that happened to return null in this specific case? Sometimes this is useful/vital for setting expectations to the user what functionality the instance is likely to have. Now, you could refactor every…
Couldn't you use isinstance(), which would not be a hack?