The first time I wanted to build an app, I sat down, opened my MacBook, and thought: okay. Let's do this.
Then I opened Google.
Four hours later I had 47 tabs open. Three different programming languages downloaded. Two YouTube tutorials paused halfway through. And zero lines of code.
I wasn't lazy. I wasn't stupid. I just didn't have a map.
The Real Problem Isn't Information — It's Sequence
Here's the thing about googling "how to make an app" — you get answers meant for people who already know the shape of the thing.
Swift or Objective-C? Xcode or VS Code? UIKit or SwiftUI? Bootcamp or self-taught? Start with fundamentals or just build something?
Every single one of those is a real question with a real answer. But when you don't know what any of those words mean yet, the answer to each question just opens three more. You spend four hours clicking and reading and watching and at the end of it you feel less ready than when you started.
That's not a knowledge problem. That's a sequencing problem.
The information exists. There's more of it than you'll ever need. The problem is nobody tells you what order to learn it in.
What 10 Years and 20+ Apps Taught Me
I've been building iOS apps solo for 10 years. Twenty-something shipped. I've made every mistake you can make in this process and kept notes on most of them.
The thing I wish someone had told me on day one isn't a tip or a trick. It's this:
The tools matter less than the order you learn them in.
Most beginners try to learn everything at once. Or they pick the "best" tool before they understand what any of the tools do. That's like buying the best hiking boots before you know whether you're going to the mountains or the beach.
Figure out where you're going first. Then pick the tools.
The 4-Step Map
If I were starting over today and wanted to build iOS apps, here's the exact order I'd go:
Step 1: Get Somewhere to Write
Download Xcode. It's free. It's made by Apple. It lives on your Mac. This is where you'll spend most of your time for the next few years so you might as well meet it now. Don't try to understand it yet. Just install it and open it. That's the whole step.
Step 2: Learn One Language
Swift. Not Objective-C, not Python, not JavaScript. Swift. It's what Apple uses, it's what iOS apps are written in, and it's genuinely well-designed for beginners. The debate about which language to learn first is real and completely irrelevant to you right now.
Step 3: Learn to Save Your Work Properly
This is Git. It creates checkpoints in your code so that when you break something (you will, constantly, that's normal) you can go back. I skipped this when I started. Lost two weeks of work. Then did it again. Then I started using Git and I've never lost work since.
Set this up before you write anything you care about.
Step 4: Build Something Small and Ugly
Not impressive. Not portfolio-worthy. Just something that runs on your phone and does one thing. A timer. A list. A button that plays a sound. The goal isn't the app. The goal is going through the full process once so it stops feeling like a mystery.
That's the map. Four steps. Everything else builds on top of those four things.
What's Next
This is the first post in a series. Next up: Git — what it actually is, why it matters more than most beginners think, and how to get started with it in under 20 minutes even if you've never used a command line before.
If you know someone who's been saying "I want to build an app" for the past year and hasn't started yet — share this with them. This is exactly where they need to begin.
I'm DevKoan. 10 years of solo iOS development, 20+ shipped apps, and a collection of every mistake a junior developer can make. I write about the things I wish someone had told me earlier.
Follow me here or on Substack for weekly posts.
Top comments (2)
"The real problem isn't information — it's sequence" is one of the most useful reframes for anyone learning to code, and it applies well beyond iOS. The 47-tab problem is essentially an optimization failure: you're trying to build a map of the whole territory before taking a single step, which feels productive but creates paralysis.
The mental model that helped me most when learning: instead of asking "what do I need to know?" ask "what do I need to know to understand the next thing I'm going to build?" It keeps the learning tightly coupled to something concrete, which cuts through the infinite-information problem immediately.
After 20+ shipped apps, what would you say is the one skill that separates the people who keep building from the people who get stuck in tutorial loops? My guess is something about tolerance for shipping imperfect things, but I'm curious what you actually observed.
You nailed it! "what do I need to know to understand the next thing I'm going to build" is exactly the filter. That's the whole game.
To your question: tolerance for shipping imperfect things is close, but the thing I've actually observed is slightly different. It's the ability to finish. Not finish perfectly, just finish at all.
The tutorial loop isn't really about learning. It's about avoiding the uncomfortable phase where you have to make decisions without a guide. Tutorials feel safe because someone else already decided the architecture, the scope, the trade-offs. The moment you're on your own, every decision feels like it could be wrong, so you go open another tab.
The people who keep building have internalized one thing: a shipped 60% app teaches you more than a planned 100% app. Not because shipping is inherently virtuous, but because the feedback from real usage is a completely different kind of information than what you get from reading docs.
So if I had to name one skill: it's the willingness to make decisions with incomplete information and live with the consequences. Which, now that I write it out, is pretty close to your "tolerance for imperfection". but I'd frame it as tolerance for uncertainty more than imperfection.