Someone logging a meal on their phone does not check their signal first. In Nutriflux, actions like logging a meal or a glass of water, locking a plan, following someone or joining a challenge have to feel instant whether or not the phone is connected.
The design that looks fine and is not
The easy approach is to update the screen immediately and send the request in the background. If the request fails, the screen is now showing something the server never received. The user believes it is saved. It is not.
An outbox
Instead, when a write cannot reach the server it goes into a queue on the device. It is kept there, in order, until it can be sent. The screen is updated straight away so the app stays responsive, but the app knows the difference between "shown" and "confirmed".
When the connection returns, the queued actions are sent in the order they were made. Retries are limited, and an action that cannot be delivered is surfaced so it can be dealt with instead of being dropped.
Each queued action carries what it needs to be recognised if it is sent twice, so a retry after a dropped response does not log the same meal again.
What the interface owes the user
Offline support is not only storage. The app has to be honest about state: what is waiting to sync, what failed, and what happens if something newer on the server disagrees with an older queued action.
Where the line is
Not everything is queued. Actions that are safe to replay later are. Anything that depends on the server's answer at that moment waits for a connection.
The result is a mode that is slower but truthful, which is better than a mode that looks fast and loses data.