An editor-integrated agent still needs a reproducible build and a clear evidence boundary. Local MCP discovery in another terminal client does not establish integration inside Xcode.
- 1Editor capability
- 2Project access
- 3Tool discovery
- 4Real task check
Work through the example
Document the selected Xcode version and the actual in-editor setup surface. Verify one small operation before claiming support.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
3. The same verification contract applies
An agent in Xcode is still an agent. Everything in
docs/orchestration/verification.md holds:
- Never accept "done" without evidence. In Xcode the evidence is right there — the build result and the test navigator. Look at it.
- The author does not grade the work. If the agent wrote the code and the test, both encode the same misunderstanding. Read the test yourself and ask whether it would fail against the old behavior.
- A green build is not a passing feature. It compiles. That is one claim.
Agent says What you check
"Added tests, they pass." → Run them. Read them. Would they fail before?
"Fixed the layout issue." → Run it on the device size that broke.
"Localized to 8 languages." → Check pluralization and RTL, not just presence.
"Build succeeds." → True and insufficient.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Editor capability | Confirm the input and environment | Preserve the failure and return to this step |
| Project access | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Tool discovery | Run the focused check | Preserve the failure and return to this step |
| Real task check | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
Xcode 27 is not installed on the test Mac; this integration lab is blocked.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- Choose an AI client for your iOS workflow
Understand the difference between a skill, a local MCP connection and ChatGPT web setup.
- How should I review availability guards when moving a Swift app toward iOS 27?
A measured guard-review example that separates SDK availability, runtime readiness, and static-analysis limits.
What to do next
Next: Keeping up with Apple: refreshing references after each beta without breaking rules