Independent product · 2023 to 2024

Balance

A health and wellness app I built to learn iOS, and later learned to critique.

Role: Sole designer and developer
Stack: SwiftUI, SwiftData, HealthKit, Firebase
Scope: Concept, IA, UI, full implementation
Status: Complete not released publicly

Read this one differently. Balance was an engineering project. I wanted to learn Swift properly, so the code got the attention and the interface got what was left. I am including it because building it changed how I work, and because the most useful thing I can do with it now is say precisely what is wrong with it.

01What it does

Four tabs, one question

Most health apps track your body. Journaling apps track your head. Balance was an attempt at holding both, on the theory that the relationship between them is the thing people are actually trying to understand about themselves.

Activity

Calories burned, step count, and heart-rate trends pulled from HealthKit into one view.

Food

Recipe and food search, so meal planning sits next to the activity it is meant to support.

Mood

Daily mood logged with custom emoji, building a visual record over time, plus a daily quote from the Quotable API.

Profile

02The build

What I actually learned

The goal

Learn Swift by shipping something real, not by following a tutorial.

Four tabs meant four different problems: HealthKit permissions and queries, a third-party food API, local persistence with SwiftData, and Firebase authentication. Each one forced a different part of the platform. A to-do app would have taught me none of it.

What it changed

I stopped writing specs an engineer has to interpret.

Working solo collapsed the gap between deciding something and living with it. Every ambiguity I would normally have handed off came straight back to me. That is the single biggest reason my handoffs are shorter now, and it is why I can prototype in the real stack instead of describing what the real stack should do.

03The critique

What I would change, and why

The interface is the weakest part of this project, and I know exactly why. I was optimizing for whether the code worked, and I let the design follow the architecture instead of the other way round. Four years of doing this professionally makes the problems easy to name.

Structure

Four tabs is a bag of features, not a product

Steps, recipes, mood, and profile sit side by side without ever meeting. The app is called Balance, and the one thing it never shows you is the balance. The redesign starts by connecting them: mood plotted against activity, sleep against how the day felt. That relationship is the product the name promises, and the current build has all the data to draw it.

Meaning

HealthKit gives you numbers, not understanding

A calorie count and a heart-rate trend are a mirror. They tell you what happened, which you mostly already knew. The design question I skipped is what a person is supposed to do with any of it, and that question should have determined the screen rather than being an afterthought on top of a chart.

Friction

The most valuable tab has the highest entry cost

Mood logging is the thing nobody else was capturing, and it sits third in a tab bar behind two screens of passive data. Anything asking for a daily habit has an interaction budget of a few seconds. It should have been the thing the app opened to, or a widget that never required opening the app at all.

Decoration

A daily quote that ignores the day

The Quotable integration serves a random quote regardless of what the user just logged. It is pleasant and it is inert. Responding to a logged state would cost almost nothing technically and would turn a decoration into a feature.

04Reflection

Why a flawed project is still worth showing

I could have quietly left this one off. I am including it because a portfolio of only polished work tells you nothing about how someone sees, and because the gap between what I built in 2023 and what I would build now is the clearest evidence I have of the distance covered.

Balance is also the reason I describe myself as a designer and a developer rather than a designer who can read code. Owning something from first sketch to shipped SwiftUI view is a different kind of understanding than reviewing a build someone else made.

Next project

Clarix→

Source on GitHub All work