Vendor did help...marked function as private. I view this specific incident as another argument against electron, so I'm biased.

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.

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.

No? Developers had access to _developer_ preview builds on macOS to test their apps. Those builds are meant for this.

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

Yes, sorry, it wasn't clear. I meant this quote has nothing in common with this situation we're talking about.

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

Again, that is what dev builds are for. Developers had months to verify their software still works on an OS that has confirmed release date and has very high ration of users that install the latest and greatest.

That's true, and yet they didn't. We can (rightfully) blame them for that, but people are still pissed off at Apple, and whether or not they deserve it they still suffer the reputational damage.

That's why this quote is relevant to this situation: it's totally Electron's fault for not adequately testing their framework against Apple's latest developer builds, but Apple could have absolutely done more to minimize the chance that Electron would make a mistake like this and cause lots of folks to be mad at Apple over it.

Should Apple be required to? No. Will they still suffer reputational damage if they don't and something like this happens? Yes.