The boring answer is that they've already invested in H.264, including hardware decoding support, and it works well enough for them, so they don't need to add support for VPx.
What user benefit would there have been? Any format added has a maintenance cost (ever notice how many security updates are found in AV code) so there would have had to be some compelling benefit versus the MPEG standards they already supported.
That's especially important for battery-powered devices since the primary WebM codec (VP8) didn't offer a reason to switch from H.264 and would had to be implemented in software rather than using the optimized hardware on the device (this is why YouTube playback performance is so much worse on most systems unless you disable WebM support in your browser).
Vastly used? I'm not so sure about that. Vastly used in tandem with H264 when required? Absolutely.
If iOS can hardware decode H264 but not WebM it actually isn't in the user's interest to support WebM, because it'll reduce incentive to provide H264 versions of content, which means iOS users will experience battery drain faster.
It might not be particularly fair, but it does make sense.
Native apps like VLC can play WebM on iOS with software decoding, but as you say it murders the battery.
If Apple supported that in browsers I'd bet that Google or other companies would switch their video hosting over, much to the detriment of anyone who watches videos on an iPhone. It's an open standard so clearly they're doing the pro-consumer good thing!
Again, who benefits from this? You’re talking about duplicating a ton of work simply to have approximately the same quality.
You can contrast this with AV1 which is also a lot of work but which delivers better quality at smaller sizes. It’s not surprising that they picked that option instead.
They don't know whats best for them if there is a user who wants something different. You might invoke appealing to the mass here, that doesn't make it true however.
Netflix on an iPhone? Probably not. At least not holding it in your hand for 2 hours.
YouTube is not ‘vastly’. Get back to us when it’s ‘vast’ among commercial content providers.
Contrary to your point about not watching on iOS, I, and everyone I know, watch all content on an iOS device, both in the living room and on the go.
There is certainly a segment of the market that is using misc devices or “casting” to USB sticks plugged into TVs, but the 4K TV owning cord cutters I know tend to also own iPhones and use Apple TVs.
We saw this shift happen even more when iOS (and TvOS) gained SSO across apps with the “TV” app as indexer, and another bump when Amazon Prime released.
Why not? Just go by traffic. Youtube default to VP9 on Chrome, so yes it is vastly used. Netflix can't even display 4K on the desktop properly.
If you watch in the living room (on TV) you are not watching it on the iOS device. By that I mean the screen of the iOS device. Being in the living room, watching on TV, means you have no battery issue. Watching on your device means literally that, watching it on your device with your devices' screen. Not some casting or streaming to other displays.
It’s only vastly used if you mean “YouTube transcodes all of their H.264 into VP8 so you can hear your CPU fan”. It’s exceedingly rare to see a webm file without a corresponding MP4 file.
Because in general they are jerks when it comes to free codecs support. The fact that they joined AOM is a major shift from their previous behavior and it most likely happened because they realized they have little choice and not because they wanted to do the right thing.
Apple traditionally ignored non MPEG codecs[1], VPx is ignored for the same reason, and not due to being developed by Google.
[1] i.e. Vorbis, Theora, Flac, matroska containers, etc. Opus is supported in Safari for WebRTC because they have to, but is completely unavailable in other contexts.
ALAC did show up at the same time as the first AirPort Express in 2004, and it is the format used to transport audio over AirPlay (first called AirTunes). That may have been the original impetus.
I was under the impression it was an AAC project that didn't get adoption outside the Apple ecosystem, not that it was Apple created. Do you know whether Apple was the submitter to ISO?
It sounds like when you say "an AAC project", you're thinking of MPEG-4 ALS [1], which was the codec chosen by MPEG for lossless audio in the mid-2000s and last updated in 2009. Despite ALS being blessed by MPEG, it never achieved much acceptance in the market. Its most direct ancestor was LPAC [2], developed at the Technical University of Berlin; but ALS included improvements from NTT Communication Science Laboratories and RealNetworks [3].
Apple developed Apple Lossless ("ALAC"), a different, unrelated [4] format, which was fairly similar to FLAC, but different in some minor ways (paraphrasing the FLAC dev's own words [4]).
Actually FLAC and Opus support was added to the Core Audio / AudioToolbox / AVFoundation APIs in iOS 11.
Though the Opus decoder only supports raw packet decoding, i.e. you still need something to decode the container (usually ogg).
Also, FLAC file decoding is horribly slow - compared to the FOSS reference decoder -, because for some reason the whole file is scanned through on the first read when using the AudioFile APIs (AudioFileReadPacketData). (I’m gonna make a demonstration project for this and send them a bugreport tomorrow.)
It actually makes sense, because libFLAC has no public API for getting the compressed audio packets as is. Rice/huffmann/whatever decompression always happens inside libFLAC.
With Apple’s AudioFile API you can decide whether you want the decompressed PCM samples, or the underlying compressed packets. You can get better energy efficiency if you offload the decompression step to the dedicated coprocessor. The difference is smaller than with hardware vs software h.264 decoding, but there is a difference.
(For lossy codecs this also makes sense when you want to forward the compressed packets to a wireless speaker in order to avoid lossy recompression on Bluetooth transmission.)