Why I Stick With Claude Code (and Why the Terminal Just Feels Right)

Over the past year, I’ve tried a bunch of different AI coding tools. Cursor, Copilot, even some wild side projects that promised to “revolutionize” my workflow.

But the one that actually stuck? Claude Code.

I write iOS apps in SwiftUI, so naturally I spend a lot of time in Xcode. That part isn’t going away. But I’ve realized more and more that my real development rhythm lives in the terminal. And that’s exactly where Claude fits best.

This post is less a technical review and more of a personal reflection on why Claude Code has become part of my daily dev life — and why I prefer this terminal-based approach over shiny GUI assistants like Cursor.

Living Between Xcode and the Shell

Building iOS apps is a funny split life. On one hand, you’re in Xcode:

SwiftUI previews
Interface tweaks
Debugging with breakpoints
Running simulators and devices

Xcode is essential. But the other half of my work doesn’t happen there at all.

I spin up projects with swift package init.
I run builds and tests with xcodebuild or swift test.
I manage dependencies with SPM.
Git is 100% command-line for me — I don’t touch Xcode’s source control panel.
Fastlane handles my TestFlight and App Store uploads.

That second half, the shell-based half, is where I feel most comfortable. It’s predictable, scriptable, fast. And it’s where Claude Code lives.

So when I first tried it, it didn’t feel like “another new tool.” It felt like an extension of my existing workflow.

Claude Code as a Teammate

When I describe Claude Code to other devs, I always use the same phrase: it feels like a teammate sitting in my terminal.

It doesn’t push me into a different environment. It doesn’t ask me to adapt to a new UI. It just sits there, waiting for me to throw work at it.

I’ll say things like:

“Split this SwiftUI view into smaller components.”
“Add unit tests for AuthService.”
“Refactor login flow to use async/await.”

And Claude just does it. It edits files, runs commands, shows me diffs, and waits for me to approve.

Cursor can look slick with its side panels and context menus. But to me, it’s like having a second IDE layered on top of Xcode. I don’t want that. I want an assistant who knows how to work in the same environment I do — and that’s the terminal.

The Permission System: Annoying at First, Then Essential

The first week with Claude, I was honestly a bit irritated with how often it asked for permission:

“Can I edit ContentView.swift?” “Can I run swift test?” “Can I create AuthService.swift?”

I thought: of course, that’s literally what I just asked you to do.

But after a while, I realized why it mattered. The permission prompts are like a seatbelt. They stop Claude from doing something destructive without me noticing.

On hobby projects, I’ll often disable them (claude --dangerously-skip-permissions) and let it fly. But on production apps or client work, I keep the prompts on. That balance of speed vs. safety feels right.

It’s funny — Cursor and GUI assistants rarely make this distinction. They just edit in the background. Sometimes that’s convenient. Sometimes it’s terrifying.

Where Claude Really Shines in SwiftUI Projects

The more I’ve used Claude, the more I’ve seen how well it handles SwiftUI’s quirks. Anyone who’s built a real-world SwiftUI app knows how messy things can get. Here are a few personal wins that sold me:

Breaking Down Monster Views

I had a ContentView.swift that had ballooned past 2,000 lines. (We’ve all been there.) It was unmanageable, previews were slow, and I dreaded touching it.

I asked Claude: “Break this into smaller views with previews for each.”

It:

Created separate files for each subview.
Wired up the bindings correctly.
Updated the previews so I could still check them independently.

That would have taken me an afternoon of grunt work. Claude did it in minutes.

Adopting New Patterns

At one point, I wanted to migrate an app to The Composable Architecture. Doing that manually is painful: moving state into reducers, reorganizing actions, adjusting views.

Claude handled a huge chunk of it. It created the boilerplate, refactored state, and even wrote some starter tests. I still had to massage things into shape, but it got me 80% there.

That’s where Claude excels: taking the pain out of big, repetitive changes.

Explaining Swift’s Mood Swings

Swift compiler errors are… something else. Sometimes they’re helpful. More often they’re walls of red that make no sense.

Now I just paste them into Claude. It explains in plain English what’s happening:

“This is failing because @ObservedObject is causing the view to recompute. Use @StateObject instead.”
“The closure here is non-escaping by default. Mark it @escaping to fix the mismatch.”

That’s worth its weight in gold. No more trawling through Stack Overflow for outdated answers.

Tests Without the Drudgery

I used to put off writing tests until the last possible moment. Now I just ask Claude: “Write XCTest cases for this API client.”

It spits out:

Happy path tests
Error cases
Async/await versions

I still review and tweak them, but the boring scaffolding is gone. Suddenly writing tests isn’t such a chore.

A Day With Claude

Here’s what an average feature build looks like for me now:

Kickoff
I describe the feature to Claude: “Add a tab bar with Home, Explore, and Settings screens.”
Scaffold
Claude generates the SwiftUI code, sets up the TabView, and stubs the screens.
Tweak
I flip into Xcode to adjust the layouts in previews.
Fix
Something breaks (it always does). I paste the error into Claude, get a clear explanation + fix.
Test
Claude writes XCTest cases, I run them in terminal with swift test.
Commit & Ship
Claude drafts the commit message. I push, run Fastlane, and ship a TestFlight build.

It feels smooth. I’m still steering the ship, but Claude is doing a lot of the rowing.

Why I’m Happy to Pay for Claude Max

$200/month isn’t cheap. But here’s how I think about it:

Claude saves me at least 5–10 hours a month.
It keeps me focused on interesting problems instead of repetitive ones.
It reduces the mental overhead of tackling messy refactors or debugging cryptic errors.

If you make a living writing apps, that return on investment is obvious. Even for indie projects, the time saved (and frustration avoided) makes it worthwhile.

Final Thoughts

Peter Steinberger wrote: “Claude Code is my computer.” That line stuck with me because it’s exactly how it feels.

Xcode is still the place where I design and debug my apps. But Claude Code has become the companion in my terminal — handling scaffolding, explaining errors, writing tests, automating releases, and generally making SwiftUI development less of a slog.

Cursor and other GUI tools are neat. They’re polished and beginner-friendly. But for me? The terminal is home. Claude fits into that world like it was always meant to be there.

And that’s why, for SwiftUI and iOS development, Claude isn’t just another tool in the box. It’s part of my daily rhythm — as natural as git commit or swift build.

# Why I Stick With Claude Code (and Why the Terminal Just Feels Right)