> Tahoe however makes my M1 Air feel sluggish doing the exact same tasks ive been last couple of years.
I have a work provided M2 Pro with 32GB of RAM. After the Tahoe upgrade it feels like one of the sluggish PCs at the house. It is the only one that I can see the mouse teleporting sometimes when I move it fast. This is after disabling transparency in Accessibility settings mind you, it was even worse before.
It's probably due to the Electron bug[1]. A lot of common apps haven't patched up yet.
I also have an M2 Pro with 32GB of memory. When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
> It's probably due to the Electron bug[1].
> When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
Look, if userspace apps can break system functionality, to the level that simple mouse cursor is not responsive, it suggests that there is something fundamental broken in the OS.
Yes, everyone should blame and shame Electron, but here the bug is firmly in the OS.
If it is accessible from userspace it is by no means private.
Does it mean the API is private in the sense of "unstable" interface? It could very well break the userspace app relying on undocumented behavior, however, crucially here, anything that is exposed to userland WILL at some point be used by some application, be it legitimate or malicious, and it should not break the OS in any way. That's basic hygiene, not even security.
inb4: yes, userspace app could trigger e.g. millions of io operations and millions of number crunching threads and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope. Insert "Task Manager (Not Responding)" meme.
It’s not in a public header. You can easily snoop “private” properties and methods quite easily in Objective-C, because the concept doesn’t exist. It doesn’t exist in C either, but if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.
> if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.
So we are talking about public/private access specifiers in source code, which only matter in cooperative setting. But that's IMO highly naive view as compute, especially OS, is objectively an adversarial environment. Some actors, at some point WILL figure out the memory layout and use that in an attack. There have been literally decades of whack-a-mole against bad actors.
I maintain my stance that any fields/members/methods loaded into a userspace program should not be capable of breaking the system.
People using private APIs know that they might cause instability (in their apps usually). That's why those APIs are private, they can change since there are no guarantees.
I'd point fingers towards the electron core devs for this one, and not devs building apps on top of electron (since they likely didn't know that's how electron was doing it).
There are cases where OS companies noticed the use of private APIs and made cleaner public ones (the most obvious was the file system syncing stuff used by Dropbox and others, which used to use private APIs until Apple provided a public one).
If you can call it, it's not private, it's that simple. Putting a "please don't call this" on is just naïve. Even in legal matters, it's already the case that laws that aren't enforced are worthless, cf. driving 5-10 mph over the speed limit being normal. It won't work any better on a weak statement on an API.
And either way, applications shouldn't be able to break the system like this. You can reasonably expect error handling to catch this, even if the error is "a private API was called".
This is on Apple. 90% at least. Maybe 10% on Electron.
If I can walk on land that says private property, it's not private. I'll remember to use that argument when I get ticketed for trespassing.
There are APIs that are explicitly declared verboten for third-parties to use because they aren't intended for outside use. That doesn't make them magically inaccessible, but it does mean that when their unanticipated use breaks things, that's on the people who ignored the warnings.
I agree that this shouldn't be able to have the huge impact that it does and that Apple ought to have made their OS more resilient, but your logic is weak.
> Even in legal matters, it's already the case that laws that aren't enforced are worthless, cf. driving 5-10 mph over the speed limit being normal.
Just because all but one cop of the force ignore people driving over the speed limit doesn't mean the one who pulls you over is isn't able to write you a speeding ticket. Try that with a judge. It might work, but the law is very much still enforceable. This isn't like failing to protect a trademark.
> If I can walk on land that says private property, it's not private. I'll remember to use that argument when I get ticketed for trespassing.
Dude. Dudette. Duderino. Did you think this through before you hit post? I'm talking about enforcement. If you're getting a ticket, it's literally being enforced. And if it isn't, you get squatters! Thanks for the point in support, I guess?
I think this is the most braindead knee-jerk HN comment I've ever gotten as a reply, congratulations.
[Ed.: god, please, this genuinely hurts my brain.]
> but it does mean that when their unanticipated use breaks things, that's on the people who ignored the warnings.
Yeah. When it breaks things for them. Not when it breaks the entire OS' UI.
Let's stay with your analogy. Things change, Electron apps break? That's analog to finally getting around to calling the cops on squatters after dozing on it. Things change, your UI goes belly up due to Electron? That's you deciding to pay the bill for electricity and indoor plumbing for the squatters. No, wait, even better: you decided you finally want to build a new house on your plot, and now have to deal with getting the squatters out first. It'll happen, but you'll have to unnecessarily sink time and money into that. Apple's dealing with evicting Electron off their private APIs. What a nice analogy.
Of course the squatters are technically wrong. But why did you leave your front door open, and neglected and didn't check in for years? The part where you're making it hard for yourself is on you, mate. You're not going to get your lost time back. Why didn't you grab a lock at home depot?
> Just because all but one cop of the force ignore people driving over the speed limit
This is generally policy, not individual cops' discretion.
Indeed that Mastodon post refers to the sibling to yours. I genuinely can't bear the contradiction. My reply below is as polite as I could manage; on Mastodon there is no point in attempting to restrain my bafflement :)
Yeah, of course they shouldn’t, but they do. Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down. DDoS for example. It’s not a solved problem.
Wax idealistic all you want, but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one. “No userland APIs, private or otherwise, should be able to crash your app!!!” Is the argument I would be responding to right now.
> Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down.
> > userspace app could trigger <...> and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope
If userspace triggers what is an effectively a DoS attack and you cannot login to root terminal and get things sorted out that's a system not designed for adversarial userspace.
> but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one
A more general context we are discussing here is resource exhaustion. There are myriads of scenarios where userspace can cause some form of resource exhaustion. My argument is that a 1) well designed 2) general use system should implement resource management in a way (e.g. priority queues) that userspace-inflicted resource exhaustion does not affect performance envelope of the system itself. Otherwise the system is open to unprivileged DoS attacks with only recourse being power cycling.
If your userspace app overcommits memory to some monstrous degree, what should the system do?
1. Enter a swap feedback, crippling the system down to unusability.
2. OOM-kill a process based on some heuristics.
3. freeze userspace, leaving privileged space functional.
I think you’re losing me. This is all completely tangential to the current discussion, bordering on non-sequitur. I don’t know why you chose to latch onto my loose quip of “bring the whole system down”, because that’s not what is happening here. I thought you knew that.
The OS got a little slower, that’s it. It was never in some unrecoverable state. One could soft close the offending processes at anytime and regain the lost perf. I’m willing to bet you could hide or minimize the window to mitigate the issue, because the bug is very specific to the layout and render run loop, which auto-pauses on lost visibility by default.
That said, I haven’t even noticed the slowdown on my work machine, but I only use Teams. it’s always been dog shit slow, just par for the course.
I can think of multiple ways to pass the message to Electron developers:
- Open a GitHub issue explaining those private APIs shouldn't be used.
- Even better, open a PR fixing their use.
- Make those API calls a no-op if they come from an Electron app.
- Fix those API calls not to grind the OS to a halt for a seemingly simple visual effect.
- Create a public API allowing the same visual effect on a tested and documented API.
Choosing to (apparently violently) downgrade the user experience of all Electron app users, without a possibility to update at the launch day, if a deliberate decision and not an overlooked bug, is a rather shitty and user-hostile move, don't you think?
> - Make those API calls a no-op if they come from an Electron app.
Long-term, this is a maintenance nightmare. These hacks can stick around for decades, because there's no backpressure on downstream to actually fix things. It's not about "team velocity", it's about keeping yourself sane.
> - Open a GitHub issue explaining those private APIs shouldn't be used.
> - Even better, open a PR fixing their use.
Apple has a history/culture of secrecy. Whenever they provide public source code, it's a dump thrown over the fence. There is most likely some team inside that actually cares, but they can't "just" open an issue. My guess is that this is their message.
> [...] is a rather shitty and user-hostile move, don't you think?
Yes, I agree, the general direction they've been taking has been increasingly user-hostile for a very long time; let alone the developer story.
But sometimes there's also a perfectly reasonable excuse, from both "technical" and "organizational" POV. That's just my take, a skunkworks effort to get Electron to fix their crap. I would do the same.
To be clear, Electron themselves fixed the bug quite quickly; but many Electron apps haven't pushed a version that vendors in the fixed version of the Electron runtime.
(And shit like this is exactly why runtimes like the JVM or the .NET CLR are designed to install separately from any particular software that uses them. Each of their minor [client-facing-ABI compatible] versions can then be independently updated to their latest OS-facing-bugfix version without waiting for the software itself to ship that update.)
Apple is consistent in their warnings to not use private APIs, and especially don't override them for custom implementations which is what Electron does here.
The _cornerMask override was a hack that shouldn't ever have existed in the first place, and it's not the only use of private APIs in the electron code base.
Apple is very clear about how they want you to make software for their OSes. It's 100% on electron that they choose to do it this way regardless.
I'd go as far as to say Electron itself is a hack that shouldn't exist, but sadly everyone has decided it's the only way they are going to make desktop software now.
> How else do you get the message across? Do not use the private APIs.
The most effective way would be for Apple to actually seek feedback on requirements and then actually implement public APIs for functionality that people need.
That's confusing "consensus building" with "effective". Killing a private api is pretty effective. And consensus building doesn't always build the best software.
... and in the process we will deteriorate the performance of millions of users and hurt our brand as a top class experience company?
Don't really care who is to blame, but they should have identified this, and either warn developers, or warn users. Or provide a tool for identifying guilty apps in your machine, and let users decide how to proceed.
There's no meaningful difference between "private" and "documented, but changing every patch release" from userspace POV, yet not committing to documentation saves development effort for the same result, hence "private" APIs. If anything, private apis let "system" apps run at userspace, reducing attack surface dramatically.
wtf am I reading? No no no. Undocumented apis callable from user space, that can break the OS, is a security flaw (in the OS). It’s why people laugh at windows.
Should we not be shaming apple for their recent software releases? Every bit of the os is N times slower than on the previous macOS version. Safari has been unusable. Constant lags and crashes in the shipped browser alone. We are back in Windows Vista times
Windows Vista broke UX for apps that tried to request admin permissions too often but didn't break the applications thenselves, and for video drivers wasn't that largely due to Intel shipping crap?
My MacOS experience has been first party software is getting worse.
If I’m remembering correctly, the original script he found had different emoji in the two lines (red X vs. green checkmark), but since HN comments strip emoji, pasting it here made them equivalent.
hmm there are apps produced by your script that claim to be fixed according to https://avarayr.github.io/shamelectron/ (Signal, Discord, Notion, etc). And I checked that those apps are updated. Which one’s correct?
Do you have a few electron powered apps that didn’t get updated yet?
Electron used to override a private function that makes the Mac OS sluggish on Tahoe, and apparently no one uses Electron apps while doing testing at Apple.
I keep my applications pretty much up-to-date but I didn't check the release notes for each Electron application that I have to make sure they're updated. I still think this is a failure of macOS, since one misbehaving application shouldn't bring the whole environment to slow to a crawl.
What I can say is that while the situation is much better than at Day 1, the whole Tahoe experience is not as fluid as Sequoia.
Also, it doesn't really matter to me if this was a private function or not, if this was Windows or Gnome/KDE people would blame the developers of the desktop instead.
It shouldn't be the user's responsibility to know what architecture the software uses to then need to go look at upgrading them. Upstream comments blaming Apple for this for "not testing Electron apps internally", but I don't expect Apple to test every single app ever released for regression testing. Apple releases betas, and the software devs are expected to test their app against it. The problem comes from the app devs using a bit of private code where it is suggested to not do that for this very reason. Even if Apple did test and find the result, it would still be the app dev that would need to fix it. Maybe the thought is that an email from Apple to the dev saying fix your code would more compelling???
> Upstream comments blaming Apple for this for "not testing Electron apps internally", but I don't expect Apple to test every single app ever released for regression testing.
This happens in pretty much every Electron app as far I know, and lots of Electron apps are like Spotify, VSCode or Slack are very likely to be in the Top 10 or at least Top 100 most used apps. And yes, I would expect Apple to test at least the most popular apps before releasing a new version of their OS.
> Maybe the thought is that an email from Apple to the dev saying fix your code would more compelling???
Of course not. Apple controls the SDK, they could workaround this in many different ways, for example instead of changing how this function was implemented they could introduce a new method (they're both private so it doesn't matter) and effectively ignore the old method (maybe also they could add a message for developers building their application that this method was removed). It would draw ugly borders in the affected apps but it wouldn't cause this issue at least.
QA then was taken pretty seriously because, unlike today, they could not just issue a patch over the internet and expect their users to find, download, and install it. Much of the '90s was pre-internet era for many people, and it was certainly before today's world of having auto-updating apps, good search engines, etc.
> why do we think this would be a solve as the devs clearly ignored the previous message about not using a private method?
If anything the fact that devs can actually access private symbols is an issue with how Apple designed their APIs, because they could make this so annoying to do that nobody would try (for example, stripping symbols).
Also, the fact that devs need to access private symbols to do what they need to do also shows that the public API is lacking at least some features.
Another thing, if this only affected the app itself that would be fine, but this makes the whole system slow to a crawl.
So while devs share some of the blame here (and I am not saying they don't), I still think this whole situation is mostly Apple's fault.
If you actually read the specific bug and use of a private method it really was a stupid decision by one developer awhile ago that just fell through the cracks. There really wasn't a benefit to doing what they did, which is why their fix was to just go back to using public APIs.
I think the failures here are that Apple should have tested this themselves and the Electron devs should have tested and resolved this during the beta period.
> If you actually read the specific bug and use of a private method it really was a stupid decision by one developer awhile ago that just fell through the cracks. There really wasn't a benefit to doing what they did, which is why their fix was to just go back to using public APIs.
I don't think it's that clear cut. It looks like it was a workaround for a MacOS rendering bug going back to at least 2017, landed in 2019 and had no apparent downsides for six years[1].
The PR removing the private API code also included someone verifying that Apple had fixed the original bug some time in the intervening years[2].
I probably wouldn't have taken this approach personally (at the very least file the original rendering issue with Apple and note it with the code, though everyone knows the likelihood of getting a even a response on an issue like that), but it wasn't some cargo culted fix.
This only made Apple look bad, again this is not a bug that make the app slow, it makes the whole system slow.
Imagine now that you're a non tech savvy user, that probably doesn't update apps as often, they are probably wondering why "my laptop is so slow after updating". But like I said in other thread, maybe this is on purpose to make people upgrade.
I don't think they care, they'll pass the blame to 3rd party app devs. They care more about forcing users and devs to interact with their products how Apple wants them too. They have a long track record of this behavior
> because they could make this so annoying to do that nobody would try (for example, stripping symbols).
Many of Apple's OS frameworks are managed code (ObjC/Swift); and in ObjC, calling across a library boundary is always done with a message-send — i.e. a dynamic-dispatch, necessarily symbol-table-based call into an entrypoint of the target library. So anything Apple did to "strip symbols" would make it impossible for them to have one of their libraries call into another of their libraries.
Spotify doesn't use Electron, though. Also, I do not expect Apple to care about Electron because delivering shitty electron experience only benefit their native apps.
If anything the ones that got a worse reputation here is Apple itself. The bug basically slow the whole system, not just the application that has the bad behavior.
Sure, people in Hacker News now know that the issue is "that Electron bug", but I am sure lots of other people that are less tech savvy just kept questioning what the hell is happening and maybe even considered an upgrade. But maybe that is the whole point.
Seems like the right patch is to just crash any app attempting to use the private API so blame would go where it is deserved. And if it caused a lot of more awareness of the need to get rid of Electron, bonus.
It seems as though a lot of arguments about this boil down to a few inane implications:
1. Apple should test every (common?) app and any change to the OS that they make that makes an app worse shouldn't be done regardless of why they wanted to make that change.
2. Even though Apple tells people not to use private APIs, if a program uses a private API anyway Apple should build a workaround into their OS instead of letting apps suffer their own repercussions.
3. Apple should test everything ahead of time and then go around telling all the app developers that there's a problem, as if those app developers are going to do anything about it.
No matter what Apple did here, their actual choices boiled down to:
1. Add workarounds for misbehaving broken apps, giving those apps no incentive to fix their issues, and forcing Apple to support those workarounds indefinitely; this also undermines their "don't use private APIs, they could break later" position. This is the kind of thing that made Windows into an unmaintainable sack of cruft.
2. Do what they did, which is change the API and let broken apps be broken to the user's detriment. Everyone blames Apple even though it's objectively not their fault.
2. Add some kind of non-workaround that caused problems for the app and not the user; e.g. have this private API rate limited or something so that the app ends up blocking in the call. Could cause problems for actual consumers of this API, and people would still blame Apple but in this case it would be more of their fault than option 2.
In the end, Apple can't spend their time fretting over what bad developers do wrong; they spend their time on their OS and software and if a developer writes bad software and causes problems then so be it.
I think testing the top 10 projects in a few verticals is a pretty reasonable thing. For my open source projects I do this kind of basic QA against their top users.
Then the bugs could be reported to the various app developers, and they would have been able to get some notice. Many would have acted on it. Many of the top apps have dedicated Apple contacts already. Seems like a completely reasonable expectation?
4. push Gatekeeper-blacklist entries for the broken (bundle ID, version) pairs of these apps (even if those are the current versions!) — such that when the user goes to open them, they just get a dialog reporting the app as being "not compatible with this Mac, and should be moved to the Trash."
I seem to recall from past reading of the AppKit source code that one solution to (1) was to have version specific workarounds that worked for e.g. RecklessApp 39, but would no longer work for RecklessApp 40. I assume that the developers in question were informed of the fact, and now had every incentive to fix the problem.
Apple really should investigate why so many popular apps are implemented using Electron. Is it that hard to use the native APIs now? If so, Apple needs to improve the native application development experience. The UX on these apps is terrible and should be embarrassing for all involved.
Electron isn't popular because SwiftUI sucks (although both statements can be true at the same time) it's because big shops have decided that it's not worth the cost to develop native UIs on each platform anymore, so the only way they've decided we will get "native" apps is via Electron.
If electron didn't exist, it would be QT, or we'd only see native apps on Windows like the old days, and nothing at all on macOS and Linux (or just web apps).
It's not a tech issue but a cultural/management problem.
Personally I try to avoid Electron apps as much as possible, but it's pretty much unavoidable now. Docker Desktop, Bitwarden, 1password, slack, VSCode, dropbox, GitHub Desktop, Obsidian, Notion, Signal, Discord, etc. All the major apps are electron. Even in the Windows world Microsoft stopped making native and makes heavy use of their own version of Electron (EdgeWebView2) for their own apps. The freaking start menu is react native ffs.
The industry has lost its collective mind in favor of being able to hire cheap javascript talent
The other reason is that many of the companies that ship Electron apps are web-first companies. Slack, Discord, VSCode, Github, and Notion were all solely web apps at first — some for years — before any native app was released.
To these companies, a "native app" is just "a web app with its own start-menu icon, no browser chrome, and access to OS APIs."
(In other words: if PWAs had access to all the same OS APIs that Electron does, then these companies wouldn't ship native apps at all!)
I have written applications for macOS in Objective-C and remain a Swift skeptic. Maybe the language has more serious design behind it now. I don’t know. As much as I hate JavaScript, maybe it is time for Apple to provide a JavaScript API or their own official Electron layer. I really hate how Electron apps don’t use the same text input field as the rest of macOS.
That's sort of the route Microsoft went with EdgeWebView2.
Swift itself is great and stable enoug now. I really like the language. SwiftUI though still needs work and is still missing functionality that you have to fall back on AppKit for so there's tons of bridges to embed AppKit views in your SwiftUI hierarchy (like NSTextView still relies on AppKit, as does some drag and drop functionality) so at a certain point you might as well just continue using AppKit.
Apple introduced an entirely new language and UI framework to make it easier, Swift and SwiftUI respectively. They have tutorials, classes, thousands of example projects, playgrounds, videos, and documentation. No, it’s not hard at all.
But very few users seem to care about performance or polish, so why not save a few bucks and build your desktop software with some cheap JavaScript devs?
> blaming Apple for this for "not testing Electron apps internally", but I don't expect Apple to test every single app ever released for regression testing.
Given how high profile the impacted app are, yes it's their responsibility to test it. Even Microsoft does better there (or at least used to). Contacting electron and finding a solution would have been an easy step to take
Electron was using an undocumented API. There is no guarantee at all that undocumented APIs will continue to work or to be supported. Why should Apple encourage this behaviour?
Yes I think Apple is to blame there. Electron is so prominent that they should have detected the problem and found a solution well before the general release.
Apple releases betas of their OS specifically so that developers can try their apps on them. macOS is so prominent that Electron-using developers should have detected the problem and found a solution well before the general release.
Well, I personally know of cases Apple did explicit patching for specific apps to keep them working / avoid breaking.
My simple guess is that slipped QA or wasn’t escalated from Apple’s feedback.
Considering the amount of electron apps, expecting all developers and all users to update all their app (and guessing which one is Electron based) isn’t good user-experience.
Let’s say the change is needed in the OS, you’d expect transition time.
Also, a good UX on OS would be to notify user this app is using some API in a way that could reduce experience. but guessing and expecting only the developer and user parties without the OS side is making less sense imho.
I don't do desktop applications professionally (firmware is my thing) but I would balk at the suggestion that I should run a beta OS on the machine that pays my rent.
What portion of, say, Slack devs actually run a MacOS beta at work? Are they regular devs, or are they in QA/test? It seems to me like the latter is the far more appropriate team for this.
I write macOS software (among other things). I always run the earlier betas on another machine for testing. The primary dev box gets the beta a few weeks before release. It’s never been a problem.
This is 100% on electron, they didn’t do their due diligence that every Mac & iOS dev goes through every summer before the next release. It’s been two decades of the same song and dance every year. There’s just no excuse.
Apple just doesn’t work that way, and hasn’t since I worked there in the 90s. Private APIs are out of bounds. It’s like a “the FBI doesn’t negotiate with kidnappers” situation.
Apple's private API situation was also much more nuanced, back in the days if Adobe was using an API, private or not, it probably wouldn't be degraded in any way until the core applications moved forward. Current Apple might not give a damn though.
Yeah true, there was a period when they couldn’t really afford to annoy the big developers. But it doesn’t seem like the underlying attitude changed much!
Sure, someone will depend on it, we all ignored "private" vs "public" at least once. Okay to do and okay to be mad when your thing breaks because you decided to depend on it? Nope.
That's a good initial step. But once it got put on a zillion computers, there should have been additional mitigation steps.
In an ideal situation, they would have noticed the widespread use of this private function a long time ago, put a note on the bug report that it works around, and after they fixed the bug they would have reached out to electron to have them remove that access.
If you owe the bank $100 and don't pay, that's your problem: you'll get in trouble for it, and the bank isn't going to be unduly harmed.
If you owe the bank $100 million and don't pay, that's the bank's problem: the loss of that $100 million is going to hit the bank hard, whether or not they're the ones who are in the right and regardless of how much trouble you get in over it.
Likewise, if you're a small time app developer and you use a private method that gets yanked and your app breaks, that's your problem: your users are going to be pissed at you, you'll take the reputational damage, and even if your users are also pissed at the OS vendor they represent such a small group of individuals that the OS vendor isn't going to be unduly harmed by that.
If, on the other hand, you develop one of the most widely used frameworks and you use a private method that gets yanked and your app breaks, that's the OS vendor's problem: the number of people who are pissed off at them (rightly or wrongly) is now much larger and they're going to take some reputational damage over it, whether or not they're the ones who have the moral high ground and regardless of how much reputational damage you also take.
And that's exactly what we're seeing here: it doesn't matter that Electron used an API they weren't supposed to, people are pissed at Apple about this and Apple, rightly or wrongly, has to contend with that reputational damage if they don't take steps to prevent this sort of thing before it happens (like letting the developers know that private-on-paper API is going to be yanked in advance, or making it mechanically impossible for anyone outside of Apple's own code to invoke that API long before someone depends on it).
Yes, sorry, it wasn't clear. I meant this quote has nothing in common with this situation we're talking about.
> has to contend with that reputational damage if they don't take steps to prevent this sort of thing before it happens (like letting the developers know that private-on-paper API is going to be yanked in advance, or making it mechanically impossible for anyone outside of Apple's own code to invoke that API long before someone depends on it).
Again, that is what dev builds are for. Developers had months to verify their software still works on an OS that has confirmed release date and has very high ration of users that install the latest and greatest.
That's true, and yet they didn't. We can (rightfully) blame them for that, but people are still pissed off at Apple, and whether or not they deserve it they still suffer the reputational damage.
That's why this quote is relevant to this situation: it's totally Electron's fault for not adequately testing their framework against Apple's latest developer builds, but Apple could have absolutely done more to minimize the chance that Electron would make a mistake like this and cause lots of folks to be mad at Apple over it.
Should Apple be required to? No. Will they still suffer reputational damage if they don't and something like this happens? Yes.
> Run launchctl setenv CHROME_HEADLESS 1 on every system start. The CHROME_HEADLESS flag has a side effect of disabling Electron app window shadows, which makes them ugly, but also stops triggering the issue.
This is why I stay on previous release until at least 0.2 or 0.3 to let them work out the bugs so I dont' have to deal with them, there was nothing in 26 that felt pressing to me that I would need to update
> apparently no one uses Electron apps while doing testing at Apple.
You have it the other way around. It should be, apparently no one making Electron bothered to test on the numerous developer and public betas to make sure their hacky override of undocumented APIs (which Apple explicitly says not to use) didn't break.
The OS and stock apps are much slower in Tahoe even. And the UI updates/interactions are also slower.
I’m lucky I only upgraded my least used machine, and that’s a well stocked M2.
> apparently no one uses Electron apps while doing testing at Apple
Or also the other way around, nobody who develops electron apps cares to test their app on macos in the beta releases (beta testing for developers was long out afaik).
Except if it was like that JIT JVM bug that caused apps to crash and was not in the beta release.
my tinfoil-hat theory is that on each OS iteration Apple adds a new feature that leverages the latest chips hardware acceleration features and for older chips they do software-only implementations.
they ship-of-thesseus the crap out of their OS but replacing with parts that need these new hardware features that run slow on older chips due to software-only implementations.
I got the first generation iPad Pro, which is e-waste now, but I use it as a screen for my CCTV, it cannot even display the virtual keyboard without stuttering like crazy, it lags switching apps, there's a delay for everything, this thing was smooth as butter on release.
I have the 4th gen (2020) iPad Pro with the A12X Bionic, the same chip they put in the Apple Silicon transition dev kits. With iPadOS 26 it's become barely usable, despite still being performant as ever on iPadOS 18. I'm talking huge drop in performance, stutters and slow downs everywhere.
I was considering just replacing the battery and keeping it for several more years but now I feel forced to upgrade which has me considering whether I still want/need an iPad since I'd also have to buy a new magic keyboard since they redesigned it, and they bumped the price ($1299 now vs. $999 when I got the 4th gen) so I'd be looking at $1700. Trying to hold out for an iPad Air with ProMotion.
I may be in the minority here, but I think 5 years is too short of a lifespan for these devices at this point. Early days when things were advancing like crazy, sure. But now? I have 8 year old computers that are still just fine, and with the M-series chips I'd expect at least 10 years of usable life at minimum (battery not withstanding)
That's weird. I have an 8th Gen iPad, the slowest device that can run iPadOS 26, and everything is fine on that old thing. (except the OS takes up the majority of the storage)
Interesting. Might try a factory reset then and see. There's noticable lag for me, it's especially slow when switching apps or bringing up the keyboard, as well as on first unlock. Interacting within a single app is still fine, it's interacting with the OS that's really sluggish.
8th Gen iPad is about the same on iPadOS 26 as 18 for me, which is slow. The 32GB really handicapped it for even being usable as to even upgrade it, I have to factory reset it first. I'm replacing it with a Mini.
The iPad Air 13 with a M3 is a really nice experience. Very fast device.
weird, my iPaid Air 3 which should have the same specs has been really for at least a year. Plenty of free storage, not so many apps, all visual enhancements turned off.
I have perfectly fine Mini 2 Retina, but because they blocked Safari updates and faked AppStore connectivity issues - I have just perfect display with still good battery than can be used as bread cutting board :(
Plus they don't let you downgrade to previous iOS versions on iPhones and iPads (unless you've been smart to save SHSH blobs and all that) so the only option to revert to a smooth version now is to download a sketchy jailbreak.
Yep, this is pretty much how they operate. Apple has always done that to some extent. Sometimes they are even quite clear about it and use it as a marketing point to push upgrading.
They could choose to not offer the new feature to users on old hardware, but still provide those platforms with e.g. security updates and key features like Safari upgrades.
26.0.1 is better, but I can still get sluggishness in a few specific cases.
I just got one example while passing the mouse quickly through my dock (I still use the magnify animation) and I can clearly see it dropping a few frames. This never happened in macOS 15.
I too have a work-provided laptop and a personal one bought the same month, with identical specs (the only difference is the US vs UK keyboard layout). The work-provided one is at least an order of magnitude slower to do anything thanks to enterprise crapware.
HAHA this is where HN has become delusional. It quite literally is the implementation, they've checked the render pipeline on reddit. Jesus the arrogance here is so shit.
It's not arrogance. Again, anyone above a 3rd comp sci student would know not to do it like that. I'm not saying I'm smart, I'm just saying I'm not stupid. There's a difference.
If this is true, then apples engineers or managers made a huge mistake in their implementation.
Yeah that's every company and yeah that's bad. I'm just pointing out it's bad. I don't know why youre taking that as if I just said something rude about your mother. Calm down, be normal.
I have a work provided M2 Pro with 32GB of RAM. After the Tahoe upgrade it feels like one of the sluggish PCs at the house. It is the only one that I can see the mouse teleporting sometimes when I move it fast. This is after disabling transparency in Accessibility settings mind you, it was even worse before.