Building an iOS app in just a day

I built a full iOS app in one day.

The world doesn’t need another calorie tracking app - yet I decided to build one.

I was looking for something quite specific: a motivating diet coach that helps me stay in a calorie deficit without feeling like I am reporting to a spreadsheet. Something lightweight. Encouraging. Fast to use. Integrated into the Apple ecosystem. And ideally with a bit more personality than the usual “you have 327 kcal remaining” experience.

As I’m currently exploring different AI workflows across the whole process from idea to deployment, this became a good real-world test case.

The experiment

The result was an iOS calorie deficit tracker with a fox mascot named Carlo.

The scope was intentionally non-trivial:

SwiftUI app incl. widgets and watch app
AI-powered meal scanning
HealthKit integration
onboarding flows
localization in two languages
17 work packages, planned and executed

For context: I write code, but I had not implemented an iOS app hands-on for more than six years. Last time, UIKit was still my default mental model. So this was a useful test case: enough engineering experience to judge the output, but enough platform distance to feel where AI actually helps.

The biggest learning

The most valuable AI contribution was not code generation. It was requirements engineering.

Before writing a single line of code, I used Claude as a sparring partner. It interviewed me through: the problem, the user experience, the scope, the edge cases, the data model, the architecture, the sequencing of the work

That changed the project: Instead of jumping straight into SwiftUI, I stayed in thinking mode longer. The idea became clearer. The boundaries became sharper. The work became executable.

The acceleration of implementation makes one thing even more important than before: Being clear about what exactly to build.

The workflow: Claude and Codex

I split the work deliberately:

Claude for product framing, requirements, user interface design, architecture, and critique
Codex for implementation
ChatGPT for generation of the visuals

Claude helped me ask:

Are we solving the right problem?
What are the hidden assumptions?
What should be in scope today?
What should explicitly not be in scope?
Where could the architecture become fragile?

Codex helped me move through the implementation work packages quickly.

The human role

The human role did not disappear. It shifted.

I was still responsible for:

defining the product intent
deciding what good enough means, reviewing trade-offs
cutting scope
validating implementation choices
keeping the system coherent

AI-assisted development is not just faster coding. It changes the shape of the delivery process.

The first big productivity gain was not: “write code faster.” It was: “get from vague need to structured, sequenced, implementable work faster.”

The bigger takeaway

Using AI for coding speeds up development. But the real leverage comes from integrating AI into the whole development process:

requirements
critique
architectural sparring
scope control
turning ambiguity into executable work

I have been using the app for a week now — and I actually enjoy it.

Even more importantly, it was genuinely fun to develop software again. That is a feeling I had lost for a while.

With AI used deliberately, you can iterate extremely fast, focus on the important parts, and orchestrate more work than would otherwise be realistic in such a short time.

But AI is not magic. It does not remove the need for product thinking or engineering judgment.

It amplifies the people who bring those things into the workflow.

For me, that is the real lesson: The future of AI-assisted software development is not just about faster implementation. It is about redesigning the way we move from idea to working product.

Guiding people and teams through this change and shaping new processes and ways of collaboration is the important leadership task right now.