iOS apps with a coding agent

A coding agent can test your app’s sign-up the way a person would: build it, run it in the iOS Simulator, fill the form with a Proxy Mail QA test address, then enter the code or open the link from the email. Proxy Mail QA gives the agent the address and the email’s code or link; the agent’s own tools drive the simulator.

Every setup below starts with Proxy Mail QA connected to the agent: paste the one-prompt setup, or connect the MCP server by hand.

To try it before pointing an agent at your own app, use the iOS sample: a small sign-up with email activation and no server. You send its activation email yourself, from your own email account, and the agent gets the code from Proxy Mail QA.

Claude Code Desktop’s iOS Simulator pane

Claude Code Desktop on a Mac can run your app in a simulator next to the conversation, tap through it and read the screen (Anthropic’s guide). It needs Xcode with the iOS platform installed, and you allow Claude to use each simulator once.

Open your iOS project in a Claude Code Desktop session with Proxy Mail QA connected, and ask:

Build the app and run it in the simulator. Sign up with a new Proxy Mail QA test address, using the password it gives you, then enter the verification code from the email and check the app shows the account as verified.

Claude then:

1. Builds and launches the app in the simulator.
2. Calls create_address, with password: true, for a fresh address and password.
3. Taps into the sign-up form and types them in.
4. Calls wait_for_code (or wait_for_link) for the code or link from the email.
5. Types the code, or opens the link on the simulator so the app handles it. Opening a link follows your session’s permission mode.

For a link that should open the app, ask for that link: “open the verify link from the email in the app”. If the email has both a web link and an app link (myapp://…), the web link comes first; wait_for_link with app: true (or the REST API’s app=true) asks for the app one. iOS asks “Open in your app?” before an app link opens it, and Claude taps Open.

The simulator’s screen can show a step a moment late, so Claude checks a screenshot shows what it typed before tapping the button, and takes another before deciding a step failed.

The simulator pane’s screenshots are sent to Anthropic like the rest of the conversation, so only use test accounts on that simulator. Proxy Mail QA addresses and passwords are test accounts by design.

Claude Code or Codex with Xcode’s tools

Xcode can share its build and project tools with an agent you run outside it, through Xcode’s own MCP server (Apple’s guide):

1. In Xcode, choose Xcode → Settings → Intelligence, and under Model Context Protocol turn on Allow external agents to use Xcode tools.

2. Add Xcode’s tools to the agent:

   claude mcp add --transport stdio xcode -- xcrun mcpbridge

   For Codex:

   codex mcp add xcode -- xcrun mcpbridge

3. Open your project in Xcode, then prompt the agent as above.

With both servers connected, the agent builds through Xcode and gets the test address and email through Proxy Mail QA.

Xcode’s own agents

Xcode’s built-in agents (Claude Agent, Codex and Gemini) can take extra MCP servers from their configuration folders under ~/Library/Developer/Xcode/CodingAssistant/ (ClaudeAgentConfig, codex and gemini), and can install agent plug-ins from Intelligence settings → Plug-ins → Add Plug-in (Apple’s guide).

Our plugin for Claude Code bundles the MCP server and a skill that describes the sign-up flow; adding it from its URL there should give Xcode’s Claude Agent the same tools. We haven’t tested Xcode’s plug-in support yet, so if it doesn’t work, use Claude Code or Codex alongside Xcode instead.

What else to ask for

Whichever way the agent is connected, it can cover more of the flow:

• A code split into boxes. Many apps show one box per digit. The agent taps the first box and types the whole code, which most apps spread across the boxes, then checks every digit landed before going on: a partial code counts as a wrong attempt.
• A longer sign-up form. For a form that also asks for a username with rules, a date of birth or a country, form_values gives a value for each field from a new address made for it.
• The email itself. After the code or link arrives, check_email with expect_host set to the domain your app’s links open (its Universal Link domain, say) checks the link goes there, along with SPF, DKIM, DMARC and a stated expiry. count_emails catches a second email sent by mistake.
• A dev server on your Mac. The simulator reaches your Mac at localhost, so a dev build’s links to localhost:3000 are expected. Ask the agent to mark it as a dev environment (mark_dev_host), or add it in Project settings, and check_email passes those links instead of failing them.
• The same account next time. Ask the agent to record where the account is used (environment, such as staging, and tags such as ios) when it creates it, so list_addresses finds it again. With an API key allowed to read saved passwords, get_sign_in returns the account and its password in one call.
• A report. Ask for a run report: the agent calls start_run first and finish_run at the end, which returns the report in Markdown.

Writing it as a test instead

To keep the check as a UI test that runs in CI, see iOS (XCUITest), or Maestro for a flow that also covers Android. Their helpers do the same in a test: check and count the emails, sign in as a saved account or borrow one, and add each test to the pull request’s report.