PulseTrail HealthKit, WorkoutKit, maps, and location
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
How should authorization, units, routes, background sessions, and provenance shape an outdoor workout?
The smallest useful vertical slice is concrete: Record workout and route samples with explicit source, unit, authorization, interruption, and completion states.
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: Hiding denied access or converting measurements without retaining unit and source metadata.
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 118: PulseTrail cross-device architecture
- Next: Part 120: PulseTrail watch UI, complications, widgets, and Live Activities
- Series index: Zero to iOS Hero