Offline workout logging: what a tracker has to get right when the gym has no signal

What offline has to mean

Most apps claim offline support and mean "the app opens". For a workout logger that is not enough. You are mid-session, the sets are coming every two minutes, and the phone is in a basement. The app has to keep accepting sets, keep the rest timer running, show you the session you started, and, when signal returns, get all of it to the server without duplicating or dropping anything. If the same workout was touched from another device in the meantime, it has to reconcile without throwing your sets away.

What Method keeps on the phone

The session draft. Every set you log is saved to the phone as part of a workout draft, along with notes, custom rest durations, exercises you removed, and cardio completions that belong to the session. The draft carries flags for whether it needs sync, is queued, or hit an issue.

Cached reads. Programs, the calendar, history, and analytics you have already loaded are stored on disk per athlete. When you are offline they stay visible, with a banner that says "Offline, showing cached data" and the actual time of the last sync, rather than a generic warning.

Your sign-in. The session snapshot is held in the Keychain, so the app opens authenticated without a round trip.

The rest timer, Live Activity, and notification run on the phone and do not need a connection.

How sync happens

When the app sees a connection, queued drafts are sent in order. Method is deliberately optimistic at launch; it assumes online until the network proves otherwise, so a brief blip does not trip the app into offline mode and stall a sync that would have succeeded.

Each result from the server is classified as retryable or terminal. A retryable failure, a timeout for example, is tried again. A terminal one, such as the workout having already been completed elsewhere, is handled rather than retried forever.

Conflicts without losing work

Two rules do most of the work.

Merge by intent. When the phone's draft meets the server's version, Method does not compute a blind difference. Removals only apply to the exercises and sets you explicitly removed on this device. Anything added on another device stays. Exercise swaps keep their slot in the order. Set rows are matched by their stable ids, with safeguards so two local rows can never both claim one server row. Weights and distances are converted into the server's display units during the merge so a unit preference change on another device cannot corrupt a number.

Never discard. If the server says the workout cannot accept your draft, because it was completed elsewhere, is no longer editable, or no longer exists, your local work is re-attached as a separate ad hoc workout. You see the message "This workout changed elsewhere. Your progress was saved separately." The sets are in your history either way.

Cardio and Apple Watch

Cardio activities recorded on the phone are drafted with a write-ahead journal so an interrupted save cleans up correctly. Activities recorded on Apple Watch are queued as durable envelopes on the watch and uploaded through the phone when a connection exists. Apple Health imports run in the background when the phone can reach the server; if it cannot, they wait.

Edges to know

• The web app needs a connection. It plans and reviews; it does not log.
• Suggested loads are computed by the server when a session is loaded. Offline, you see the suggestions that came with the session the last time it was loaded.
• Draft storage is on the device. Deleting the app before a draft has synced loses that draft.