Hacker News Reader

Comment by Y-bar | Hacker News Reader

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.

View on HN

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

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

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.

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

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com