Why I Rebuilt Boop v2 Around Inspectable Evidence

Boop started as a narrow bridge: read supported history from a compatible WHOOP Strap and move the useful parts into Apple Health without adding another account or health-data cloud.

Version 2 keeps that local-first core, but the app is now much closer to a full daily health and training companion. It includes Strain, Recovery, and Sleep scores; a more complete day view; activity and fitness detail; a Health Monitor; and direct Strap controls for alarms, timers, and double-tap actions.

The visible redesign is substantial. The architectural change matters more: Boop should not show a confident number unless it can explain why that number is available.

A score is a receipt, not a decoration

Recovery and sleep interfaces make it tempting to lead with three large circles and fill in the reasoning later. That order creates a fragile product. If a night is incomplete, a baseline is still forming, or one input arrived after the screen loaded, the UI can look finished while the underlying claim is not.

In v2, derived values are treated as versioned results with inputs and readiness conditions. A score can distinguish between unavailable data, a forming baseline, a provisional result, and a complete result. The user should be able to see the signals that contributed rather than receiving a black-box verdict.

This is especially important because Boop is independent wellness software. It is not affiliated with WHOOP, Apple, or Bevel, and it is not a medical device. Transparent inputs do not make a wellness estimate clinical; they make the product honest about what it calculated.

The day view had to finish progressively

A local-first app has a different loading problem from a server dashboard.

Some data is already persisted. Some is available immediately from Apple Health. Some arrives from a live Strap stream, and older history may still be moving in chunks. Waiting for every source before rendering makes the app feel stalled. Rendering everything as final on the first frame makes it wrong.

The v2 day view is built around progressive completion. Stable persisted values can appear first. Live status remains visibly live. Dependent sections finalize when their own evidence is ready rather than when one global spinner decides the entire page is done.

That same principle applies after interruption. Background delivery, a Bluetooth disconnect, or a killed process should not force the app to start the logical operation from zero. Durable checkpoints let Boop resume the work it can prove was not completed.

Health Monitor without a second health cloud

The Health Monitor brings together signals such as heart-rate variability, resting heart rate, respiratory rate, blood oxygen, and temperature when the device and available sources support them.

Boop still does not operate a health-data backend. Processing remains on the iPhone, with Apple Health used for the fields the user authorizes. Optional Health access should improve the experience, but local Strap-derived behavior cannot disappear merely because one export permission is off.

That separation sounds small. It prevents a common product failure where a permission for one integration accidentally becomes the master switch for unrelated local functionality.

Strap controls need the same truthfulness

Alarms, timers, and double-tap actions are not ordinary form controls. A button press in the app is the beginning of a command sent over an unreliable radio link, not proof that the Strap accepted it.

The interface therefore needs distinct sending, confirmed, failed, and recoverable states. It should retain the intended value while reconnecting and avoid pretending an optimistic local toggle is already hardware truth.

This is one of the recurring lessons from building Boop: connected hardware turns tiny interface states into part of the protocol.

A one-time full version, when released

The intended product model keeps the existing core free and makes the full version a one-time purchase rather than a subscription. That direction fits a local app with no Boop account and no ongoing health cloud to fund.

It also raises the bar for the product itself. A lifetime unlock should buy a durable capability, not dependence on a remote service I might later switch off.

This describes the product and implementation direction, not proof that a specific in-app purchase is available in a distributed build. Boop has an open external beta, while this article describes the v2 candidate architecture; a candidate build and a tester-installable build are separate release states. The current beta link, compatibility notes, privacy details, and methodology live at boop.band.

The goal is not to clone another wearable dashboard. It is to make the data, controls, and reasoning more inspectable while keeping ownership on the device.