5 ms·

It was Electron causing a shadow repaint, not Apple: https://github.com/electron/electron/issues/48311#issuecomment-3332181420 https://github.com/electron/elec

by cnity 1y ago

It was Electron causing a shadow repaint, not Apple: https://github.com/electron/electron/issues/48311#issuecomment-3332181420 https://github.com/electron/electron/issues/48311#issuecomme...

m-schuetz 1y ago
It only became an issue when Apple's update made it an issue. This is on Apple.
- jermaustin1 1y ago
  Why is it on Apple to make sure that their private APIs (as in you SHOULDN'T USE THEM, because they will change without regard to your software) are backward compatible?
  - Ambroos 1y ago
    It's on both. Apple should probably have caught this in beta considering how widespread Electron apps are, and have worked with Electron to fix it or they should've worked around it (which Microsoft would probably have done).
    - samtheprogram 1y ago
      Electron updates already exist, it's the individual apps that need to update their version of Electron.
  - afavour 1y ago
    Because ultimately Apple is making software for its users. Something that negatively affects their users experience is something they should factor in with new releases no matter whose "fault" it is. Such is the pain of making operating systems. You're right in the purest sense: use a private API, get burnt. But when it's something this widely used and depended upon you could argue Apple should have made it into a public API by now.
  - runjake 1y ago
    It’s not on Apple. They explicitly warn developers not to do this because stuff exactly like this can happen. If it were an issue involving public APIs, then yes, it would be on Apple. I get it. I’ve used private APIs in some of my Apple apps. But when you do, you take on a certain level of risk and responsibility when you’ve got customers. The bigger question is why none of these Electron app developers, particularly larger outfits like Slack, didn’t catch this issue in the last 3 months they had access to Apple OS betas. Do they have a QA process? Perhaps they should start.
    - stereo 1y ago
      For all we know, they could have filed radar issues with Apple months ago.
      - runjake 1y ago
        They could have, but the most likely response is "Do not use private APIs. They are not intended/ready for third-party developers yet."
  - cowboy_henk 1y ago
    If they're not supposed to be used, why can they be used? Hyrum's law strikes again! With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/)
    - colejohnson66 1y ago
      Because Objective-C doesn’t have access controls. If a method exists, you can call it. A "private" API is just an undocumented one.
      - LeoNatan25 1y ago
        Given enough motivation, access control is irrelevant too. See early Windows "private" API that was used for decades and Microsoft supported despite being "private", because they knew it was being used and they (used to) care about their users.
  - m-schuetz 1y ago
    Anything that can be used, will be used.
emn13 1y ago
Put it this way: if I were in charge of a major OS, and I having one of the major app frameworks used on my OS tested on for my annual upgrade, I'd feel pretty embarrassed, even if there's a figleaf excuse why it's not my fault. This doesn't exactly instill confidence in Apple's competence.
- BoredPositron 1y ago
  That's how you end up with windows.
  - badc0ffee 1y ago
    This. Would it really be better if macOS accumulated workarounds for buggy apps?
    - cwillu 1y ago
      Yes.
    - emn13 1y ago
      There's also the alternative of announcing this breakage publicly to electron beforehand; and the alternative of having a hack and publicly announcing it will be removed in a year. There's even the alternative of just announcing the caveat at all, so your users aren't unwitting guinea pigs. If they don't want to support a million workarounds forever, they don't have to it's not all or nothing.
- whatevaa 1y ago
  Apple doesn't care, they know their users will eat anything they throw at them. Electron used non-public pieces to workaround an issue with Apple code which Apple knew about and was not interested to address, now it's broken after it changed. Nothing new.
- reaperducer 1y ago
  if I were in charge of a major OS, and I having one of the major app frameworks used on my OS tested on for my annual upgrade Each program contains its own version of Electron. How is Apple going to know the version of Electron your particular version of your particular app that you installed on one particular date perhaps years in the past works? n apps in the world × n versions of Electron The problem isn't Apple. It's that the developer of your program is using an outdated version of Electron, or it's put out an update and you haven't updated.

