11 ms·

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

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

kokada 1y ago
> 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.
- dylan604 1y ago
  > (maybe also they could add a message for developers building their application that this method was removed) why do we think this would be a solve as the devs clearly ignored the previous message about not using a private method?
  - kokada 1y ago
    > 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.
    - tedivm 1y ago
      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.
      - magicalist 1y ago
        > 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. [1] https://github.com/electron/electron/pull/20360 https://github.com/electron/electron/pull/20360 [2] https://github.com/electron/electron/pull/48376#issuecomment-3340202800 https://github.com/electron/electron/pull/48376#issuecomment...
- deleted 1y ago
  [deleted]
- wvenable 1y ago
  "When developing Windows 95, one manager bought every program available at a local software store..." https://www.pcworld.com/article/2816273/how-microsofts-windows-95-test-nearly-crashed-an-entire-software-store.html#:~:text=The%20switch%20from%20Windows%203,Chen%20continues: https://www.pcworld.com/article/2816273/how-microsofts-windo...
  - bee_rider 1y ago
    That was the 90’s, the QA was harder to do but actually done sometimes.
    - pjmlp 1y ago
      In the 90's we also got to enjoy native apps.
    - freeAgent 1y ago
      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.
- 0x457 1y ago
  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.
  - kokada 1y ago
    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.
    - NetMageSCW 1y ago
      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.
- deleted 1y ago
  [deleted]
danudey 1y ago
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.
- sunshowers 1y ago
  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?
- mcculley 1y ago
  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.
sersi 1y ago
> 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
- xbar 1y ago
  Here's the thing: they undoubtedly did test these and shipped Tahoe anyway.
  - mocenigo 1y ago
    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?

kokada 1y ago

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

dylan604 1y ago
> (maybe also they could add a message for developers building their application that this method was removed) why do we think this would be a solve as the devs clearly ignored the previous message about not using a private method?
- kokada 1y ago
  > 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.
  - tedivm 1y ago
    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.
    - magicalist 1y ago
      > 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. [1] https://github.com/electron/electron/pull/20360 https://github.com/electron/electron/pull/20360 [2] https://github.com/electron/electron/pull/48376#issuecomment-3340202800 https://github.com/electron/electron/pull/48376#issuecomment...
deleted 1y ago
[deleted]
wvenable 1y ago
"When developing Windows 95, one manager bought every program available at a local software store..." https://www.pcworld.com/article/2816273/how-microsofts-windows-95-test-nearly-crashed-an-entire-software-store.html#:~:text=The%20switch%20from%20Windows%203,Chen%20continues: https://www.pcworld.com/article/2816273/how-microsofts-windo...
- bee_rider 1y ago
  That was the 90’s, the QA was harder to do but actually done sometimes.
  - pjmlp 1y ago
    In the 90's we also got to enjoy native apps.
  - freeAgent 1y ago
    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.
0x457 1y ago
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.
- kokada 1y ago
  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.
  - NetMageSCW 1y ago
    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.
deleted 1y ago
[deleted]

danudey 1y ago

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.

sunshowers 1y ago
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?
mcculley 1y ago
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.

sersi 1y ago

> 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

xbar 1y ago
Here's the thing: they undoubtedly did test these and shipped Tahoe anyway.
- mocenigo 1y ago
  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?