What are the tradeoffs? For their own devices nothing changes, and for other devices they need to spend some extra integration work to make sure there's a standard they follow but that work should pale in comparison to the main engineering.
Apple loses the forced bundling but they'll do fine without it and it's a good thing for everyone else.
> for other devices they need to spend some extra integration work to make sure there's a standard they follow
Have you ever built a software product with an API? Would you say it was trivial upfront and ongoing to build and support this API?
Why would Apple have to endure this burden. If a 3rd party maker cannot make their device work the same way with the proper access, it is their own issue and not something Apple should help them figure out. The proper access is the key part, but once that access is open it is up to the devs to figure it out. If their product still has a subpar user experience, that'll be something the market figures out for them
> If a 3rd party maker cannot make their device work the same way with the proper access, it is their own issue and not something Apple should help them figure out.
This is NOT expected from Apple and explicitly noted in the ruling.
They are simply not allowed to restrict OS features from competitors in order to frame them as Apple accessory features, because this distorts the competition in this accessory market
I'm not asking for anything beyond proper access.
Your "they" is ambiguous so that I interpreted it as Apple needing to spend extra time.
You interpreted that word correctly. But I would say that part of "proper access" is that it needs to meet basic interoperability levels. That much is Apple's job, and it's not a very big job.
I'm not asking for them to do any work beyond that level for non-Apple devices. If those devices need to run fancy code to make the feature work, that fancy code isn't Apple's job.
(But if the feature just needs to listen to the microphone feed, then I do expect it to work out of the box with any headset. (The firmware updates they're doing to older airpods are not clear evidence one way or the other whether it actually needs on-headset support.))
> Why would Apple have to endure this burden.
The same reason they endure the burden of safety certification and employment requirements: it’s the law. It’s not exactly a new concept.
Saying something is the law is never a valid argument in discussions like this. There has been multiple historic examples of things being the law until everyone realized how unethical the original law really was.
Yes, but for now that's the law. So, the pragmatic answer is: they have to do it because otherwise their stuff will be pulled from the shelves and they will be fined. This does not prevent them from discussing with the Commission, which they are already doing, or lobbying for changes in the regulations, which their are also already doing within the limits of the political system.
It's not an argument, it's a factual answer. Apple has to comply with the law.
And yes, it also happens to be a good law that promotes competition and curbs anti-competitive abuses.
A third-party maker literally CAN NOT make their devices work the same way.
"Can not" as in "unable because Apple doesn't allow that". All Apple needs to do is whitelist access to certain APIs and provide minimal documentation.
No, that's not so. One of the relevant rulings (https://ec.europa.eu/competition/digital_markets_act/cases/2...) dictates that merely providing any API isn't enough. Among other requirements, the API must "properly consider the needs of third parties that will make use of the solution", it must be "properly tested for bugs or other shortcomings", and Apple must "provide adequate and timely assistance to third parties that report issues". A barely hacked-together API that's hard to use without constantly pinging the team who implemented it - entirely normal for the first release of a big new feature - wouldn't be enough.
Yes, and?
> A barely hacked-together API that's hard to use without constantly pinging the team who implemented it - entirely normal for the first release of a big new feature - wouldn't be enough.
Oh, so Apple can't be bothered to be held to the same standard as, say, automotive developers?
Ahh, I see the problem. This may come as a shock to you: a phone is not a car.
Yes, a phone is vastly more important than a personal car right now. You can easily live (especially in Europe) without a car, but a phone is indispensable.
I would have more sympathy for Apple if they behaved ethically, respecting developers and users. They absolutely do not behave ethically, preferring to exploit everything they can.
Turnaround is a fair play, so I'm going to shed zero tears if Apple is forced to spend a couple hundred million dollars (at most) adapting their internal documentation for their APIs.
I don't understand the analogy. Are auto manufacturers in the EU required to publish a detailed spec and robust API for third party backup camera developers?
They are required to provide detailed repair manuals, spare parts, and diagnostic software to independent repair shops.