We preserve the words and supported entries you are still working on when the phone locks. An unsent Ask question, session note or typed set entry should remain a draft when you return, rather than becoming either lost work or an accidental save. Recipe editing follows the same principle for its supported draft workflow.

The advantage is protection from ordinary interruption. Your phone can lock while you think, cook or train. Keeping the draft helps you continue deliberately, without pretending that unfinished text is a completed record or permission to send information elsewhere.

How it works

For an ordinary protected-data lock, Foleil carries supported draft content back to the matching reopened record. Ask words remain unsent, and typed training entries remain subject to their normal save action. Drafts are bound to the same data context and relevant session; reset, restore, an incompatible record or a failed reopen can invalidate that carry instead of attaching old words to new records.

Why it matters

Preserving a draft is different from automatically committing it. The first protects the person's work; the second can create a misleading history. Those two outcomes should not be conflated simply because both make text reappear.

Apple's Data Protection overview, accessed 19 October 2026, describes the importance of locked-device protection for app data. It gives the platform context for treating a lock carefully. Foleil's draft behaviour is a product claim to assess in its own workflow, not a claim that Apple guarantees every draft survives process termination, a restart or removal of the app.

Compared with other health and fitness tools

Strong's official Watch workout guide, dated 9 February 2021 and accessed 19 October 2026, documents editing repetitions, weight and workout notes. Foleil's reason to choose the workflow described here is the deliberate treatment of unfinished content across the connected app's lock boundary. We do not claim Strong loses drafts or infer any absence from its documentation. The relevant evidence for Foleil is whether the right draft returns without an unintended save or send.

The evidence and a practical example

Consider typing part of an Ask question, then locking the phone before sending it. After reopening the same data context, the useful outcome is your text ready to continue, with no question already submitted on your behalf. In a workout, the analogous case is a typed set row that is still waiting for Save.

Now consider a reset or the session ending before the return. Reattaching an old draft could put words against the wrong history, so this is a different case. The evidence is the exact unfinished content, the record it belongs to and its unsaved status. This example does not promise permanent draft storage or recovery after every operating-system event. Keeping ordinary lock continuity is narrower than guaranteeing that no unfinished work can ever be lost.

Frequently asked questions

Does restoring an Ask draft send it?

No. The carried words remain a draft. Opening or restoring the composer is different from submitting the question.

Does a lock save a typed set result?

No. Preserving the typed row keeps your work available for the ordinary save action; it does not turn unfinished entry into a completed set.

Does this cover a reset or every app restart?

No. The supported lock carry is tied to the same data context. Reset, restore, failed reopening and process termination have different limits.

Sources