Sleep timers: a small feature that was harder to build than the story engine

When we listed Dreamify's features, the sleep timer was one line. When we built it, it took longer than the first version of the story engine. Here is why, for anyone building something similar.

The fade is the feature

A linear fade over thirty seconds is noticeable: the volume keeps dropping in steps a half-asleep ear can follow, and the drop itself can wake someone. Ours is long and curved, losing most of its volume slowly and the last of it almost imperceptibly. We tuned the curve by ear, in a quiet room, many times.

The phone will lock

A parent sets the timer, puts the phone face down and leaves. The screen locks, the app goes to the background, and the timer still has to fire and still has to fade. That means proper background audio handling and a timer that does not depend on the app being on screen. It also means the lock screen controls have to keep working and have to reflect the fade correctly.

After the fade: nothing

The obvious design is an end screen or a "play another" prompt. Both are wrong at bedtime. After the fade, the app goes silent and stays silent. No chime, no notification, no auto-play. If the story ends before the timer, the same rule applies.

Interruptions

A phone call, another app playing audio, headphones disconnecting. Each one interrupts playback in a different way, and the timer has to behave sensibly in all of them: pause, not reset; resume where it was, not from the start; never blast audio at full volume after an interruption.

How we tested it

Not in a simulator. On real devices, in real rooms, with the lights off and, eventually, with children who were actually falling asleep. A feature that is correct in the test suite and wrong in a dark bedroom is wrong.

Why it was worth it

Because the sleep timer is the moment the app proves it understands what it is for. Everything before it is a story. The timer is the part that lets a parent walk away.