You are assuming that these Apple APIs are used to give Apple a competitive advantage somehow. From what I can tell, these specific APIs don't. What they do give Apple an advantage in ironically is in forcing more developers to develop using (Apple) native APIs.
The CA prefixed ones are core animation related. Some of the others appear to be drawing frame related. I am not sure what the remote one does. None of these are giving Apple a direct advantage. I bet Electron tried to access to them to draw web pages smoothly.
The Windows API availability window gave Windows apps market advantages.
There are other private Apple APIs that do give Apple an advantage against app developers. Those advantages are in accessing physical hardware and possibly associated software, background processing, and integration (iCloud, etc...) But these aren't the bone of contention.
>None of these are giving Apple a direct advantage.
>I bet Electron tried to access to them to draw web pages smoothly.
How is this not a direct advantage? If these uncommented API calls provide a better performing solution than anything a third party can make then that is a direct advantage. Apps with that call could have a longer battery life or just run smoother.
There is a very valid reason for an API to be kept private, if it's based on internals that are too hardware-specific and you don't want to break compatibility when/if you update the hardware (so a higher-level abstraction is needed and that is in the public API) is a very fair one. Core Animation might fall into that or it might not but it doesn't necessarily is a conspiracy to keep 3rd party apps in the mud.
When you consider that Windows has to keep backwards compatibility with applications from decades ago using whatever calls to Win32, to the point of keeping comments in the source code about why some call is done that way and shouldn't be changed then it's pretty fair that a company providing a platform wants to keep a tidy, secure (or at least following their guidelines for security/privacy concerns) public API.
The Java community had a huge debacle about `sun.misc.Unsafe`, it was a private API being abused by numerous libraries[0] and when its removal was announced there was a quite big backlash about its repercussions.
I don't think that Apple is evil because of its enforcement on private APIs, there might be other issues with this enforcement but there are very valid reasons to do it.
Public core animation APIs on Apple hardware are plenty fast. I suspect the issue here is that web browsers are acting as yet another abstraction layer and thus are introducing more performance overhead. Electron is probably trying to squeeze as much performance as it can get or electron has a rendering cycle that makes it hard to have it not skip frames due to overhead. Best thing to do is to ask Electron devs.
I was wrong about some of them being drawing frame related. See https://www.cocoawithlove.com/2008/12/drawing-custom-window-.... Apparently customizing the window frame. The CA prefixed ones are correct. Apparently, at least on a Mac, it was more about battery than performance (at least for what Mozilla did) but it was still about the amount of work they were doing per frame (for Mozilla).
The CA prefixed ones are core animation related. Some of the others appear to be drawing frame related. I am not sure what the remote one does. None of these are giving Apple a direct advantage. I bet Electron tried to access to them to draw web pages smoothly.
The Windows API availability window gave Windows apps market advantages.
There are other private Apple APIs that do give Apple an advantage against app developers. Those advantages are in accessing physical hardware and possibly associated software, background processing, and integration (iCloud, etc...) But these aren't the bone of contention.