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