by cnity 1y ago

It was Electron causing a shadow repaint, not Apple: https://github.com/electron/electron/issues/48311#issuecomment-3332181420 https://github.com/electron/electron/issues/48311#issuecomme...

m-schuetz 1y ago

It only became an issue when Apple's update made it an issue. This is on Apple.

jermaustin1 1y ago
Why is it on Apple to make sure that their private APIs (as in you SHOULDN'T USE THEM, because they will change without regard to your software) are backward compatible?
- Ambroos 1y ago
  It's on both. Apple should probably have caught this in beta considering how widespread Electron apps are, and have worked with Electron to fix it or they should've worked around it (which Microsoft would probably have done).
  - samtheprogram 1y ago
    Electron updates already exist, it's the individual apps that need to update their version of Electron.
- afavour 1y ago
  Because ultimately Apple is making software for its users. Something that negatively affects their users experience is something they should factor in with new releases no matter whose "fault" it is. Such is the pain of making operating systems. You're right in the purest sense: use a private API, get burnt. But when it's something this widely used and depended upon you could argue Apple should have made it into a public API by now.
- runjake 1y ago
  It’s not on Apple. They explicitly warn developers not to do this because stuff exactly like this can happen. If it were an issue involving public APIs, then yes, it would be on Apple. I get it. I’ve used private APIs in some of my Apple apps. But when you do, you take on a certain level of risk and responsibility when you’ve got customers. The bigger question is why none of these Electron app developers, particularly larger outfits like Slack, didn’t catch this issue in the last 3 months they had access to Apple OS betas. Do they have a QA process? Perhaps they should start.
  - stereo 1y ago
    For all we know, they could have filed radar issues with Apple months ago.
    - runjake 1y ago
      They could have, but the most likely response is "Do not use private APIs. They are not intended/ready for third-party developers yet."
- cowboy_henk 1y ago
  If they're not supposed to be used, why can they be used? Hyrum's law strikes again! With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/)
  - colejohnson66 1y ago
    Because Objective-C doesn’t have access controls. If a method exists, you can call it. A "private" API is just an undocumented one.
    - LeoNatan25 1y ago
      Given enough motivation, access control is irrelevant too. See early Windows "private" API that was used for decades and Microsoft supported despite being "private", because they knew it was being used and they (used to) care about their users.
- m-schuetz 1y ago
  Anything that can be used, will be used.

emn13 1y ago

Put it this way: if I were in charge of a major OS, and I having one of the major app frameworks used on my OS tested on for my annual upgrade, I'd feel pretty embarrassed, even if there's a figleaf excuse why it's not my fault. This doesn't exactly instill confidence in Apple's competence.

BoredPositron 1y ago
That's how you end up with windows.
- badc0ffee 1y ago
  This. Would it really be better if macOS accumulated workarounds for buggy apps?
  - cwillu 1y ago
    Yes.
  - emn13 1y ago
    There's also the alternative of announcing this breakage publicly to electron beforehand; and the alternative of having a hack and publicly announcing it will be removed in a year. There's even the alternative of just announcing the caveat at all, so your users aren't unwitting guinea pigs. If they don't want to support a million workarounds forever, they don't have to it's not all or nothing.
whatevaa 1y ago
Apple doesn't care, they know their users will eat anything they throw at them. Electron used non-public pieces to workaround an issue with Apple code which Apple knew about and was not interested to address, now it's broken after it changed. Nothing new.
reaperducer 1y ago
if I were in charge of a major OS, and I having one of the major app frameworks used on my OS tested on for my annual upgrade Each program contains its own version of Electron. How is Apple going to know the version of Electron your particular version of your particular app that you installed on one particular date perhaps years in the past works? n apps in the world × n versions of Electron The problem isn't Apple. It's that the developer of your program is using an outdated version of Electron, or it's put out an update and you haven't updated.