Claude Code Learning Hub
中文 Mingyu's Library

Hub / Tips / F · End-to-end scenarios

An iOS app from zero to App Store submission

One person, one Mac, one idea — walk the whole road from kickoff to App Store submission with Claude Code: how to split the phases, what Claude does in each, and how to close the verification loop in the simulator.

During development, the key is letting Claude verify its own work (the iOS Simulator pane lets it tap and look for itself); during release, the key is handing the Apple busywork to fastlane. The former is an official capability, the latter mature community practice.

One-line answer

Answer Split the project into six phases: interview to a spec → scaffold → feature iteration (simulator loop) → release prep (fastlane) → TestFlight → submission. During development, use the iOS Simulator pane in Claude Code Desktop so Claude can install the app, tap through it, and read the screen to check itself (an official capability, in public beta); for release, the community standard is fastlane to automate signing, screenshots, metadata, and uploads — and to make it the only channel that writes to App Store Connect (third-party practice). The phase breakdown itself is our arrangement.

Steps

  1. Interview to a spec: don't write code yet. OfficialBest practices suggest that for big features you first have Claude interview you with the AskUserQuestion tool — technical approach, UI/UX, edge cases, trade-offs — then write it all up as SPEC.md and start a clean new session to implement. Details in Interview your way to a spec. Expected output: a SPEC.md with explicit acceptance criteria.
  2. Scaffold: once the empty project exists in Xcode, run /init to generate CLAUDE.md and write in the build/test commands, target devices, and code style. Our takeFor iOS projects especially, spell out "how to build, how to run tests" — every later iteration depends on Claude using them to check itself.
  3. Feature iteration + simulator loop: develop in Claude Code Desktop (macOS); when you give Claude a task like "build the app and run it in the simulator to check the onboarding flow", the iOS Simulator pane opens automatically: Claude installs the app, taps through it, and reads the screen to verify the change, while you watch — or take over and tap yourself. OfficialRequirements: Claude Desktop v1.24012.0+, Xcode 26.x with the iOS platform installed (Xcode 27 not yet supported); in public beta, available on Pro/Max/Team but not Enterprise; local sessions only. Each simulator needs a one-time authorization on first use, and screenshots are sent to Anthropic — don't sign into real accounts on test devices. To pick a device, just say so, e.g. "run it on the iPhone SE simulator". After each feature lands, have Claude walk the flow in the simulator against SPEC.md and paste screenshot evidence (see the prompt below) — that's the self-verifiable definition of done loop; more detail in iOS simulator verification.
  4. Release prep (fastlane): Third-partyfastlane is the community-standard iOS release automation tool, turning archive, signing, screenshots, metadata upload, and submission into repeatable "lanes". There's a ready-made Claude Code skill (greenstevester/fastlane-skill); once installed, plain language like "Set up Fastlane for my iOS app" has Claude read your Xcode project and generate the config. Third-partyField experience (theyawns.com's BaseballScorer series): make fastlane the only channel that writes to App Store Connect, keep the App Store copy in the repo as the single source of truth, and never hand-edit in the web console — two sources of truth will inevitably fight.
  5. TestFlight: Third-partyThe same source's beta-lane practice: bump build → archive → upload to TestFlight → only tag in git after success (baking "don't burn a build number on a failed upload" into the control flow instead of relying on someone remembering). A note on device testing: OfficialClaude can only drive the simulator, not a physical iPhone/iPad — run it on the real device yourself and send screenshots of whatever you find back to Claude to fix.
  6. Submission: Our takeHave Claude draft the App Store description, privacy notes, and reviewer notes; keep them in the repo and submit via fastlane. Review materials are read by Apple's reviewers — read every word yourself before sending. If you get rejected, paste the rejection letter verbatim into Claude to analyze and fix.

Copy-paste prompt

During feature iteration, run this verification loop each time a feature lands (in a local Claude Code Desktop session):

Fully verify the changes we just made in the iOS simulator:
1. Build the app and launch it in the simulator; fix any compile errors before continuing.
2. Starting from a cold launch, walk the main flow — "new user opens the app for the first time → completes the core action" — taking a screenshot at each key screen.
3. Check every acceptance criterion in SPEC.md one by one, list anything that fails, fix it, and walk the flow again.
4. Once everything passes, paste the key screenshots and the commands you ran as evidence — don't just say "done".

When you reach the release phase, you can open with this (requires the fastlane skill installed, or let Claude learn it on the fly):

Set up fastlane for this iOS project:
1. Read the Xcode project and generate a Fastfile with a beta lane: check we're on the main branch with a clean working tree →
   bump build number → archive → upload to TestFlight → only commit, tag, and push after the upload succeeds.
2. Keep the App Store metadata (description, What's New, keywords) in the repo's docs/ directory as the single source of truth,
   synced by fastlane — never make me hand-edit the web console.
3. Do a dry run, and list the steps it would execute plus the credentials/permissions I need to supply manually.

Sources & last verified