Cody Cantrell

Native depth

watchOS app

SwiftUI, driven by a pure workout state machine. A real HKWorkoutSession with pause and resume; live, average and max heart rate and active calories round-trip into phone history. Starts standalone.

Live Activities

Lock Screen and Dynamic Island, with an interactive Log set button that works while the app is suspended — and says so when a set needs typed numbers first.

App Intents

Ask Buddy and Start Workout, surfaced in Siri, Shortcuts and Spotlight, plus an iOS 18 Control Center and Action-button control.

Widgets

Home and Lock Screen steps widgets that refresh themselves from the pedometer while the app is closed, and a watch complication that deep-links in.

HealthKit

Workouts, heart rate, bodyweight and steps. Phone workouts write back to Apple Health with cross-device dedupe against the watch’s own save.

Native bridges

Two custom Expo modules I wrote: ActivityKit over an App Group queue and a Darwin notification, and WatchConnectivity.

Architecture

Decisions

1. The rest timer does not tick from the app

   The Live Activity renders its countdown with a system timer interval, so the Lock Screen stays accurate. I spend the update budget only on state changes — set finished, rest started, session ended.

   TradeoffI gave up control of the countdown formatting and cannot easily show anything but elapsed or remaining time. In exchange the timer never drifts, never goes stale, and never gets throttled out mid-set.

2. The Lock Screen can log a set while the app is suspended

   The interactive Log set button writes into an App Group queue and raises a Darwin notification rather than waking the JavaScript runtime. The app drains the queue when it next runs, so the tap is durable whether or not anything is alive to receive it.

   TradeoffTwo writers now touch the same workout, which is the whole reason the queue and its drain order had to be designed rather than assumed. The payoff is a button that is honest: it works when the app is gone, and it says so when a set genuinely needs typed numbers first.

3. The AI coach proposes; the app decides

   The chat coach never writes to the program. It returns a proposed change, the app validates it against its own rules, and only then applies it. Requests go through a server-side proxy with a hard per-user dollar budget enforced atomically.

   TradeoffCoaching needs a network and costs money per user, so it can never be the only way to train — everything it suggests has to be reachable by hand too. What it buys is that a bad generation is a rejected proposal rather than a corrupted mesocycle, and that one user cannot run up my bill.

4. Offline is the default, not a fallback

   Every write lands in local state first and joins a persistent queue that syncs to Supabase with backoff and poison-entry rotation. Nothing in the logging path waits on a request.

   TradeoffI maintain a queue, its retry policy and its failure modes instead of letting a client library own them. But the app works the same in a gym basement as it does on wifi, and one permanently bad row cannot wedge the sync forever.

5. The native code is testable without a simulator

   A root Package.swift compiles the pure Swift — the watch state machine and its friends — on macOS. `swift test` runs 93 native tests in about four seconds.

   TradeoffThe pure logic has to stay genuinely free of UIKit and WatchKit for this to keep working, which is a constraint on where code is allowed to live. It also means CI can check the hardest part of the app in seconds.

Honestly

Screens

• 

  Today

• 

  Coach

• 

  Programs

• 

  Profile