Is this an attempt by Apple to increase robustness by reducing dependencies on unsigned binaries?
However, this is not really about unsigned binaries. These APIs are from OSX itself. This is about access to private APIs. These have no contract and can be changed at any time, as they were not intended for public consumption.
But, if Apple is trying to apply anticompetitive behavior against certain technologies, if this rule is selectively enforced, if there is any bad smell or anything dirty about this process, then Apple is inviting antitrust scrutiny or new laws.
Apple had better make sure it is squeaky clean on this.
In some cases, private APIs are used as implementation details of public APIs. For example, the symbol "NSNextStepFrame" sounds like it might be part of the implementation of NSWindow. In some other cases, Apple has made early versions of some APIs private before later releasing them publicly -- for example, the Catalyst APIs (UIKit on macOS) was a private API for a while before being publicly released, allowing Apple to test the APIs (and potentially make backwards-incompatible changes) before external developers started using it.
It's only anticompetitive if they selectively apply those rules.
It's also pretty much a straw man kind of argument around the public/private API distinction as important to prevent applications from breaking, as it seems to be the rule rather than the exception that lots of apps break on iOS updates anyway.
They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
This only affects the App Store, which Chrome quite purposely is not part of and which the vast majority of Apple apps aren't distributed through.
> They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
My understanding is that the inefficiencies in question come from a need to bridge from cross-platform code into the public APIs.
For example, one of the private functions mentioned was needed to treat mach ports as file descriptors - not needed if you are using the proper API to deal with ports.
My understanding is the CoreAnimation private calls are because the layers are rendered and composited externally and CA is only being used for display. Because the rest of CA is skipped, it can't determine a list of partial changes and thus performs a lot more work than necessary. The Private calls are being used to force CA to skip rendering parts of parts of the display. Safari doesn't need to do this because they are using the proper API for the entire pipeline.