Ahmad Dibo© Notice

B5

01 Premise

Motus is a voice-driven strength-training app for iPhone and AirPods. It runs a session through the headphones: it announces the next exercise with last session’s numbers, listens for what I did, logs it, times the rest and moves on.

I built it for how I train. My split is an eight-slot rotation (push, pull, legs, rest, chest and back, arms, legs, rest) that drifts against the seven-day week, and I work through each session in a fixed order. The apps I tried pinned workouts to weekdays, reopened the exercise library after every set and congratulated me for finishing. I wanted a ledger that holds the order, states the numbers and says nothing else.

The founding constraint was that the phone stays in my pocket, locked, for the whole session.

Can a full strength session run by voice with the phone locked in my pocket?

Motus home screen reading “Hi Dibo, Ready to start legs?” above a Start workout link.
Home
Programs screen listing Arms, Chest & Back, Legs, Pull and Push with exercise counts, above a November calendar marking training and rest days.
Programs and rotation
Chest & Back program listing six exercises in order, each with its last weight and reps.
Program order
Session screen for shoulder press, set 2 of 2, listening, with the transcript “7 at one sixty five” and the sets logged earlier in the session.
Session

02 Methods

The constraint rested on three untested assumptions about the hardware. Before any product code, each was tested on device with a throwaway app and a pass condition written in advance.

The first swept audio-session configurations with music playing from another app, including a control known to degrade audio. The second locked and pocketed the phone during live capture and counted audio buffers. The third, whether an announcement fires from a locked phone, is still open.

03 Findings

The AirPods microphone and full-quality music do not coexist. Across four configurations the system granted one or the other, never both. The iOS 26 option built for this case reported itself supported and declined to engage, silently moving capture to the phone’s own microphone. The one configuration that captured from the AirPods, the hands-free control, dropped music from 48 kHz to 24 kHz.

Capture stops when the app leaves the foreground. Through a lock and an unlock the buffer count held at 162 for twelve seconds while the engine reported itself running, with no error. The background audio permission I had relied on covers playback alone.

Together the two findings close the original design. Full-quality music requires the phone’s microphone, and the phone’s microphone requires the app in front. No configuration is hands-free, pocketed and music-safe at once.

  • Fig. 01 Audio Session Configurations
  • Fig. 02 Capture Across a Lock

04 Design response

Only the input path failed, so the loop was split along that line. Announcements, rest countdowns and chimes are designed to reach me with the phone locked in my pocket. Spoken sets and corrections happen with the phone in hand and the app open, for a few seconds per set. The promise became never operating the phone: no menus, no tapping, no typing.

The schedule carries no weekday. The rotation is an ordered cycle of slots with rest as a slot of its own, advanced by a completed workout and anchored to the last session I finished. Elapsed days consume rest slots and never a training slot, so finishing legs on Friday puts chest and back on Sunday, and a skipped Sunday moves that session to Monday without comment.

  • Fig. 03 The Split Loop

05 Gym speech

Gym speech breaks ordinary number parsing. “One thirty five” arrived as 1:35, and a remark to someone across the room arrived as a set. The parser is a closed grammar that rejects anything it does not match: a rejection costs one repeated sentence, and a wrong number costs a false entry I will never notice. Its specification is 84 spoken phrases, at 0 failures and 0 plausible-wrong parses. The session screen keeps the last logged set in view, so a misheard number is caught before the next.

06 Discussion

Two of my assumptions were reasonable readings of Apple’s documentation, and both failed on the device within minutes. Reasoning could not have reached either result. Measuring first cost a week of test code and kept the product from resting on an API note I had read too generously.

The same rule runs through the build. A misheard number is refused, rep counting from head motion is left out because a counter wrong one set in twenty makes me check all twenty, and no weight is converted between units. In a log with no read-back, a wrong entry costs more than a missing one.

The third measurement is still open. Announcements from a locked phone are designed to work and have not been measured, and until they are, the pocketed half of the session is a design claim.