AI for iOS development: what agents do well on Apple platforms

Most writing about AI coding agents assumes a web app. Run the tests, open a browser, done. iOS developers read those posts and hit a wall on day one: the agent can’t see the simulator, it edits the project file and breaks it, it confidently uses an API that was renamed last June, and it has no idea that the screen it just “fixed” now clips on a smaller iPhone.

I have been building iOS apps since 2020 and have nine of my own on the App Store, and I now build most new things with agents. My view is that Apple platforms went from awkward to workable for agents during 2026, but only if you give the agent the same feedback a person gets: a build, a running app and a picture of the screen.

What changed for AI in iOS development in 2026

Two things moved at once.

Apple brought agents into Xcode. Xcode 26.3, announced in February 2026, added Anthropic’s Claude Agent and OpenAI’s Codex inside the IDE. According to Apple, agents there can search documentation, explore the file structure, update project settings, run builds and iterate on fixes, and check their own work by capturing Xcode Previews. Xcode also exposes those capabilities through the Model Context Protocol, so other compatible agents can use them. At WWDC in June 2026 Apple announced Xcode 27, and MacRumors reported that the coding assistant now handles localisation, can work against simulated devices and can be extended with custom skills.

The terminal route also matured. Command-line agents like Claude Code and Codex can drive xcodebuild and simctl directly, and open-source MCP servers such as XcodeBuildMCP (now published by Sentry as MobileBuildMCP) give them tools to build, run and test on simulators, take screenshots and inspect the on-screen UI. Device tools exist too, but they need code signing set up first.

The result: an agent no longer has to code blind on Apple platforms. Whether it does depends on how you set it up.

What AI agents do well on Apple platforms

Agents are strongest where Swift code can be checked without looking at a screen.

• Model, persistence and networking code. Codable types, API clients, SwiftData or Core Data layers, error handling. Plenty of examples in training data and easy to unit test.
• Tests. Writing XCTest and Swift Testing cases for existing logic, and making them pass, is one of the best uses of an agent on any platform.
• SwiftUI screens from a precise spec. Given a clear description, existing design tokens and a screenshot to match, agents produce reasonable views quickly.
• Mechanical work across a codebase. Renames, migrations from older APIs, adding accessibility labels, extracting strings into String Catalogs.
• Build errors. Reading a failing build log and fixing the cause is a tight loop agents handle well, as long as the build is fast enough.

What still doesn’t work well

The weak spots are the parts of iOS work that depend on eyes, hands, accounts or very recent knowledge.

Judging the result visually. An agent can take a screenshot, but noticing that spacing feels off, that a sheet animates oddly, or that Dynamic Type at the largest size breaks a layout is still unreliable. It will often describe a screenshot as correct when it isn’t.

Gestures, animation and feel. Interaction details that a person notices in a second are hard to specify and harder for an agent to verify.

The project file. Edits to project.pbxproj by hand, or by an agent writing text into it, are a classic way to end up with a project Xcode refuses to open.

The newest APIs. Apple changes Swift and its frameworks every year. A model trained before the last WWDC will reach for old patterns, and strict concurrency errors in Swift 6 can send an agent into rounds of adding annotations until the warnings go away rather than fixing the design.

Signing, provisioning, entitlements and App Store Connect. These need accounts, certificates and judgement about review guidelines. I keep a person on all of it.

Hardware features. Camera, Bluetooth, push notifications, HealthKit and anything that only behaves properly on a real device can’t be checked in a simulator loop.

This is how I’d place common iOS tasks today. The placements are my judgement from practice, not a measurement.

Which iOS tasks to hand to an agent

Data as a table

Item	Needs a person's eyes, hands or accounts	How well agents do it today
Networking and models	Rarely	Well
Unit tests	Rarely	Well
String Catalogs	Rarely	Well
SwiftUI from a spec	Always	Well
Swift 6 concurrency	Rarely	Poorly
Animations	Always	Poorly
Signing and release	Always	Poorly

How to give an agent eyes: the build, simulator and screenshot loop

The single biggest improvement for iOS work is to stop letting the agent declare a screen done from the code alone. Make it build, run, look and get checked.

A feedback loop for an agent working on an iOS app

