PulseTrail cross-device architecture
PulseTrail is an offline-aware outdoor fitness product split between iPhone and Apple Watch. It treats location and health data as sensitive observations, and it never turns a best-effort consumer device into an emergency guarantee.
Product decision
Which device owns workout state, route guidance, sensor samples, and synchronization?
The smallest useful vertical slice is concrete: Make one workout session authoritative, then exchange versioned commands, summaries, acknowledgments, and recovery snapshots.
Boundaries that keep the design honest
- Declare one authority for the active workout and make cross-device messages idempotent, versioned, and recoverable.
- Preserve units, timestamps, provenance, gaps, and authorization state with every health or route observation.
- Design useful offline and low-power behavior before adding live transfer or decorative metrics.
- Test interruption, denied access, stale location, sensor gaps, process loss, and delayed synchronization as normal states.
- Avoid this failure: Allowing phone and watch to be simultaneous writable authorities for every workout field.
Release evidence
No PulseTrail target, HealthKit store, WorkoutKit schedule, workout session, route recording, Watch connectivity session, background execution, or physical outdoor test was exercised.
This chapter is an architecture and review artifact. Apple SDK behavior still needs the matching Xcode target, Simulator where representative, configured account or entitlement where required, and physical-device evidence for hardware or field behavior. The browser Swift runner proves none of those Apple platform surfaces.
Series navigation
- Previous: Part 117: PulseTrail product, safety, and privacy
- Next: Part 119: PulseTrail HealthKit, WorkoutKit, maps, and location
- Series index: Zero to iOS Hero