Maintenance Log

Concluded that HKWorkoutSession is a healthd (system daemon) level resource that app code can't fully control. os_log/Console.app tracing pinpointed the exact cause, but with no fix possible without side effects, this was documented as a known limitation for v1.0.

Accepted the reality that most people aren't looking at their phone while a Watch-led run is happening. Decided iPhone didn't need to mirror it live, and deliberately narrowed the scope to match actual usage instead of chasing full bidirectional mirroring. This walks back one of the four scenarios that entry #01 (mirroring redesign) had originally built out.

Entry #09 already removed Watch-led mirroring itself, but the code that let iPhone receive Watch's mirrored session back was still sitting there. Now the start side is decided by iPhone alone, full stop, and the stop side confirms it's the same run via the shared session ID.

A side effect of disabling retrieveRemoteSession() in entry #10. A reminder that removing code means checking what else was quietly leaning on it too - this time, a completely different function's branching logic.

When two unrelated jobs - "cleanup for a screen transition" and "defensive reset on restart" - live in the same function, a change meant for one keeps leaking into the other. Splitting responsibility by function was the whole fix.

Delete-and-reinstall testing never exercises the migration path at all. Any schema change now gets checked at least once via an in-place update from the prior version.

An API that buries failures inside a result value instead of throwing means "success-shaped failures" need the return value itself checked, not just the absence of an error. It's also easy to forget that the Dashboard's own query and the app's code can hit CloudKit very differently.

Fixed both on-device ducking bugs, and 1.4.1 solved which device reads the split while mirroring. What remains is a watch-only run while music plays on the iPhone. The system decides who owns the audio stream, so a Watch app has no way to touch the iPhone's session. Added a note in the app's announcements screen instead, asking users to play music from the Watch itself. Not every problem gets solved by code. Sometimes an honest heads-up is the actual answer.

A common but easy-to-miss arithmetic bug - when the starting point and the step size aren't multiples of each other, that mismatch just keeps compounding.

This bug wasn't introduced all at once, it came from two separate changes made while preparing v1.3 overlapping. First, stationary detection was reworked from scratch around raw speed. Later, for a completely unrelated reason (suppressing false alerts from a resting heart rate), freeze-while-stationary logic was added on top. Each change was reasonable on its own; nobody realized at the time that the rule in stationary detection could break the assumption the later freeze logic depended on. It was a bug that only showed up in the relationship between two changes, not in either one read alone.

At first this looked like reducing two savers to one. It was really about deciding which device owns the save. Without that decision, blocking one side meant nobody saved on the blocked path and both saved on the other. Removing a duplicate and deciding an owner were different jobs.

onDisappear cannot tell "the user left" from "another screen covered this one". The larger lesson sits elsewhere. Both wrong hypotheses came from reading code; the right one arrived only after the reporter said they had not viewed the summary. Told the repro failed, I questioned the recipe instead of the hypothesis. For a bug someone else hit, no amount of reading fills in the conditions. Only they know them.

Only one save path goes through the subscription, which is why the other three looked fine. The ghost had nowhere to show itself there. It was also receiving every other subscription from init(), not just stop signals; the failed save was simply the most visible symptom. That a @State initial value gets built more than once was known. That a discarded copy keeps working once subscriptions are involved was not.

What changed was the order, not the save. Why the watch's save stalls on some runs and not others is still unknown. It is not length and it is not volume: the six-hour run wrote far more and finished, while the stalled one wrote to the database faster. The fix did not depend on that answer, though. The iPhone never had a reason to wait on the watch's save in the first place. Explaining a fault completely and removing what the user lives through are not always the same piece of work.