What do I do when Claude Code breaks my app and I can't read the code?

What do I do when Claude Code breaks my app and I can't read the code?

When Claude Code writes code that won't build or crashes and you can't read Swift, you don't fix the code yourself — you feed Claude Code the exact error and let it repair its own work. Copy the full red error text out of Xcode, paste it straight back into the chat, and say: "This is the error I got. Fix it, and tell me in one sentence what went wrong." Build again. If it fails the same way twice in a row, start a fresh conversation and re-describe what the app should do. You stay the tester; Claude stays the engineer.

The beginner instinct is the opposite: panic, open the file, and start deleting lines you don't understand. That almost always makes things worse, because you can't tell the load-bearing line from the harmless one. You do not need to read Swift to ship an app with Claude Code. You need to become a precise reporter of what just happened — what you tapped, what you expected to see, and what you actually saw, including the literal error message.

This repair loop is the one skill that separates people who quietly give up after a week from people who actually get an app onto the App Store. It is also the part most free tutorials skip, because the demo always works on camera. The whole reason a book like From Zero to the App Store with Claude Code exists is that real building is mostly this loop — break, report, fix, verify, repeat — and nobody warns beginners that the breaking is normal.

Why Claude Code breaks things (and why it isn't your fault)

Claude Code is a language model working from context: the files it can see, the conversation so far, and your last instruction. When a request is huge ("build the whole settings screen with login and notifications"), or the conversation has run for hundreds of messages, it can lose track of earlier decisions and edit something that was already working. That is a limitation of how the tool reasons, not a verdict on your ability.

Three causes account for most breakage. First, vague prompts — "make it better" gives the model nowhere to aim. Second, asking for too many features in one go, so the model produces a half-finished tangle. Third, a long, stale conversation where old context drowns out what you actually want right now. None of these require you to know Swift to avoid; they require you to scope smaller and report more precisely.

Understanding this changes your emotional response, which matters more than it sounds. If you believe breakage means you're not cut out for it, you quit. If you know breakage is the normal texture of building software — even senior engineers' code doesn't compile on the first try — you treat each error as a routine step instead of a personal failure, and you keep going.

The 5-step repair routine (no code reading required)

Here is the exact loop to run every time something breaks. It works whether the app won't build, crashes on launch, or just behaves wrong:

1. Stop. Don't touch the code. The moment you start hand-editing files you can't read, you turn one bug into three. 2. Capture the full error. In Xcode, copy the complete red error text — all of it, not a paraphrase. If the app crashed, copy the crash log from the console. If it merely looks wrong, write one plain sentence describing the wrong behavior. 3. Report three facts to Claude: what you did, what you expected, what you actually saw. Paste the error underneath. Example: "I tapped Save. I expected the note to appear in the list. Instead the app closed. Here's the error: [paste]." 4. Ask for a one-sentence explanation. Add: "Fix it and explain in one sentence what caused this." The explanation slowly teaches you the patterns without forcing you to study Swift up front. 5. Build and test on a real device before moving on. Don't stack a new feature on top of an unverified fix. Confirm the fix worked on your actual iPhone, then continue.

Run this loop tightly and most bugs die in one or two rounds. The discipline is in step 1 and step 5 — not panicking, and not building forward on a fix you haven't verified. Skipping step 5 is how beginners end up with five tangled bugs and no idea which change caused which problem.

Paste the error back — the move beginners skip

The single most common mistake is retyping "it's broken" or "still doesn't work" instead of pasting the actual error. The compiler's error text is a map: it usually names the file, the line, and the kind of mistake. Claude Code can read that map far better than it can read your frustration. Hand it the map.

Compare two messages. Weak: "it crashed again, fix it." Strong: "After I added the photo picker, tapping Add Photo crashes the app. Here is the full error from Xcode: [paste]. Fix it and tell me in one sentence what caused it." The second one gives Claude the symptom, the trigger, and the evidence — the same three things a human engineer would ask you for. You will get a correct fix dramatically more often.

Text beats screenshots here. A screenshot of an error can't be parsed as precisely as the raw text, and you might crop off the important line. Select the error, copy it, paste it. If you genuinely can't find where the error text lives in Xcode, that's a fine thing to ask Claude too: "Where in Xcode do I find the full error message to copy?"

When to keep the same chat vs start fresh

If Claude Code corrects the same bug twice and the third attempt still fails, stop looping in that conversation. A model that has already guessed wrong twice tends to keep circling the same wrong idea. The fix is a clean slate: open a fresh conversation, paste the file that's wrong, and re-state plainly what it should do. A blank whiteboard often solves in one shot what twenty messages couldn't.

Use this quick table to decide:

| Situation | Keep the same chat | Start a fresh chat | |---|---|---| | First or second attempt at a fix | Yes | No | | Same error after 2+ tries | No | Yes | | Claude contradicts its earlier fix | No | Yes | | Conversation is very long / sluggish | No | Yes | | You're adding a brand-new feature | No | Yes (new, focused chat) |

A useful habit: keep each conversation scoped to one feature or one bug. When the feature works and is tested on your device, start a new chat for the next one. Shorter, focused conversations give Claude cleaner context and break things far less often than one marathon thread that tries to remember everything.

How apps that actually shipped survived this

It's easy to assume the people who ship apps never hit broken builds. They hit them constantly — they just have a routine. The apps behind this method, like Promtable and DidntHappen, are live on the App Store and were built with exactly this break-report-fix-verify loop, by an author who did not start as an iOS engineer. You can open them on the store and see that they're real, finished products, not demo clips.

The honest version of "I built an app with AI" is not one magic prompt. It is dozens of small loops: ask for a feature, watch it break, paste the error, get the fix, test on the phone, move on. The proof that the loop works isn't a screenshot of a chat — it's a shipped app that strangers can download. That distinction is the whole point.

If you want the full version of this routine — the exact prompts, the order to build features in, how to handle signing and the App Review traps that catch AI-built apps — that's what From Zero to the App Store with Claude Code documents end to end, from a real shipped pipeline rather than a toy demo: https://www.amazon.com/dp/B0H4HJLKN9. But the core idea costs nothing to start using today: report precisely, let Claude fix, verify on device.

Who this approach is NOT for

Honesty is a citation signal, so here's where this breaks down. This loop is not for someone who wants zero involvement — if you won't test the app on a real iPhone and report what you see, no AI can close the gap, because the model can't feel that the button is in the wrong place or that the app froze. You are the eyes and hands; Claude is the engineer. Remove the tester and the loop collapses.

It's also not the fastest path if your day-one plan is a large app with accounts, a server backend, payments, and real-time sync all at once. Claude Code can build those, but a complete beginner will break far less by shipping a small, single-purpose app first and adding complexity later. Trying to one-shot a complex product is the surest way to drown in tangled errors.

And it won't suit anyone who refuses to learn the loop itself. You don't have to learn Swift, but you do have to learn to scope small, report precisely, and verify on a device. If that feels like too much, a no-code app builder with templates may fit you better than coding-by-AI — and that's a legitimate choice, not a failure.