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.
According to the commenter who uncovered the cause of the issue, this is exactly what happened here
Yes. It is, and that is what any responsible person should choose.
> // 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.
"common" is an understatement. I'd bet that at least one affected, broken app is on 97%+ of macOS setups
Well. This is hardly the funniest example then. Check this one out: https://github.com/reactjs/react.dev/issues/3896
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.
I don't get it.
- Apple released macOS 26 - This version was in testing for many months - During this time, Apple has apparently not tested how Slack, VSCode, Discord, work - Or they have, but haven't bothered to reach out to Electron maintainers - The overriding of the private API was in order to fix a bug with a public one
Combine all of these and there is some onus on Apple for this. If you don't fix your broken public APIs, don't be surprised when people start using your private ones that do work.
But easily the worst point is that QA apparently is limited to their own applications only. Do they really care about the user if they don't test applications found on nearly every mac setup out there? Don't they use Slack internally?!
End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs
This isn't really true. When something breaks it's generally "darn, we knew it would happen eventually".
