They’re not working on anything, this just means the WebKit previews or the odd product which embeds WebKit rather than use webviews can run regardless of OS support.

Apple ain’t going to enable features they don’t support on safari.

That’s Safari’s preview.

No, it is not. It's webkit. Safari is based on webkit, but the webkit project at large does not decide what does and does not go in Safari.

That's why there are regular "Webkit features in Safari X": that something is added to webkit does not guarantee it'll land in Safari, ever.

Hell, it took 18 months and 2 iOS/macOS releases for the AVIF support to go from landing in Webkit to landing in Safari. And that was something Apple wanted.

> Just that it’s not “obviously” impossible.

Neither was webm support, but that didn't stop them from taking several years to implement it (and even then it was half-finished). Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop.

Nothing is technically impossible for Apple, but codec support is stuck between an ideological/financial rock and a hard place.

> Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop.

And on the other end you have Google who threatens others if they don't bend over and implement Google's codecs in hardware [1]. The codecs space is, and has always been, a game of shitty players.

[1] e.g. https://www.protocol.com/bulletins/av1-android-14-requiremen... and https://www.protocol.com/youtube-tv-roku-issues

AV1 is a more open codec than MOV or AAC, so it's not really any shittier of a play than Apple demanding third-parties use AAC for every iPhone accessory.