If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit.
This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation; (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.
> despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation
That's inherent on the way current computers manage the memory. And I don't know if the gains are enough to pay for the loses of guaranteeing encapsulation.
One could reach for static analysis, but that would imply some restrictions on the machine's assembly. Those are probably worth it.
> a piece of code has different behavior depending on the identity of a function
I have written my quota of "find the latest caller on the stack with property X, verify if it has access", on different languages. Some times a function can't in any way be just a function.
I don’t understand what goes through the developer’s mind. A method is marked as private. It’s documented as not to be used by developers. Further documentation says that using it may break your application in strange ways now or in the future. Despite all this, the developer concludes: “yea, I think it’s a good idea to use this API!” Then, later when something breaks, it’s Shocked Pikachu all around.
> 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.
So you'd tell customers "No, I'm not fixing that bug because doing so would offend my aesthetic sensibilities. Yes, I know you have a support contract, but I simply refuse to address your problem even though I could"? Or maybe you'd phrase it a little differently in public.
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%.
Discovering and using private APIs is not a walk in the park. I doubt "laziness" is a common motivation for doing so. Lack of knowledge or bad docs, perhaps. But there's often no officially sanctioned way to do something that people want (and perhaps will pay for) - most private API usage I've seen falls into this third bucket.
Laziness comes in many forms. Arguably, discovering and using private APIs is a form of intellectual laziness — it requires you to refuse acknowledging that the whole system is telling not to do things that way.
If you defer to authority. That is, you accept that the people who made the API have the authority to dictate you what you can or can't do on your hardware (or for other people on their), that privating the parts of the API you need was a conscious decision (and not just laziness on their part) and that in general you listen to commands like that.
Even with just a shroud of hacker thinking that is not something programmers should easily accept.
Oh wow, that is the opposite of Hacker Mentality to me. I may question lots of other people, but if some other coder put in the time to construct a well designed API that includes public and private methods, my first thought is never “I know better”. Took me a couple of decades to stop thinking that though, so what do I know?
> // 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.
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.
It's not necessarily "blaming", more a combination of:
- 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?!
How come this only surfaces now? Surely large companies such as Microsoft and Slack apparently tested their products that use Electron with the public betas?
It's very hard to notice and very easy to attribute something else. The main symptom is your laptop heating up which is usually attributed to
(1) You just have a slow MacBook, you should get a new one
(2) During beta, "it's a beta and it's expected to heat up and be slow"
(3) People not caring about temps because they use the laptop in clamshell mode
I believe this falls into the perfect definition of "slipped thru the cracks"
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
I disagree I think Apple has a responsibility to not break the biggest software used on their platform. They might not like it but I'm sure they'd dislike that software never being there at all even more.
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
There's also the good old use case of "am I dealing with a subclass that overrode the superclass's implementation of the method."
How do you distinguish between a superclass that always returns null/noop, vs. a subclass that happened to return null in this specific case?
Sometimes this is useful/vital for setting expectations to the user what functionality the instance is likely to have.
Now, you could refactor everything to have the superclass's implementation either throw a NotImplementedError, or return a sentinel value... but changing every call site might be a gargantuan task. Similarly, adding static metadata to every subclass might not be feasible. But checking whether the function's (pre-bound) identity is different is a very easy hack!
Ironically, this might indeed be exactly what Apple is doing here, and they're doing it in a tight loop.
> That's inherent on the way current computers manage the memory.
You can trivially do that today by telling the linker to discard this symbol. Sure it's still not hardware isolation, but now the caller needs to disassemble the binary and hardcode locations. When its inlined before, then you aren't even able to do this.
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.
A good argument for allowing and working with minor platform differences instead of trying to micromanage every little aspect to force inter-platform consistency and/or perfect compliance with the mockup.
> (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.
Note that most definitions of extensionality don't consider the number of steps to achieve the result as an observable property, although in practice it is.
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.
Well yes, if the out-of-tree driver sticks to public stable APIs it shouldn't be broken. And analogously here, if the software in question stuck to public stable APIs and didn't reach into private internals it shouldn't have broken.
> (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation;
That's why its a good idea to strip a symbol or provide a linker script. This way you can also properly version the code.
Abuse of private APIs means that your public API is incomplete. And that people dislike how your system behaves so much, that they're willing to muck with its internals.
No, it means some people are doing it wrong either because:
1. They don't know how to do it the right way
or
2. They can't be bothered to do it the right way
#1 I can understand. We all make mistakes as we learn and grow as developers. #2 is just arrogance / laziness on the part of the developer. Compounding it by blaming the platform owner that clearly and explicitly told you not to go that route is gross.
> It turns out Electron was overriding a private AppKit API (_cornerMask) to apply custom corner masks to vibrant views.
> ...
> By removing the custom _cornerMask override and associated logic, we allow AppKit to handle shadows with its default pipeline. This resolves the GPU spike while retaining shadows as expected.
I'd say that most often usage of private APIs is because:
I'll grant that their documentation isn't the best I've ever seen, but it is still on you if you reach for private APIs. Again, that is consciously choosing a shortcut you've been explicitly told not to use.
With Objective-C's nature as a dynamic language, there's no way to make APIs fully private and unusable to third parties. Despite heavily embracing Swift in recent years, much of AppKit and UIKit are still written in Objective-C.
"Not Apple's fault" is up for debate; even if Electron shouldn't be doing this, Apple arguably shouldn't be pushing out updates that cause issues with wide-swaths of software that users use regardless.
We've had developer betas of macOS Tahoe since June.
Standard practice for any mobile or desktop software is to start testing on the betas as soon as they're available. Unless this was a last-minute change before the final release, it's on the software developers to use the betas to prepare their software for upcoming releases.
Apple’s attitude here is that it’s an inherent risk of using private APIs, because it’s not something they want devs doing. They don’t facilitate it like MS tends to. Don’t touch the stove if you don’t want to get burnt.
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.
The Electron maintainers should've considered that possibility before reaching for a private API. It's on the Electron's team's shoulders and nobody else's.
If I were building a FOSS platform, I wouldn't give a second thought to third parties making use of my platform's private APIs. They're private for a reason, whether that be because they're not yet fully baked or because using them can have unintended consequences, they're not intended for public consumption. I especially wouldn't want somebody else's platform to depend on my private APIs, because I am then effectively locked into keeping that API frozen in time by the numerous others building on this other person's platform.
It's generally poor practice to build upon such brittle things as under-the-hood tinkering anyway.
That one's incomplete migration rather than backwards compatibility. As in, they failed to move everything rather than moving everything but preserving the old way for compatibility with something.
Sounds like Joe will direct his anger towards Slack and Spotify, and as a paying customer he has every right to be upset when his software doesn't work.
I doubt he will - they didn’t change, his OS did, they worked before, post hoc ergo propter hoc. Anyway, they’re from different companies, how could they both be at fault? If he even identifies them as related - he probably had them both running at startup and never quits them.
How much cognition are we assigning to Joe in this hypothetical scenario? You make him out to be barely more capable than a lab chimpanzee dully poking at a screen to get some fruit. Give Joe a little credit, people aren't as dumb as you think.
I think there's a propensity for cynical tech-oriented people to look at non-tech people as if they're dullards. I'm not convinced, I take a more optimistic view of people.
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.
It’s true that they’ve made some progress but my work laptop running Windows 11 still has UI elements from Windows 95/NT 4. The file system hasn’t improved since then and the keyboard responsiveness is actually worse. BeOS on 90s hardware absolutely torches Windows 11 on things like UI responsiveness, ability to multitask without degrading UI performance, and the file system (not networking, of course, it wasn’t perfect).
I think it’s fair to question whether the decisions around backwards compatibility have been worth the cost but I’d imagine they’re already doing that. Enterprise IT departments love Windows but nobody else does, and the generation of people who grew up using iOS/Android and macOS/ChromeOS for school aren’t going to jump at the chance to bring that enterprise IT experience into their personal lives.
The file system is a great example of how Windows has evolved, actually. Windows 95 was (initially) still using FAT16! NT4 was using NTFS 1.2, we're now on NTFS 3.1. To the file system itself MS added (per Wikipedia): disk quotas, file-level encryption, sparse files, "reparse points" (dunno), journaling, "distributed link tracking" (also dunno), "the $Extend folder and its files" (ditto), and better MFT recovery. Also, apparently not part of the file system itself: symbolic links, transactions, partition shrinking, and self-healing. And that's just what I gleaned from the History section on Wikipedia's NTFS article; I'm sure there's more.
Apple specifically was much slower catching its file system up with Microsoft, despite their disinterest in backwards compatibility. And if Apple jumped ahead a little with APFS, well, NTFS holds its own just fine against APFS for 99% of users. And for when it doesn't, there's also ReFS, an entirely new next gen file system used on Windows Server, and is now slowly making its way onto the desktop.
Okay, I’ll grant that links and mountpoints were good but NTFS is still missing integrity checks, fast queries, etc. For most users nothing had changed since the Clinton administration.
You can actually tell the old controls from the Win NT by how fast and responsive they are. They also properly follow the best practices by showing keyboard accelerators when you press "alt".
And they also explain themself to the user. The new UI often doesn't tell you at all, what exactly you are modifying here, while the old often has paragraphs of explanation.
You can still find applications written for Windows 3.1 in the latest builds of Windows 11. Something regarding database drivers if I recall correctly.
Now imagine if you could get rid of all that legacy crap to make it work in the first place. Microsoft CAN’T do that, because the entire premise of Windows is backwards compatability.
Apple? They don’t care. Killing 32bit apps? Just make an announcement saying that in 2 major macOS releases, macOS won’t be able to run 32 bit apps. It cuts down bloat, and it cuts down on the potential attack surfaces for malicious actors.
Obviously just about everyone would agree that Windows 1 -> 7 was progress. I don’t think you’ll find too many people who’ll say the same about Windows 7 -> 11.
> Now imagine if you could get rid of all that legacy crap to make it work in the first place.
Yeah, and someone will wake from the dead and rewrite all the programs that run the world, written 20-40 years ago, that are to a large degree perfectly working under these compatibility layers.
You should be eternally grateful to MS for dedicating tons of money and some of its best people to maintaining backwards compatibility.
Apple can only afford it because pretty much nothing critical ever ran on macos.
As a dev, if you use a private method, you've just taken ownership of the problem. I suggested to you in our contract not to do it, and that it would likely not be supported, and you did it anyway. Fix your shit, common software or not.
This is what an Apple engineer could write in the electron's github issue if they refused to fix it.
We're not discussing that, but that they have pushed an update without proper testing. You can see from the other comments that breakage is not limited to people using private methods.
If this comment is to be believed, it's not Apple's fault. It's the apps mucking around with the internals of AppKit.
This example just happens to illustrate two of my least favorite software engineering practices: (1) despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation; (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality.