Case study
Simple Fasting App: The engineering behind a minimal experience
Simple Fasting App is an independent iPhone app for which I own the product direction and SwiftUI development. It focuses on starting a fasting session, following its progress, and reviewing past sessions. This case explains how I approach session state, system integrations, and release decisions behind a minimal interface.
The problem: More than a timer
Showing elapsed time is the visible part. When someone edits a start time, changes the duration, or finishes a session early, history, reminders, and surfaces outside the app need to reflect that decision too. My product decision was to manage this complexity inside the application instead of turning it into more settings for the user.
My role and boundaries
I combine product direction, SwiftUI engineering, QA prioritization, and release preparation. Codex supports code review, implementation, test preparation, and release documentation. Deciding what the correct behavior should be and authorizing a release remain separate responsibilities: product judgment and publication approval stay with me.
Decision: Separate presentation, data, and system integrations
I keep Views, ViewModels, repositories, and services separate. Views present interactions; repositories handle persistence; dedicated services handle notifications, Widgets, and Live Activities. A session change is therefore not evaluated solely through the timer on the main screen.
For the Widget, session information such as start and end times is published to shared state. Progress calculations use a valid start–end interval, fall back to a controlled duration when necessary, and bound the displayed progress. The timeline also accounts for the session ending. This means designing behavior around explicit time data instead of assuming continuous background execution.
Decision: Organize checks around the user flow
I do not define testing solely by how an individual screen looks. Editing the start time, changing the duration, ending early, and completing a session are evaluated across the main app, Widget, reminders, and Live Activity. The repository contains focused tests for time and progress calculations. Device checks are a separate verification layer; a unit test does not replace observing actual Lock Screen behavior.
Outcome and limits
Simple Fasting App is published on the App Store. Widgets and Live Activities appear in both the store description and the project sources. The concrete outcome is not just a prototype, but an application whose development and releases I continue to own.
This case makes no claim about health outcomes, weight loss, or medical benefits. Nor do I treat the existence of tests as a guarantee of flawless behavior on every device. The lesson is straightforward: a minimal product experience requires the responsibilities behind it to be explicit and testable too.