← All articles
Story

243 Days: How a Non-Coder Shipped an iOS App

I had never written code and could not read an error message. 243 days, 466 commits and 43,000 lines later, the app shipped. Here is what actually made it hard.

5 min read
读中文版 →
Contents

243 days ago I did not know what Swift was. Today my app is on the App Store.

I am a complete outsider to this field. I never studied programming, I cannot read an error message, and I could not explain what “object-oriented” means. My only tool was describing what I wanted in plain language, and working alongside an AI.

This is not an article about how to write code. It is about how far one person can take a real product without knowing how to code — and what actually made it hard.

My entire method was “say it in plain words”

At the start I did not even know how to ask for what I wanted. For the first two weeks I kept making the same mistake: describing things in programmer vocabulary.

If I wanted swipe actions on a list, I would say “add swipeActions to this List with leading and trailing.” Back came a wall of code I had no idea how to fit into the project.

So I gave up on that and said this instead:

“This list of items — I want to swipe left and get a delete button, swipe right and get a pin button.”

It got it right immediately.

That shift sounds trivial. It was the single most important thing I learned in 243 days: you do not need to learn a programming language, but you do have to learn to describe precisely what you want.

The more specific the request, the more reliable the output. “Redesign the shopping list” is a complete module, if you say it clearly enough.

What 243 days actually looked like

StageWhat happened
First 10 daysThe entire skeleton stood up. Six core features working in a week.
Month 3The burst. 198 commits in one month — per-category fields, unified search, family sharing.
Month 5v1.0. A custom dataset to train YOLOv8 so recognition runs offline; the conversational assistant ships; subscriptions go live.
Months 7–8Two whole months. One commit.
Month 9Came back and pushed to v1.2.1 in a week.

The final numbers: 466 commits, 43,000 lines of code, 411 tests.

I still remember the shock of those first ten days, when it genuinely worked. But those ten days are not what decided whether this app survived.

The hard part was not features. It was crashes.

You can add features one at a time. You cannot do that with a crash.

The worst one was writing AI recognition results to the database: the moment recognition finished and the results were saved, the app crashed. Every time. I wrote “fix this completely” five times.

The first four attempts were guesses. Guess a cause, change it, run it, it crashes again. That grind is genuinely corrosive — you start to suspect you simply are not capable of this.

On the fifth attempt I did something different: I pasted the error message in verbatim, without changing a single character.

It found the problem almost immediately. That is when I understood that I had been substituting “what I think is happening” for “what is actually happening.”

After that I made it a fixed loop:

Crashes are the best teacher you will get. Every error message tells you precisely where your understanding of the logic is wrong. It leaves no room for vagueness.

Months 7 and 8: I disappeared

I hesitated about whether to include this part.

In those two months the project had exactly one commit. Not a technical wall, not a lack of time — I just did not want to open it. Months of continuous output had used up whatever was driving me, and seeing the icon produced a small physical resistance.

The anxiety was real: everyone else is shipping, and I am standing still. But I let myself stop anyway.

Coming back in month 9, something interesting had happened: those two months had not made me worse. They had made things clearer. Design problems that had been stuck for weeks resolved quickly. In one week I pushed to v1.2.1.

If you are in the middle of something long: a broken rhythm is not a failure. The finish line keeps moving forward regardless.

Four things I would pass on

1. Plain language is enough to start. You do not need the terminology first. “Redesign the shopping list” is the start of a module. Vocabulary speeds up collaboration; it is not the entry requirement.

2. Crashes are the best teacher. Every error is one free upgrade. Hand over the raw message instead of guessing ten times.

3. Commit small. Let it snowball. This is the only way someone like me can stay in control of 40,000 lines. Change one small piece, confirm nothing broke, repeat. Trying to build a whole feature correctly in one pass always ends badly.

4. Accept the real rhythm: bursts and rests. In 243 days I had one month with 198 commits and two months with one. That is normal. Demanding a steady pace from yourself is a good way to quit.

Why I built an inventory app

The app is called AllMyThings and it is for keeping track of what you own.

I did not pick the category. My own home was a mess: warranty cards I could not find, shampoo bought three times over, food in the fridge discovered only once it had expired. I wanted to solve my own problem first.

If you care more about how to actually do this than how the app got built, I wrote two more practical pieces: what I found after logging all 128 things in my home, and where a home inventory spreadsheet breaks down.

If someone like me can do it, you can at least try it.

Keep reading