3 ms·

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 bui

by _1tem 1y ago

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.

Y-bar 1y ago
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.
- _1tem 1y ago
  Sounds like you’ve never designed a public vs private API before. The difference is night and day.
  - Y-bar 1y ago
    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.
    - _1tem 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        > 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 1y ago
        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.
        1y ago
akmarinov 1y ago
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

by _1tem 1y ago

Y-bar 1y ago

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.

_1tem 1y ago
Sounds like you’ve never designed a public vs private API before. The difference is night and day.
- Y-bar 1y ago
  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.
  - _1tem 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        > 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 1y ago
        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.
        1y ago

akmarinov 1y ago

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