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.
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.
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.
Even if you disqualify the devs from being mad, everyone else gets to be mad.
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).
> 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 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.
Welp
https://leb.fbi.gov/articles/featured-articles/fifty-years-o...
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.
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.
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.
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.
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.
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.
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.
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.
[1] https://github.com/electron/electron/pull/20360
[2] https://github.com/electron/electron/pull/48376#issuecomment...
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.
If they stripped symbols, they’d get flak for not having good stack traces. I think it boils down to “if you’re huge, you’re never doing it right”.
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.
https://www.pcworld.com/article/2816273/how-microsofts-windo...
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.
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.
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?
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?
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
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.
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!)
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
https://github.com/tkafka/detect-electron-apps-on-mac
About half of the apps I use regularly have been fixed. Some might never be fixed, though...
From: https://www.reddit.com/r/MacOS/comments/1nvoirl/i_made_a_scr...
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.
Hence I am not surprised that they ignore their existence.
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.