Building an iOS App With Claude Code: SwiftUI, Xcode and Agents

Claude Code does not live inside Xcode, and that turns out to be an advantage: it works through the same command-line tools a CI server uses. The trick is setting up the project so the agent can compile, test and see failures on its own. This article walks through that setup, the SwiftUI patterns agents handle reliably and the places where you should keep a human hand on the wheel.

Set up a project the agent can verify

An agent that cannot run the build guesses. An agent that can run it iterates. Before the first feature prompt, put these pieces in place:

1. Create the project in Xcode yourself. Choose the bundle identifier, team, minimum iOS version and SwiftUI lifecycle deliberately. Generating the project file from scratch is one of the tasks agents do worst.
2. Add a scripted build. A small Makefile or shell script with targets such as build, test and lint that call xcodebuild with a fixed scheme and simulator destination. One command, predictable output.
3. Add a test target from day one. Unit tests for view models and services, plus a handful of UI tests for critical flows.
4. Write a CLAUDE.md. Architecture, folder layout, naming, which commands to run, and what not to touch.
5. Commit before every agent session. Small diffs are reviewable; a three-hour unsupervised session is not.

A CLAUDE.md that works for SwiftUI

Stack: Swift 6, SwiftUI, iOS 17+, Swift Package Manager only. Architecture: feature folders, one view model per screen using the Observation framework, services injected via protocols. Commands: make build, make test. A task is only done when both pass. Do not edit .pbxproj by hand unless asked; ask me to add files to targets if needed. Every new permission needs an Info.plist usage description and a note in the PR. Never add third-party SDKs without asking.

Adjust versions to your project; the point is to remove decisions the agent would otherwise make differently in each session. More on instruction files in AGENTS.md and CLAUDE.md explained and Claude Code best practices.

What agents do well in SwiftUI – and what they don't

A recurring problem is API drift: the model may reach for an older API when a newer one exists, or use a brand-new API that is unavailable on your minimum iOS version. The build loop catches the second case; the first is a code-review topic. Asking the agent to "use only APIs available on iOS 17 and prefer current Apple recommendations" helps.

A daily working loop

• Plan first. Ask for a plan for the feature, read it, correct it, then let the agent implement. Rejecting a bad plan costs seconds; rejecting a bad implementation costs an hour.
• One feature per session. Clear context between unrelated tasks so old assumptions do not leak in.
• Let tests fail loudly. Ask the agent to write the failing test before the fix for bugs.
• Use Xcode for what it is best at. SwiftUI previews, the view debugger, Instruments for memory and performance, and running on a physical device.
• Review diffs like a colleague's PR. Look for added dependencies, new permissions, force unwraps and silently swallowed errors.

Giving the agent eyes: screenshots and UI tests

Compiling code proves little about how a screen looks. Two techniques close that gap without leaving the terminal:

1. Screenshot loop. Boot a simulator with xcrun simctl, install the build, launch it and capture a screenshot with xcrun simctl io booted screenshot. Claude Code can read the image and compare it with your design description or a reference screenshot you provide.
2. UI tests as specifications. XCUITests that tap through onboarding, login and the core task turn "it should work like this" into something the agent can run and fix against.

Combine both for visual work: describe the target, let the agent build, screenshot, compare and iterate a few rounds, then do the final polish yourself in Xcode previews. It is slower than a human designer for pixel-perfect detail but very effective for layout bugs, missing states and dark-mode problems.

Pitfalls that show up only later

These do not break the build, so the agent will not notice them. Put them on your own checklist:

• Hard-coded secrets. API keys in Swift files end up in the binary. Use a backend proxy for anything sensitive.
• Missing privacy manifest entries. Required-reason APIs such as UserDefaults need declared reasons in PrivacyInfo.xcprivacy.
• Missing account deletion. If users can create accounts, App Review expects a way to delete them in the app.
• Web-like screens. If the app mostly displays content from your website, review guideline 4.2 before you invest further.
• No offline or error states. Generated screens often assume a perfect network.

From working app to approved app

Once the app runs on a device, the remaining work is release engineering: signing, TestFlight, privacy labels, screenshots and review. That process is covered step by step in from Claude Code to the App Store, and the certificate side in iOS code signing explained. If you would rather hand that part off, appsubmitter.io sets up CI/CD and submits signed builds in your own Apple developer account, including guidance through rejections. Teams that want to get better at the agent workflow itself can learn it hands-on in the agentic coding trainings at neooutput.