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.
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.
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.
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.
With Android's diverse/fractured ecosystem, a similar "system wide" look with reflectivity would be hard to deliver across the board on Android with so many models having very bare specs.
2. unrelated workaround for scroll bug - defaults write com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool false
It sounds really nice for the intended purpose, just not reliable for many.
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.
We're not discussing that, but that they have pushed an update without proper testing. You can see from the other comments that breakage is not limited to people using private methods.
The Electron Framework.framework it contains is 400+ MB alone. I don't understand where you come up with your 90 MB figure?
Perhaps this file is just the installer and the actual system files are much larger? Or maybe your 400MB figure comes from a bloated install? Just speculating here.
The last good file search I've ever used was in windows 98. There was no indexing. When you did a search, it looked through all the subdirectories for a filename which matched the search term. It was glorious.
If I were building a FOSS platform, I wouldn't give a second thought to third parties making use of my platform's private APIs. They're private for a reason, whether that be because they're not yet fully baked or because using them can have unintended consequences, they're not intended for public consumption. I especially wouldn't want somebody else's platform to depend on my private APIs, because I am then effectively locked into keeping that API frozen in time by the numerous others building on this other person's platform.
It's generally poor practice to build upon such brittle things as under-the-hood tinkering anyway.
The alternative doesn’t help either. That’s the approach Microsoft has taken and look what a mess Windows is because of it.
Can you point at any part of windows being a mess specifically because of backwards compatibility?
The recent stagnation of the OS has nothing to do with attempting to maintain backwards compatibility.
I think it’s fair to question whether the decisions around backwards compatibility have been worth the cost but I’d imagine they’re already doing that. Enterprise IT departments love Windows but nobody else does, and the generation of people who grew up using iOS/Android and macOS/ChromeOS for school aren’t going to jump at the chance to bring that enterprise IT experience into their personal lives.
The file system is a great example of how Windows has evolved, actually. Windows 95 was (initially) still using FAT16! NT4 was using NTFS 1.2, we're now on NTFS 3.1. To the file system itself MS added (per Wikipedia): disk quotas, file-level encryption, sparse files, "reparse points" (dunno), journaling, "distributed link tracking" (also dunno), "the $Extend folder and its files" (ditto), and better MFT recovery. Also, apparently not part of the file system itself: symbolic links, transactions, partition shrinking, and self-healing. And that's just what I gleaned from the History section on Wikipedia's NTFS article; I'm sure there's more.
Apple specifically was much slower catching its file system up with Microsoft, despite their disinterest in backwards compatibility. And if Apple jumped ahead a little with APFS, well, NTFS holds its own just fine against APFS for 99% of users. And for when it doesn't, there's also ReFS, an entirely new next gen file system used on Windows Server, and is now slowly making its way onto the desktop.
It's the new stuff that is slow and unusable.
Now imagine if you could get rid of all that legacy crap to make it work in the first place. Microsoft CAN’T do that, because the entire premise of Windows is backwards compatability.
Apple? They don’t care. Killing 32bit apps? Just make an announcement saying that in 2 major macOS releases, macOS won’t be able to run 32 bit apps. It cuts down bloat, and it cuts down on the potential attack surfaces for malicious actors.
Obviously just about everyone would agree that Windows 1 -> 7 was progress. I don’t think you’ll find too many people who’ll say the same about Windows 7 -> 11.
What would be the consequence of this? What harm does this do? Would it be worth Spotify and Slack breaking when I upgrade my OS?
That's easy to imagine: people would have zero reason to use Windows.
AirPort Utility? Apple disbanded that team in 2016. There hadn't been a new AirPort since 2013.
Yeah, and someone will wake from the dead and rewrite all the programs that run the world, written 20-40 years ago, that are to a large degree perfectly working under these compatibility layers.
You should be eternally grateful to MS for dedicating tons of money and some of its best people to maintaining backwards compatibility.
Apple can only afford it because pretty much nothing critical ever ran on macos.
Software A an B works fine before update, after update, both breaks => whatever changed is the problem(in this case, the OS).
I'm not defending anyone here, but sometimes it's to work around bugs in public APIs that never get fixed. And sometimes it's because some perceived needed functionality isn't exposed in public APIs.
They figure "It'd be a lot easier to use this private API. We can just fix it if it breaks.", not really realizing the ramifications, for example a lot of apps use older versions of Electron -- some even EOL.
Is the Electron team now going to backport this fix to several versions back? Sounds... involved.
According to the commenter who uncovered the cause of the issue, this is exactly what happened here
Yes. It is, and that is what any responsible person should choose.
> // By overriding this built-in method the corners of the vibrant view (if set) will be smooth.
If you don't override the built-in method, the corners won't be smooth. Jagged corners cause thousands of eye injuries every day.
Using (or overriding) private APIs comes with risks, but sometimes it's the only way to get things done. Of course, it comes with consequences too. Sometimes vendors test their new releases with commonly use applications and reach out when they've changed things and breakage results, but testing releases isn't webscale.
"common" is an understatement. I'd bet that at least one affected, broken app is on 97%+ of macOS setups
Well. This is hardly the funniest example then. Check this one out: https://github.com/reactjs/react.dev/issues/3896
Of course, if you use a private API, you're on your own if your app breaks because of it. I myself have done my fair share of using private APIs on Android. Ideally, you should test your app on beta versions of every upcoming major OS release to make sure it doesn't break. Even more ideally, there's a public equivalent starting with some OS version and you only use the private one until that version, then nothing will ever break.
I don't get it.
- Apple released macOS 26 - This version was in testing for many months - During this time, Apple has apparently not tested how Slack, VSCode, Discord, work - Or they have, but haven't bothered to reach out to Electron maintainers - The overriding of the private API was in order to fix a bug with a public one
Combine all of these and there is some onus on Apple for this. If you don't fix your broken public APIs, don't be surprised when people start using your private ones that do work.
But easily the worst point is that QA apparently is limited to their own applications only. Do they really care about the user if they don't test applications found on nearly every mac setup out there? Don't they use Slack internally?!
End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs
This isn't really true. When something breaks it's generally "darn, we knew it would happen eventually".
I believe this falls into the perfect definition of "slipped thru the cracks"
Even with just a shroud of hacker thinking that is not something programmers should easily accept.