This is more than just about revenue. There is massive engineering cost and complexity involved to support the EU’s demands. Interoperability is not easy to build. It slows down worldwide development pace too.

I’m not convinced that a rule that essentially says ”some API:s you have for your own devices should be made public” is a massively complex engineering project.

Sounds like you’ve never designed a public vs private API before. The difference is night and day.

Coding and documenting different API:s has been a major part of my day job since about 15 years. The only difference of note for those is the amount of available documentation.

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.

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.

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.

At the end of the day - it’s not. Apple could have the greatest tech in the world, the least complexity, but if they don’t consistently show a graph that goes up in terms of revenue- they’ll find themselves irrelevant pretty quickly.

Where are they going to find 25% to cover this loss of revenue? Nowhere