• Agent
• Automated check
• Person

Steps as text

Step	What happens
1. Agent edits Swift	Agent — one screen or feature
2. Build and test	Automated check — xcodebuild on a simulator
3. Run in simulator	Step — fixed device and locale
4. Screenshots	Automated check — plus UI hierarchy dump
5. Reviewer agent	Agent — compares with the spec
6. Person	Person — looks at the final shots
Loop	findings go back: back from step 5 to step 1

1. Pin the environment. One scheme, one simulator model and OS version, one locale. Write them in the project’s CLAUDE.md or AGENTS.md together with the exact build and test commands, so every run uses the same ones.
2. Make the build the first gate. A Stop hook in Claude Code, or a script around codex exec, runs the build and the tests and refuses to finish while they fail. The pattern is in Claude Code hooks: turning an assistant into a pipeline.
3. Capture evidence, not opinions. Screenshots of each changed screen on the pinned simulator, plus a dump of the accessibility hierarchy, saved where the reviewer can read them. The hierarchy catches missing labels and hidden buttons that a picture doesn’t show.
4. Review against a written spec. A second model compares the screenshots and the diff with the acceptance criteria, ideally including a reference image. Criteria like “the primary button is visible without scrolling on the smallest supported iPhone” can be checked; “looks nice” can’t. More on writing those in acceptance criteria an agent can’t talk its way around.
5. Keep a person on the last look. Scrolling through the final screenshots takes a minute and catches what both agents missed.

Setting up an iOS repository for agents

A few changes to the project make every agent run smoother.

• Keep the build fast. Agents rebuild many times per task. Split code into Swift packages so tests for one module don’t need the whole app.
• Avoid hand edits to the project file. Prefer folder-synchronised groups in recent Xcode versions, or generate the project from a spec file, and tell the agent in the instructions file never to edit project.pbxproj directly.
• Give the agent current documentation. Point it at Apple’s docs search in Xcode or provide notes on APIs that changed this year, so it doesn’t write code for last year’s SDK.
• Make previews and test data deterministic. Fixed dates, fixed sample data and no network in previews give screenshots that can be compared run to run.
• Clean up after agents. Repeated builds and simulator runs fill a disk with DerivedData, caches and old simulators surprisingly fast. I built SimCleaner partly for this.

Bad and good approaches

Bad: letting the agent say “the UI is updated” without a build or a screenshot. That is a claim, and on iOS claims are wrong often enough to matter. See evidence over claims.

Bad: asking for a whole app in one prompt. You get something that compiles once and can’t be maintained. One screen or one feature per run, each with its own checks, works far better.

Bad: giving agents your signing certificates and App Store Connect access so they can “ship it”. The upside is a few saved minutes; the downside is a release you didn’t review.

Good: agents on logic, tests, localisation and spec-driven screens, with a build gate and a screenshot loop, and a second model reviewing.

Good: people on visual quality, interaction feel, privacy decisions and release.

I think the split will keep moving toward the agents. Xcode now gives them previews and simulators, and screenshot review keeps getting better. I expect a solo iOS developer with a well-set-up pipeline to maintain several apps at the pace a small team used to, with the human time spent on product decisions and the final look. If you want help setting that up for your own apps, write to me.

Questions

Can AI build an iOS app?

AI agents can write most of the code for a simple iOS app, including models, networking, tests and SwiftUI screens. A person is still needed for visual quality, signing, App Store submission and features that need a real device.

Which AI is best for iOS development?

Xcode 26.3 and later include Claude Agent and Codex, and both also work from the terminal with xcodebuild and simulator tools. The setup matters more than the model: an agent that builds, runs the simulator and gets reviewed beats a stronger one coding blind.

Can Claude Code work with Xcode projects?

Yes. Claude Code can run xcodebuild and simulator commands from the terminal, use MCP servers for building, testing and screenshots, and since Xcode 26.3 Claude Agent also runs inside Xcode itself.

Can AI agents test iOS apps in the simulator?

Yes. With simulator tools or an MCP server, an agent can build, install and launch the app, take screenshots, read the UI hierarchy and run XCTest suites. Judging whether the result looks right is still the weak part.