https://github.com/neovide/neovide/issues/3225
Other Tahoe issues with non-Electron apps:
browserwindow.setHasShadow(false)
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 of encapsulation; (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.
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. Those are probably worth it.
> a piece of code has different behavior depending on the identity of a function
I have written my quota of "find the latest caller on the stack with property X, verify if it has access", on different languages. Some times a function can't in any way be just a function.
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 everything to have the superclass's implementation either throw a NotImplementedError, or return a sentinel value... but changing every call site might be a gargantuan task. Similarly, adding static metadata to every subclass might not be feasible. But checking whether the function's (pre-bound) identity is different is a very easy hack!
Ironically, this might indeed be exactly what Apple is doing here, and they're doing it in a tight loop.
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.
Note that most definitions of extensionality don't consider the number of steps to achieve the result as an observable property, although in practice it is.
Also, this in the comment:
> [a user] Please try any way of getting in touch with Apple engineers you can. As a project, we don't have a better connection to Apple than you do.
>
> One approach might be the engineer who replied to the Bluesky post that someone linked to above about the input issue.
Pure incompetence. Major projects have no way to do anything but ping randoms on socials.
It doesn't matter who's fault it is in some Aristotelean sense, what matters is the user upgraded to YOUR new OS, and now shit don't work.
Raymond Chen and Microsoft got this, years ago. Joel talked about it. You make shit work, even if it's the software being a fuck.
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.
1. They don't know how to do it the right way
or
2. They can't be bothered to do it the right way
#1 I can understand. We all make mistakes as we learn and grow as developers. #2 is just arrogance / laziness on the part of the developer. Compounding it by blaming the platform owner that clearly and explicitly told you not to go that route is gross.
Standard practice for any mobile or desktop software is to start testing on the betas as soon as they're available. Unless this was a last-minute change before the final release, it's on the software developers to use the betas to prepare their software for upcoming releases.
defaults write com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool false
That command’s equivalent is being patched into Chrome and will have to ripple downward into Electron apps; directing complaints to each electron app impacted with a link to the relevant Google issue workaround will give them sufficient data to mitigate it, if they bother to.
Apple is already aware — https://x.com/ian_mcdowell/status/1967326413830472191 (apologies for the Twitter link, but it’s an Apple employee). EDIT: Someone else has traced the issue to Electron messing with internal OS APIs! Courtesy of https://news.ycombinator.com/item?id=45377253 —
> It turns out Electron was overriding a private AppKit API (_cornerMask) to apply custom corner masks to vibrant views.
ps. This issue was discussed a week ago here:
https://news.ycombinator.com/item?id=45292019
pps. Manually applying this workaround without scheduling its future removal has a slight but non-zero risk of someday breaking OS-linked autofill in your electron apps in weird or unexpected ways.
ppps. I don’t work for anyone, school for another three years minimum.
https://xcancel.com/ian_mcdowell/status/1967326413830472191
FTFY :)
It's really fucking obnoxious that somehow a goddamn web app in a wrapper is managing to cause system wide hangs.
https://github.com/electron/electron/issues/48311#issuecomme...
"Application should use all cores and all available memory."
In the past few years, the only applications i've seen run amok with memory usage at least were of course Electron based.
However, note that this problem is on Mac OS "users had too much contrast so we ruined it" 26 Tahoe. It's part of the early adopter experience.
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.
Aside from that, the Settings menu memory leak (or whatever it the problem is) is very much more apparent on the older mac than it is on the new one, but it's still reproducible. Neither computer is running Tahoe yet, these issues were already present, but based on on your comment, they might now be functionally worse in addition to being a performance and user experience joke.
My new Mac is still amazing hardware-wise, and since those issues seem to just be compensated for, perhaps by having efficiency cores that they're able to delegate background processes to, but the sluggishness and in-adequacy of frontline processes and apps must be embarrassing for what I presume to be smarter engineers than myself who probably just don't get to allocate time or energy toward any of the problems, especially with things like Xcode and SwiftUI also having major issues, and the mac being a relatively small market.
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.
I had the same issue; killing Spotlight processes fixed it. (A reboot would probably do the job too.)
(Killing the process, ofc)
Doesn't seem to be updated for Tahoe yet, and even the Sequoia version isn't notarized, so it's not really clear if it has a future.
I've had this issue on my M1 and now my M4 mac for about a year now, and I can't figure it out. Uninstalling and reinstalling hasn't helped.
Literally, someone can reliably send me a slack notification in a meeting (even when DND is on) and cause my Zoom outbound video to get gummed up.
Edit: I ask because I wonder if it has to do with this.
I shouldn't have updated to MacOS Tahoe on my Macbook knowing that it was a .0 release. They need to fix this ASAP.
`browserwindow.setHasShadow(false)`
Could possibly just hotpatch my existing app, add this to the packed in javascript .asar resource file and not having to make a new build with updated Electron version.
At least I notice fan going jet speeds with VSCode lately.
The most inefficient solution (in both space and time complexity) being suggested to build desktop apps is now shown to be causing widespread sluggishness.
So much for interviewing developers for algorithms and data structures. Also Rust won't save you or make Electron faster either.
The most inefficient solution (in both space and time complexity)
In fact it can be worse than many, including modern C++.
Of all the points you mention, compatibility with websites is probably the only one that can be considered exclusive to Electron codebases.
if all you can create are electron apps then you are not a developer.
>cross platform
many programs are cross platform, without the need of Electron.
>open standards
???
>easy compatibility with websites
Electron isn't necessary, e.g. Telegram.
>easiness to keep updated
not Electron exclusive
Electron exists for lazy "programmers" to make their products as fast as possible, without caring for code quality and their customers experience. This is why managers love it, it saves money: you don't need to hire proper software engineers nor allocate an appropriate amount of time to develop and maintain your product.
Electron is part of the enshitification of the web and the IT in general.
2. What better cross platform GUI alternative do you suggest?
These days if you want to support macOS, Windows, Linux: I say good luck to you, Electron can save you there.
Electron is not crap, but many javascript developers are crap. You can make fast and memory efficient apps in Electron, if you know how to code.
(Note: Slack or Discord developers don't have that skill)
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’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.
Hasn’t it always had horrible problems? I’ve never heard a good thing about it in use.
Hasn't that been Apple's norm for a few years now?
Not trying to land a cheap dunk here; I've honestly been running into rough edges and bad design with every major release for a long time.
Not to this degree.
I’ve had 3 memory leaks in native apps, including the calculator. There’s basic alignment errors pretty much everywhere. In many places text can become fully unreadable (black on black, white on white, text over a transparent background with overlapping text below…).
It’s not slightly lowered quality, it’s the kind of inconsistency you expect mixing custom launchers and icon packs.
> It’s a rare misstep from Apple — and an unprecedented one in scale.
There's a lack of taste & lack of respect for the user, too. Things that usually don't get fixed in point releases and take a long time to course-correct.
- Button Shapes: Buttons actually look like buttons.
- Reduce Motion: Animations are a lot more fluid and the parallax effects are more subtle. They don't trigger motion sickness like the previous ones did.
- Larger Text: The worst areas of the UI have better contrast.
- Reduce Transparency: While there's more transparency effects, they're a lot better.
- Increase Contrast: If I do need to turn this back on it is a much better integrated effect than previous version.
The changes in macOS 26 are half-finished. Anything with raised glass looks like plateaus in the middle of a flat desert. Only half the apps have the new rounded corners on window and they do not match the rounded corners in the rest of the interface. They even cut off parts of the interface like the bottom of every scrollbar.
It's disappointing. I loved Windows 7's aero theme.