The workflow

  1. 01Start with one question
  2. 02Connect, then narrow the task
  3. 03Verify the proposed fix
  4. 04Keep the review reproducible

Start with one question

A broad “review my app” request can produce a long list without a clear next action. Start with the file or feature you changed. Ask your agent to distinguish a compiler error, a heuristic finding and a design suggestion.

iOS Agent Skill provides local references and file-located reviews. It does not replace the Swift compiler. A reported issue is something to investigate, and a clean result is not proof that the app is correct.

Connect, then narrow the task

For Claude Code, run this from your app folder:

claude mcp add ios-agent -- npx -y ios-agent-mcp@latest

Reconnect the client and confirm that the tools appear. For another client, use its setup guide. The local server requires Node.js 20 or later.

Review the Swift concurrency in the files I changed.
Search only relevant local references.
For each finding, show the file, line and reason.
Propose the smallest fix and explain how to test it.
Separate verified results from suggestions.

Verify the proposed fix

For example, when a finding concerns UI-observed state, inspect where that state is mutated and what actor isolation the type actually has. Do not add annotations across the project simply because a heuristic suggests them. Ask for the relevant source context, then build with your target SDK.

Review the diff before accepting it. Run tests for the affected behavior and record the command and outcome. If no suitable test exists, say that explicitly instead of treating compilation as a behavior test.

Keep the review reproducible

  • Keep one issue and its proposed patch together.
  • Record the package version and client used.
  • Use a synthetic example when reporting a false positive.
  • Never attach private app source or credentials to a public issue.

The useful result is an inspectable change with evidence. Token savings and a quality advantage over other workflows have not been established.

Inspect the review tools · Read the evidence and limits

Decision checkpoints

SituationAction or statusEvidence or boundary
Compiler diagnosticBuild with the same scheme and SDKA successful build
Heuristic findingInspect the surrounding isolation and ownershipA justified patch or documented false positive
Behavior concernReproduce the user actionA passing behavioral test