PulseTrail offline, battery, sync, and failure recovery
PulseTrail is an offline-aware outdoor fitness product split between iPhone and Apple Watch. Its system surfaces are projections of one durable session, not competing sources of truth.
Product decision
How can the app preserve a workout through disconnection, process loss, low power, and delayed transfer?
The smallest useful vertical slice is concrete: Checkpoint the authoritative session locally, batch samples, acknowledge transfers, and merge summaries by stable session and revision identity.
Boundaries that keep the design honest
- Keep the active workout authoritative on one device and make cross-device operations replayable and idempotent.
- Budget sampling, rendering, storage, and transfer from user value and measured energy cost.
- Preserve raw provenance and gaps while presenting clear derived summaries.
- Require physical-device and outdoor evidence for sensor, background, battery, and field-recovery claims.
- Avoid this failure: Sampling and transmitting every signal at maximum frequency regardless of product value or energy cost.
Release evidence
No PulseTrail application, watch app, complication, widget, Live Activity, HealthKit session, background transfer, energy profile, or physical outdoor journey was executed.
This chapter records product and architecture decisions. Apple framework behavior still requires the matching Xcode target, configured service or account where applicable, and named Simulator or physical-device evidence. The browser Swift runner does not validate these Apple SDK surfaces.
Series navigation
- Previous: Part 120: PulseTrail watch UI, complications, widgets, and Live Activities
- Next: Part 122: PulseTrail testing and release review
- Series index: Zero to iOS Hero