[thothamon]

I feel Apple is moving into somewhat dangerous territory. If the intent, as documented by internal messages and emails, is purely to protect the consumer by forcing people to use only public APIs, that's one thing.

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.

[coldcode]

This is nothing new, developing iOS and MacOS apps you use public APIs and never use private ones. I have never had any desire or need to use something not documented/public in anything I have built. You'd have to be pretty dumb to depend on something that Apple can and will change whenever they want. When I worked at Apple 25 years ago I remember the source code to the old MacOS was riddled with "if Word version 4.05 do this, if 4.15 do that" to try and avoid breaking Microsoft's apps". It was a nightmarish attempt to ensure buggy software didn't suddenly stop working. I don't blame Apple for wanting to avoid this kind of pain today.

[thothamon]

Valid points. My worry is if this is being exercised inconsistently. Is the same rule applied in the same way to everyone? Even Apple granting itself exceptions isn't great -- and I know it does grant this exception to itself -- but if it grants exceptions to some third parties but not others, or does not faithfully and consistently enforce the rule for everyone, that would be extremely troubling.

[duskwuff]

I think the intent of these rules is (and generally has been) to allow Apple to classify APIs into "public" and "private" categories, where the public APIs are documented, and will not change or be removed without plenty of notice, and the private APIs aren't any of those things.

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.

[scarface74]

Having public and private methods has been an industry standard forever. As has the understanding that you don’t depend on private methods.

[bdcravens]

Apple has banned the use of private APIs for years.

It's only anticompetitive if they selectively apply those rules.

[lostmyoldone]

They have selectively applied them to themselves for ages as far as I know. Which must be regarded as anti competitive to some extent.

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.

[dwaite]

> They have selectively applied them to themselves for ages as far as I know. Which must be regarded as anti competitive to some extent.

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.