3 ms·

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.
        0x457 1y ago
        No? Developers had access to _developer_ preview builds on macOS to test their apps. Those builds are meant for this.
        javawizard 1y ago
        That's not what that quote is about. 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).
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?

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.
        0x457 1y ago
        No? Developers had access to _developer_ preview builds on macOS to test their apps. Those builds are meant for this.
        javawizard 1y ago
        That's not what that quote is about. 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).

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?