Why do they drag their feet so much regarding open codecs? It seems like they just need to take an existing dependency and integrate it in their browser, that doesn't seem like a lot of work. Maybe I'm completely wrong about that? Are there hidden complexities? Maybe they want to implement the codecs in-house? Royalty/licensing issues?
They want to only offer good options, to guarantee a certain UX. All of the codecs they do support have hardware acceleration and tend to be among the best in their class. Why would they duplicate functionality they already have?
> They want to only offer good options, to guarantee a certain UX. All of the codecs they do support have hardware acceleration and tend to be among the best in their class. Why would they duplicate functionality they already have?
This is provably false though. For example, they support Opus bitstreams either through WebRTC (because it's required) or inside their own buggy special-snowflake .caf container (so they do support the more "expensive" encoding/decoding part of Opus that could benefit from hardware acceleration), but they don't support Opus audio files (that is, the '.opus' Vorbis container which everyone uses to hold Opus audio, which is the "easy" part of supporting Opus and doesn't benefit from having hardware acceleration because there's nothing to accelerate there).
And they control their own hardware for how many years now? Their A4 silicon first appeared in 2010; they could have easily added whatever hardware acceleration they want to, but they chose not to.
Frankly I'm not sure what their motivations are. I guess they just don't care?
I’m trying to say they don’t care about anything other than the “blessed” path. Anything else is by accident. They couldn’t see a point to opus files, so they didn’t bother.
Basically anything that Apple tries to ban for anti-competitive reasons. Once this blocker is removed, no one will care about Apple bans anymore.