7 ms·

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

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.

kokada 1y ago
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.
- speedgoose 1y ago
  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.
  - IMTDb 1y ago
    So now you can disregard the notion of "private function" if you pass 100k stars on GitHub ?
    - ruined 1y ago
      all APIs are public APIs
      - NetMageSCW 1y ago
        Only if you don’t care about your users or your apps reputation. Of course, if you are using Electron those ships have already sailed.
    - javawizard 1y ago
      There's definitely a line of thinking that would say "yes": https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
      - 0x457 1y ago
        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.
        Dylan16807 1y ago
        Okay to be mad the OS vendor didn't do anything to help when the users are the ones that face the fallout? Yes. Even if you disqualify the devs from being mad, everyone else gets to be mad.
        0x457 1y ago
        Vendor did help...marked function as private. I view this specific incident as another argument against electron, so I'm biased.
        Dylan16807 1y ago
        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.
        javawizard 1y ago
        Exactly. As they say: if you owe the bank $100, that's your problem; if you owe the bank $100 million, that's the bank's problem.
  - wrs 1y ago
    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.
    - makeitdouble 1y ago
      > "the FBI doesn’t negotiate with kidnappers” Welp https://leb.fbi.gov/articles/featured-articles/fifty-years-of-fbi-crisis-hostage-negotiation 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.
      - wrs 1y ago
        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!
  - danudey 1y ago
    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.
    - ryukoposting 1y ago
      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.
      - fingerlocks 1y ago
        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.
    - rock_artist 1y ago
      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.
    - bambax 1y ago
      If the result of this policy is that users think Apple products are crap, then it's probably counter-productive for Apple, no?
- dylan604 1y ago
  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
placatedmayhem 1y ago
The check script I've been recommending is here: https://github.com/tkafka/detect-electron-apps-on-mac 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...
- EasyMark 1y ago
  wasn't there a workaround for those apps that might not ever get updated? I thought I saw something on reddit. Some config change
  - joshstrange 1y ago
    > 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. From: https://www.reddit.com/r/MacOS/comments/1nvoirl/i_made_a_script_to_detect_electronbased_apps_on/ https://www.reddit.com/r/MacOS/comments/1nvoirl/i_made_a_scr...
EasyMark 1y ago
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
- abustamam 1y ago
  Tbh I'm purposely not updating because I'm not in love with the new ~Aero~ glass UI.
michelb 1y ago
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.
- astrange 1y ago
  It should not be slower. File a report in Feedback Assistant.
nikanj 1y ago
Or more likely nobody gives a damn about performance while doing testing.
pjmlp 1y ago
WWDC keynote on the state of the nation was quite clear on what Apple thinks about Electron and related stuff like React Native. Hence I am not surprised that they ignore their existence.
freehorse 1y ago
> 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.
thewebguyd 1y ago
> 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.

kokada 1y ago

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.

speedgoose 1y ago
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.
- IMTDb 1y ago
  So now you can disregard the notion of "private function" if you pass 100k stars on GitHub ?
  - ruined 1y ago
    all APIs are public APIs
    - NetMageSCW 1y ago
      Only if you don’t care about your users or your apps reputation. Of course, if you are using Electron those ships have already sailed.
  - javawizard 1y ago
    There's definitely a line of thinking that would say "yes": https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
    - 0x457 1y ago
      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.
      - Dylan16807 1y ago
        Okay to be mad the OS vendor didn't do anything to help when the users are the ones that face the fallout? Yes. Even if you disqualify the devs from being mad, everyone else gets to be mad.
        0x457 1y ago
        Vendor did help...marked function as private. I view this specific incident as another argument against electron, so I'm biased.
        Dylan16807 1y ago
        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.
        javawizard 1y ago
        Exactly. As they say: if you owe the bank $100, that's your problem; if you owe the bank $100 million, that's the bank's problem.
- wrs 1y ago
  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.
  - makeitdouble 1y ago
    > "the FBI doesn’t negotiate with kidnappers” Welp https://leb.fbi.gov/articles/featured-articles/fifty-years-of-fbi-crisis-hostage-negotiation 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.
    - wrs 1y ago
      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!
- danudey 1y ago
  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.
  - ryukoposting 1y ago
    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.
    - fingerlocks 1y ago
      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.
  - rock_artist 1y ago
    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.
  - bambax 1y ago
    If the result of this policy is that users think Apple products are crap, then it's probably counter-productive for Apple, no?
dylan604 1y ago
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

placatedmayhem 1y ago

The check script I've been recommending is here: https://github.com/tkafka/detect-electron-apps-on-mac 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...

EasyMark 1y ago
wasn't there a workaround for those apps that might not ever get updated? I thought I saw something on reddit. Some config change
- joshstrange 1y ago
  > 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. From: https://www.reddit.com/r/MacOS/comments/1nvoirl/i_made_a_script_to_detect_electronbased_apps_on/ https://www.reddit.com/r/MacOS/comments/1nvoirl/i_made_a_scr...

EasyMark 1y ago

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

abustamam 1y ago
Tbh I'm purposely not updating because I'm not in love with the new ~Aero~ glass UI.

michelb 1y ago

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.

astrange 1y ago
It should not be slower. File a report in Feedback Assistant.

nikanj 1y ago

Or more likely nobody gives a damn about performance while doing testing.

pjmlp 1y ago

WWDC keynote on the state of the nation was quite clear on what Apple thinks about Electron and related stuff like React Native. Hence I am not surprised that they ignore their existence.

freehorse 1y ago

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

thewebguyd 1y ago

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