We make returning to Foleil feel like returning to the routine you were using. After a lock, eligible unchanged information stays available to the reopening workflow instead of forcing every healthy page through an ordinary cold start. The screen returns when its required records are ready and privacy allows it.

The advantage is continuity in a frequently interrupted day. You can lock the phone between sets or leave the app during dinner preparation without treating every return as the beginning of setup. This is a description of the reopen experience, not a zero-time guarantee or a benchmark against another app.

How it works

On an eligible return after a lock, Foleil carries forward supported unchanged state and prepares the records needed for the visible pages. A privacy cover stays in place until the reopened view is ready to reveal. Reset, restore, changed records and failed reopening have separate handling; the app does not reveal old private content merely to make the return look fast.

Why it matters

A fast-looking screen is useful only if it is also the right screen with appropriate information. Reopening into stale values or briefly exposing private content would trade away the meaning of continuity.

Apple's Data Protection overview, accessed 19 October 2026, explains how device protection relates to locked and unlocked states. It supports treating a lock as more than a visual pause. That is platform context, not proof of Foleil's runtime performance. Our claim remains the user-visible reopen workflow and its privacy boundary, without an invented number of milliseconds saved.

Compared with other health and fitness tools

Strong documents a connected iPhone and Watch workout experience, including Live Sync, in its official Watch guide, updated 19 January 2026 and accessed 19 October 2026. Continuity is already an important task in training software. Foleil's reason to choose this workflow is continuity across our broader daily app after a lock. We have not measured Strong's lock handling and make no claim that it restarts every page, loses information or reopens more slowly.

The evidence and a practical example

Imagine checking a workout, locking the phone and returning to it a little later. The useful result is a coherent session with the right records and no unnecessary journey through unrelated loading screens. If a reset or restore happened, however, the old view is no longer an appropriate shortcut to the new data.

The evidence is what appears after the lock: the correct current record, preserved eligible state and an intact privacy cover until reveal. A failed reopen should present a failure instead of showing the earlier private page as if it were current. Device load and required fresh reads can still introduce waiting. Instant in everyday language does not mean the app bypasses those checks.

Frequently asked questions

Does reopening take literally no time?

No timing guarantee is claimed. Required reads and privacy checks still run before the appropriate content is revealed.

Does this also carry state through a reset?

A reset or restore changes the data context. It is not treated as the same ordinary lock-and-return path.

What happens if private data cannot reopen?

The failure stays behind the privacy cover instead of revealing an old page as if reopening had succeeded.

Sources