|
|
|
|
|
|
by lostmyoldone
2424 days ago
|
|
|
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. |
|
|
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.