> The fact that they adopted AVIF relatively swiftly

Can be linked to Apple being a governing member of AOM.

> and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.

Feel free to hold your breath, but I don't think that'll be good for your health.

The webkit bug for AVIF was opened in February 2020, an "initial support" patch was proposed in May, support was merged in March 2021. Apple separately shipped the decoder[0] in iOS and macOS in September/Octoboer 2022, and enabled the feature for Safari.

The webkit bug for JXL was opened in February 2020. That's about all that's happened to it. Reaction has been:

- Webkit is not super interested in adding a bunch of third-party unsafe code[1]

- Safari support requires OS support, which is non-existent for JXL[2]

[0] Webkit on non-apple platforms can use Webkit's decoders, on Apple platforms it uses CoreGraphics, though as seen with HEIF having CG support doesn't mean Apple enables the format in Safari.

[1] https://lists.webkit.org/pipermail/webkit-dev/2021-May/03184...

[2] https://lists.webkit.org/pipermail/webkit-dev/2021-May/03185...

They’re working on ending the OS-parity nonsense with AVIF. https://webkit.org/blog/13584/release-notes-for-safari-techn...

To be clear I didn’t say I’m holding my breath. Just that it’s not “obviously” impossible.

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.

Apple dragged their feet on introducing webms to Safari and they still often require fiddling with to get working on iOS. If Apple isn’t jumping at supporting a format, it’s generally safe to assume they’ll do all they can to not support it unless the pressure is overwhelming.

Which doesn’t seem to be the case with this format.

Apple is a company that cares deeply about usability. Once JPEG XL reaches critical mass in photography or creative work (video mastering, image processing, graphics and similar), Apple will very likely be the first to add support. Their users much rather have a thumbnail than a stock icon for photographs and graphics. I wouldn't be surprised if JPEG XL support would be announced by mid 2023.