[_1tem]

There is simply no good way to make the API public while maintaining the performance and quality expectations that Apple consumers have. If the third party device doesn’t work people will blame Apple even though it’s not their fault. Just like how consumers blamed Microsoft for BSODs even though it wasn’t their fault.

Edit: the evidence for my claim - just look at how realtime audio apps with tight latency requirements can’t work on Android

[Y-bar]

> There is simply no good way to make the API public while maintaining the performance and quality expectations that Apple consumers have.

You have no evidence for any of these two claims. From my professional experience it is 100% possible. Making a API public seldom, if ever, requires changes to called code behaviour. Not punishing competitors who tried to use your API is also not requiring any code changes, it is a policy decision.

[_1tem]

Evidence: Open source devs and Google and Microsoft have been trying to build MacBook Pro laptop performance for decades and failed. The entire performance advantage of Apple products is due to their tightly controlled integration of the hardware and software stack.

Apple consumers have come to expect this level of quality from Apple products. It is unreasonable for the EU to demand interoperability with other products when the very thing that makes Apple products work well depends on tight integrations that are not interoperable.

[Y-bar]

None of that has anything to do with secret/private API:s and corporate policies forbidding anyone else from using them.

[_1tem]

In order to build a high performance product you have to control all of the API surfaces. Apple devices battery life would suffer if any shoddily written third party device could operate with crappy drivers for it.

[Y-bar]

Again, that has nothing to do with why Apple considers it okay to punish other companies who wants to use those API:s. Apple is under zero obligation to make the API:s easy to implement, it’s just that they cannot forbid anyone from using them, no matter how complex you imagine them to be. No matter if only engineers at Apple has the mental acuity to understand them, no matter if Apple by laws of nature is the only company in the galaxy that could design such silicon to be able to use the API effectively, and so on… Apple is under no obligation to change the behaviour of their API:s to accommodate competing products, they are just not allowed to hide them from and punish competitors.

[_1tem]

I, as an engineer, absolutely support keeping private APIs private in order to preserve the performance of products. This is a good policy decision and a good engineering decision. Allowing others to build products on top of private APIs creates false user expectations. The user doesn't know the difference between a public or private API, they just expect their devices to work properly. If you allow a private API to be abused, then third parties may create crappy products (such as fake AirPods) which will ruin the battery life and security of Apple devices. The user doesn't know who to blame, Apple or the third party. It is absolutely within Apple's rights to protect their private APIs from misuse in order to preserve security and performance of their products for all users. The user is free to choose a different brand if they want interoperability. I, as an Apple user, want security and performance, not interoperability. If I wanted interoperability I would choose Android. The EU has no right to force Apple to become crappier like Android.