[_1tem]

The entire premise of Apple is building highly tuned private APIs. It’s what makes things like Apple Silicon battery performance and power to watt ratio possible. This kind of super fine tuning is practically impossible over a public API boundary, or at least much more difficult task. Take Live Translation for example. It has very tight latency and performance requirements which would be hard to make work over a public API where you can’t control the other device. Many types of audio applications are literally impossible to build on non-Apple devices due to the latency requirements. There is an entire audio ecosystem that cannot exist on Android due to the realtime performance requirements.

[Y-bar]

I see now where you don’t understand the issue.

The ease of implementation is not part of the question. Apple is just not allowed to hide these API:s (eg. Low latency audio and bluetooth pairing) and then block and punish any competitor who tries to use them.

[_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.

[_1tem]

It’s not about ease of implementation. It’s impossible to build Apple Silicon level of quality in power to watt performance or realtime audio apps over public APIs. Just look at how open source devs failed to fix battery issues with Framework Laptops or build realtime audio over Android. You can’t get Apple quality performance over a public api.

[Y-bar]

Then effing let them try? Apple, if you are correct will provide 100% of the best products every time. If it is so impossible, why have a corporate policy to punish competitors who try? They will obviously inevitably fail according to you.

[_1tem]

It’s about the fact that opening your API limits your own engineering capabilities. A device with an open API has a different security and performance profile.

So Apple has to sabotage their own devices performance and security to let other people use it. The EU has no business in this.

If Apple provided public APIs for their products their own mobile devices battery life and security would be worse due to crappy third party integrations. Apple achieves high performance experiences precisely because that is a ENGINEERING REQUIREMENT to build high quality products.