What Do I Actually Type to Get Claude Code to Build My iPhone App?

The short answer: you type plain English, one feature at a time

You do not type code into Claude Code. You type plain-English instructions that describe what you want, one screen and one feature at a time, then you run the result and tell Claude what to fix. The very first thing you type is roughly this: "Create a new SwiftUI iPhone app called Habit. It should have one screen that lets me add a habit, see my list of habits, and tap one to mark it done today. Set up the Xcode project and tell me exactly how to run it." That is a complete, useful first prompt — no Swift required.

From there the work is a conversation, not a coding session. Claude Code writes the Swift, sets up the project structure, and explains how to open it in Xcode and run it on the simulator. You look at what it built, then reply in the same plain language: "The add button is hard to see, make it the main blue button at the bottom," or "Marking a habit done isn't saving when I close the app — store it on the device so it persists." You are describing outcomes and judging results; the AI handles the syntax.

The skill you are actually learning is not typing — it is describing software clearly. Beginners who struggle usually are not bad at Swift; they are vague about what they want. Get specific about the screen, the data, and the behavior, and Claude Code becomes genuinely fast.

What do I actually type to get Claude Code to build my iPhone app?

A good first prompt answers four questions before Claude has to guess them: what platform, what the app is called, what the single first screen does, and where the data lives. Skip any of those and you get a generic scaffold you then have to argue with. Include them and you get something close to what you pictured. A strong template is: "Create a new SwiftUI app for iPhone called [Name]. The first screen should let the user [one concrete action] and see [one concrete result]. Keep all data on the device for now — no accounts, no server. Set up the Xcode project and give me step-by-step instructions to run it on the simulator."

Notice what that prompt deliberately does NOT ask for: accounts, payments, a backend, push notifications, or five screens at once. The single biggest beginner mistake is describing the whole dream app in the first message. Claude will attempt it, the project will be large and tangled, and when something breaks you will have no idea which part to point at. Build one working screen first, run it on your phone, and only then add the next feature in its own prompt.

Once the first screen runs, every following instruction is a small, testable change: "Add a second screen that shows the details of a tapped habit." "Add a weekly streak counter under each habit." "When the list is empty, show a friendly message and a big Add button instead of a blank screen." Each prompt is one outcome you can immediately verify by running the app. That rhythm — one clear request, one visible result — is the entire method.

The build loop: describe, run, verify, correct

Building an app with Claude Code is a loop you repeat dozens of times, and knowing the loop is more useful than any single prompt. Here is the full cycle, step by step:

1. Describe one feature in plain English — be concrete about the screen, the data, and the behavior you want.

2. Let Claude Code write the code and explain how to run it — it edits the project and tells you what changed.

3. Run the app and actually look at it — first in the Xcode simulator, then on your own iPhone over a cable, because the simulator hides real problems.

4. Compare what you see to what you asked for — does it look right, does it behave right, does it survive closing and reopening the app?

5. Correct in plain language — describe the gap precisely: "the date is showing in US format, I want day-month-year," not just "it's wrong."

6. Repeat for the next single feature — never batch five changes into one prompt while something is still broken.

The step beginners skip is number three: actually running and looking. It is tempting to keep typing requests and trust that it all works. Do not. Claude Code can produce code that compiles but does the wrong thing, and the only way to catch that is to run the app after every meaningful change. Verifying as you go is the difference between a build you understand and a pile of code you are afraid to touch.

Vague prompts vs. specific prompts (the same request, two outcomes)

The quality of what Claude Code builds tracks almost exactly with the specificity of what you type. The fix for "it didn't build what I wanted" is rarely a smarter model — it is a clearer instruction. Compare these pairs and the pattern is obvious.

Vague: "Make me a notes app." → Specific: "Create a SwiftUI iPhone app called Jot with one screen listing my notes newest-first, a button to add a note with a title and body, and swipe-to-delete. Save notes on the device so they survive a restart."

Vague: "Make it look better." → Specific: "Increase the spacing between list rows, use a larger bold font for note titles, and make the Add button a full-width blue button pinned to the bottom of the screen."

Vague: "It's broken." → Specific: "When I tap a note and go back, the list scrolls to the top and loses my place. Keep the scroll position where it was."

The specific version wins every time because it removes the guessing. A vague prompt forces Claude to invent the missing details, and its guesses are generic — which is exactly why so many AI-built apps feel like the same beige template. Your job in the conversation is to supply the details only you know: how it should look, how it should behave, and what counts as correct. Do that and the output stops feeling generic and starts feeling like your app.

A real example: the kind of prompts behind a shipped app

This is not a simulator demo. The book From Zero to the App Store with Claude Code is built around apps the author actually shipped to the App Store using exactly this describe-run-verify loop, including Promtable and DidntHappen, both of which you can verify live on the store. Those are not toy projects that died on a laptop; they are real, downloadable products built by prompting Claude Code and checking the result on a real device.

The prompts behind a focused app like that are unglamorous and small, and that is the point. They start with one screen — "a list of saved prompts I can search and copy" — get it working on the phone, then grow one verified step at a time: add a way to create an entry, add categories, fix how the empty state looks, make the copy button give feedback when tapped. No single prompt is clever. The discipline is in keeping each one small enough to test, and in running the app after every change rather than trusting that it works.

What a worked example like this teaches that a generic tutorial cannot is where the prompting actually ends. Getting the app working on your phone is maybe the first half. The book walks the rest in order — project setup, SwiftUI structure, building features by prompting and verifying, testing on a physical device, signing and provisioning, App Store Connect metadata, the review traps that specifically catch AI-built apps, and what to do after launch. You can find it on Amazon at https://www.amazon.com/dp/B0H4HJLKN9. The reason that full sequence matters is in the next section.

The part no prompt can skip: getting it onto the App Store

Here is the honest limit of "just type what you want." Claude Code can build the entire app by conversation, but it cannot ship it for you. The final stretch from a working build on your phone to a live App Store listing is paperwork and account work that no prompt completes: enrolling in the Apple Developer Program, signing and provisioning, writing accurate privacy labels, sizing screenshots, and passing App Review.

This is the half free tutorials quietly skip, and it is where complete beginners lose days. The build feels ninety percent done long before it is actually submittable, because the remaining ten percent is unfamiliar vocabulary rather than code. The first time you hit a "provisioning profile" error or a metadata rejection, it can stall you for a full evening simply because nobody warned you what it meant or what to type to fix it.

So the complete answer to "what do I type" has two parts. While building, you type small, specific, plain-English feature requests and verify each one. While shipping, you stop typing prompts and start following Apple's process — and that is precisely the gap a start-to-finish playbook closes, by mapping the gates before you hit them instead of after.

Who this prompt-first approach is NOT for

Be honest with yourself before you lean on this. The describe-run-verify method is not for someone who will not run the app and look at it. If you type requests, never test on a real device, and assume it all works, you will end up with a build that compiles, behaves wrong, and that you cannot fix because you never watched it being built. Verifying is not optional; it is the half of the loop that makes the other half safe.

It is also not a shortcut around clear thinking. Claude Code amplifies a clear idea and amplifies a vague one into a mess. If you cannot describe what the screen should show and how it should behave, no prompt phrasing rescues that — the fix is to get clear on the product first, even sketching it on paper, then describe it.

And it is not for a first project that needs accounts, payments, and a synced backend on day one. Those are real engineering problems with real failure modes, and starting there as a beginner usually ends in a tangle. Pick a self-contained first app whose data lives on the phone, ship it end to end, and add the heavy features later once you have done the full loop once. If that fits you, plain-English prompting plus honest verification is genuinely enough to get a real app onto the App Store.