Why Pivumo ships AAC, not Opus

Pivumo is an early-learning app for children who cannot read yet, which makes the voice the interface rather than a feature of it. Every prompt, number, colour and reward is spoken, in twenty-nine languages, by two characters. The audio is not an asset folder — it is the product surface.

The production brief specified Opus. It is a sensible-looking choice: better quality per byte than AAC at speech bitrates, and for an app shipping thousands of voice lines across twenty-nine locales, twenty to thirty percent smaller is a real number.

The problem

On iOS, Flutter audio goes through AVPlayer. AVPlayer has no Opus or OGG decoder. An Opus-only build is not degraded on iPhone and iPad — it is silent. For a product where the voice is the interface, silent is not a bug with a severity rating. It is the app not existing.

This is the kind of thing that is invisible until integration, and catastrophic at exactly the wrong moment: after the entire multi-language package has been generated, QA-listened and licence-cleared.

What shipped

AAC-LC in .m4a as the default set, at 48 kHz — mono for voice, because speech gains nothing from stereo and doubles the size, and stereo for music. It plays natively on both platforms. The Opus set is still produced and shipped alongside, as an Android-only option, with identical file names, keys and directory layout, so choosing it is a path change and nothing else.

The general version

Format decisions belong to the platform that has to decode them, not to the pipeline that produces them. The cheapest moment to discover that is before generating twenty-nine locales, and the way to make it cheap is to play one file on the real target device early — not to read the specification and assume the runtime honours it.

Keeping both encodings behind an identical layout cost almost nothing and turned an irreversible decision into a reversible one. That trade is usually worth taking.