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.
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.
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.
They only needed to test with the latest Electron at the time of release (or indeed, any chance version - they're all affected - but latest is a reasonable baseline). If they had, they would've seen this.
There are patches out now, but only after Apple released the OS to the entire team world and people reported the issue to the Electron team.
Imo, Electron is sufficiently popular that somebody should test at least one Electron app on a major new OS version sometime before releasing it as done! Any app would've worked, and there's plenty of popular ones, as this post shows.
There's just no way for Apple to maintain and run comprehensive test suites for all the different software platforms out there, even "popular" ones.
That's why they release betas early -- that gives each project an opportunity to run their own test suites, however comprehensive they may be.
It's a little hard to hold Apple responsible when there are a lot of app teams in a better position to catch this than Apple, and apparently none of them did.
(Maybe it was a late change in Tahoe? Still, no one found it in the RC either it seems.)
No, this is possible, but again, just drain the bathwater of "all, everything, comprehensive 100%" while blocking the baby of glaringly obvious system-wide visible bugs any good 9x% testing would've caught.
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.
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?
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.
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.
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).
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/)
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.
This doesn't exactly instill confidence in Apple's competence.