> I don’t understand what goes through the developer’s mind.

I'm not defending anyone here, but sometimes it's to work around bugs in public APIs that never get fixed. And sometimes it's because some perceived needed functionality isn't exposed in public APIs.

They figure "It'd be a lot easier to use this private API. We can just fix it if it breaks.", not really realizing the ramifications, for example a lot of apps use older versions of Electron -- some even EOL.

Is the Electron team now going to backport this fix to several versions back? Sounds... involved.

The alternative to using private methods or reflectively mucking about with library/platform internals isn't always "do the same thing but with only public API"; it's sometimes "you can't possibly fix the bug or implement the feature that you want to". It sure does increase maintenance burden though.

I get it but a lot of the war stories from Raymond Chen's blog https://devblogs.microsoft.com/oldnewthing/ were about helping major corporations unscrew something that had relied on a private Windows API because there hadn't been a good way to do it. I would guess most cases of people choosing to rely on a private method are laziness or lack of knowledge about "the right way" (or call it bad documentation), but not 100%.

Ok, but

> // By overriding this built-in method the corners of the vibrant view (if set) will be smooth.

If you don't override the built-in method, the corners won't be smooth. Jagged corners cause thousands of eye injuries every day.

Using (or overriding) private APIs comes with risks, but sometimes it's the only way to get things done. Of course, it comes with consequences too. Sometimes vendors test their new releases with commonly use applications and reach out when they've changed things and breakage results, but testing releases isn't webscale.

Sometimes you just can't achieve something with public APIs. Especially on Apple OSes, they love making genuinely useful APIs private for no good reason while heavily using them in their own apps.

Of course, if you use a private API, you're on your own if your app breaks because of it. I myself have done my fair share of using private APIs on Android. Ideally, you should test your app on beta versions of every upcoming major OS release to make sure it doesn't break. Even more ideally, there's a public equivalent starting with some OS version and you only use the private one until that version, then nothing will ever break.

If breaking encapsulation delivers value under the form of features-making-users-happy for a couple years and the fix when it breaks is a matter of a couple weeks (and, like here, a line of code) then it's definitely the right tradeoff

> I don't understand

Well. This is hardly the funniest example then. Check this one out: https://github.com/reactjs/react.dev/issues/3896

And there are people who's default setting is to hate/blame Apple because it's fashionable to do so and they are defending not just the use of but also overriding an API explicitly marked as private.

I don't get it.

Apple has to take some of the blame from this, MacOS without Electron apps is a much less useful proposition. If they knew they were going to change this API in this release it would have made sense to reach out and offer a public way to Electron.

End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs

> Then, later when something breaks, it’s Shocked Pikachu all around

This isn't really true. When something breaks it's generally "darn, we knew it would happen eventually".

Yeah, but you HATE how the system behaves because some great spark at Apple thought that corners must always be _this_ rounded.

Couldn't you use isinstance(), which would not be a hack?

Personally, at this point I blame that universal assumption that every piece of code inside a program has the same reliability, trustworthiness and disclosure properties. At some point we'll have to burn down every bit of software infrastructure and build it new with some care about security.

Or, as some OS maintainer once said: WE DO NOT BREAK USERSPACE! Seriously. How hard is this rule to understand? We particularly don't break user space with TOTAL CRAP.

No time to do that when you need to re-do the entire UI of 100 apps for no good reason other than to make an iMac indistinguishable from an iPad.

[flagged]

Exactly. Who you blame depends on if it was introduced in beta 1 or RC.

The person who's getting burnt is Random Officer Worker Joe, who just wants to run Slack and Spotify and who doesn't know a thing about Electron or private APIs, but knows that ever since upgrading their version of macOS things are running terribly. Apple's position is technically noble, but that doesn't help their users.

What? Windows made tons of progress while maintaining this principle and became the most popular operating system in the world. Are you trying to tell me that you believe the evolution of Windows from 1.0 all the way to 7 - the entire time trying to operate according to this principle - doesn't constitute meaningful progress?

The recent stagnation of the OS has nothing to do with attempting to maintain backwards compatibility.

No, for "pushing out updates that cause issues [with very common software]".