OneBite Estimates Need a Review Step
OneBite's capture flow became clearer when recognition, local fallback, correction, and saving each had an explicit place in the meal journal.
OneBite's most interesting screen is the one before Save.
The app takes a photo or a meal description and offers a nutrition estimate. The temptation is to make that interaction feel instantaneous: capture, answer, done. But the answer contains assumptions, and saving it gives those assumptions a much longer life.
The early-September work made the review step more explicit. It also tightened the local fallback so it needs supported meal context instead of producing an estimate simply because an input exists.
Show where the answer came from
The screenshot inventory distinguishes an Apple Intelligence review state from a deterministic local-fallback review state. The saved meal editor also keeps provenance visible.
That is useful product information. A user should be able to understand why the app offered this result, particularly when the available model or device changes. A fallback should explain its limitations in the same place it presents values.
These are the two documented review surfaces from the 2 September capture pass:
The captures show supported UI states with example data. They are not evidence that the model ran in Simulator, and neither image establishes nutritional accuracy.
An incomplete input can deserve no estimate
The 6 September change required supported meal context before local estimates. That is a small implementation change with a large effect on the product's tone.
If there is not enough useful information, asking for more context is a better interaction than filling the review screen with a confident-looking default. The interface can still help: explain what is missing, preserve the capture, and keep manual correction available.
An honest failure is especially useful in a journal. It prevents one weak capture from becoming an apparently authoritative historical record.
Saving is a separate action
A proposed estimate should become a saved meal only after the user reviews it. The review is where they can correct the description, portions, or values. The later editor keeps that correction path open.
This is the part I want an AI feature to do well: reduce the work needed to create a useful record while leaving the final judgment visible and reachable. The model's answer is an input to the workflow, rather than the workflow's conclusion.
The same care applies to importing old meals
Early-September fixes also added confirmation before replacing an imported meal journal and preserved the existing journal after a failed replacement.
That is connected to the review problem. Both operations cross the line from suggesting information to changing durable user data. A quick capture should not silently accept uncertain values; an import should not silently discard existing meals.
For OneBite, the stronger product is the one that makes those transitions easy to understand. Capture starts the conversation. Review makes it useful. Save creates the record the user has chosen to keep.