Skip to content

Blog

Adding more supported formats is what broke it on iPhone

3 min readWritten by the site’s operator

Accepting more file formats seemed like an obvious improvement. It broke the site on iPhone. Entirely self-inflicted.

The tools here used to be fairly strict about which files they would take. That looked like unnecessary friction, so the lists were widened on the principle of "be generous and let the decoder decide": `ogg`, `opus`, `wma`, `amr`, and for video `mkv`, `avi`, `wmv`, `flv`, were added to every picker.

A failure report came in from a real iPhone almost immediately. Safari on iOS can decode none of those.

Widening the gate threw away the signpost

The shape of the breakage is the interesting part. Before, choosing an unsupported file produced a clear "this format is not supported". Afterwards, with the gate gone, the file travelled all the way to the decoder, which returned its own terse "decoding failed" and nothing else.

From the visitor’s side the second is plainly worse: no indication of what was wrong or what would work instead. The restrictive version had been the more helpful one, precisely because it was restrictive.

Ask the browser instead

The picker is now built by asking the browser itself what it can play. That capability report is answered at runtime and is correct on every platform, including ones that have not shipped yet.

Hand-written list37 typesAfter asking the browser25 typesDropped in this build: .wma / .amr / .avi / .wmv / .flvAn iPhone is offered the 23 formats it can actually open, and never sees the 14 it cannot.
How many extensions the picker offers. Instead of a fixed list, the browser’s own answers narrow it.

Measured, this build went from 37 extensions to 25, dropping `.wma`, `.amr`, `.avi`, `.wmv` and `.flv`. Offering a choice that cannot work is worse than not offering it, so this is a straightforward improvement.

The answer is not perfect either

There is a second trap underneath. "Can you play this?" and "can you decode this?" are different questions, and they do not always agree. Measured here: `aiff` and `quicktime` both report that they cannot be played, and both decode perfectly well.

So the capability report is used only to shape the picker and the error text — never to refuse a file. Anything it drops still reaches the decoder if you pick it anyway, and the decoder remains the final authority.

What this means if you are on iOS

When an audio or video file will not open on an iPhone or iPad, the usual reason is simply that iOS cannot handle that format. It is not a broken device or a broken app. Treat `ogg`, `opus`, `wma`, `amr`, `avi`, `wmv` and `flv` as unlikely to work.

If a computer is available, converting to MP3 or MP4 first with file conversion is the reliable route — H.264 MP4, MP3 and M4A open almost anywhere on iOS. The conversion also happens inside the browser, so nothing has to be handed to a server on the way.

The stem separation in this article runs free in your browser — no sign-up, and your audio never leaves your device.

Next article

2 min readThe browser said it could do it, and produced a broken file

The API that reports supported recording formats returned true, and the result was a corrupt 1,690-byte MP4. The four measurements, and why the fix was to stop asking and start measuring.

All articles

Sponsored links