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