Running Xcode 27's Agent and Antigravity Side by Side: Designing the Work Boundary for iOS

With Xcode 27 bringing agentic coding into the IDE itself, iOS development now has two code-writing agents over one repository. Here is a practical design for keeping a single source of truth and splitting work across spec, implementation, and verification.

Antigravity²⁹¹ Xcode³ iOS Development² Agent Design⁵ Workflow⁸

✦ Premium Article

The Xcode 27 developer beta is out, and agentic coding now lives inside Xcode itself. The update pulls strong external models and agents directly into the development flow. It is a welcome change, but if you already run agents through Antigravity, the first problem is not the feature. It is the bookkeeping of a new situation: two agents that can both write code now sit over the same repository.

One of them works inside Xcode, tight against the build and the device debugger. The other works through Antigravity's CLI or IDE, taking on cross-file work and scheduled automation. Run both without drawing a boundary and the same file gets rewritten by two agents, and you lose track of which change is canonical. This article lays out how I design the work boundary when developing iOS across two agentic tools.

Why "who handles it" turns into an accident

With a single agent, the source of truth is never ambiguous. The agent's latest state is canonical. The moment there are two writers, the definition of canonical silently splits in two.

Three accidents are typical. The first is the double edit: Xcode's agent tidies ContentView.swift while Antigravity touches the same file in a refactor, and the save order erases one of the changes. The second is mismatched preconditions: Xcode treats a buildable state as "done" while Antigravity treats a green test suite as "done," producing a half-finished commit that satisfies only one bar. The third is split observability: who changed what scatters across two separate logs, and you can no longer trace the cause of a bug.

None of these is a question of which tool is smarter. They are the cost of not designing a boundary. The first thing to decide is not "who is more capable" but "what counts as the one source of truth, and who is allowed to write to it."

Pin the source of truth to the repository

The first thing I fix is a single principle: the only source of truth is the repository working tree. Both Xcode's agent and Antigravity edit files under the same Git control, and no tool's internal transient state is treated as canonical. It sounds obvious, but agents tend to accumulate context in tool-specific sessions and drafts because it is convenient. Make that canonical and you steadily grow information that the other tool cannot see.

On top of that, I place a shared contract that both agents read on startup, as an AGENTS.md at the repository root. Antigravity picks up this kind of file as context, and having Xcode's agent read it at the start of a session aligns the premises behind both tools' decisions.

# AGENTS.md — rules every agent in this repo follows
 
## source of truth
- Canonical state is this Git working tree only. No tool's draft state is canonical.
- Definition of done: scripts/verify.sh returns exit 0. "Build only" or "tests only" is not done.
 
## ownership boundary
- Preview-linked tweaks and on-device debugging fixes -> Xcode's agent
- Cross-file refactors, scheduled automation, CI wiring -> Antigravity
- Both touching the same file at once is forbidden. Split the branch first.
 
## commit rules
- One commit, one concern. Mark ownership in the subject: [xcode] / [agy]
- Do not push a commit that has not passed verification.

AGENTS.md is not decoration. The shared verification script described below, together with a written ownership boundary, is the spine that places two agents under one discipline.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦How to keep a single source of truth across Xcode's agent and Antigravity using an AGENTS.md and a shared operating contract

✦A concrete basis for splitting work into spec, implementation, and verification, and deciding which tool owns what

✦A shared verification gate that any agent's code must pass, plus the practice that prevents double-edit accidents

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Split work into spec, implementation, and verification

Before talking about ownership, splitting the work itself into three layers keeps decisions from wobbling.

The spec layer decides what to build. I do not hand this to an agent; a person writes it out as a short spec note. For each feature I keep a docs/spec/{feature}.md stating, in a few lines, the conditions to satisfy and the things never to do. Writing the negative spec — what must not happen — is the cheapest way to stop an agent from running off the rails.

The implementation layer writes code that satisfies the spec. This is where I split tools. The verification layer checks whether the written code meets the spec and the existing quality bar, and it runs through one single gate regardless of which tool wrote the code.

Layer	Primary owner	Artifact	Canonical check
Spec	Human	docs/spec/*.md (positive + negative spec)	Agreed in review
Implementation	Xcode agent / Antigravity, split at the boundary	Diff in the Git working tree	Sent to verification
Verification	Shared script	verify.sh result	exit 0 only

The benefit of separating layers is that it confines the tool debate to the implementation layer alone. Keep the spec and verification shared, and whichever tool handles implementation, the entrance and exit stay singular.

What I leave to Xcode's agent

Xcode's agent is strong on work tight against the build and the device. Tightening a layout while watching the preview, reading a build error's context and fixing it in place, jumping from a device crash log to the offending line — the closer the work sits to information Xcode already holds, the more value it produces.

I push the following toward Xcode: single-view SwiftUI adjustments, fixing broken Auto Layout or previews, localized fixes that accompany on-device debugging of a particular screen, and isolating build-setting or simulator-dependent problems. All of them complete within one screen or one feature, where build success bites back immediately.

Conversely, I avoid handing large cross-file refactors to Xcode's agent. An IDE agent tends to prioritize getting the local build green, and it is not necessarily designed to mind whole-repository consistency.

What I leave to Antigravity

Antigravity is strong on repository-wide work and on the steady operations that run outside the IDE. Unifying naming across many files, swapping out an API client layer, batch-tidying localization strings, and scheduled runs or CI wiring via the CLI all stabilize when pushed to this side.

Scheduled nightly work in particular suits the Antigravity CLI. Since the move to the Go-based CLI, startup speed and token efficiency reached a level you can feel in real operation. Officially it is described as roughly 3x faster than standard tooling with about 70% fewer tokens, and the gap tells most on automation you leave running unattended. As an indie developer running several apps and operations in parallel, those efficiency numbers map straight onto my sense of cost. I run a non-interactive check like the following as a pre-push hook.

#!/usr/bin/env bash
# scripts/agy-precheck.sh — cross-file check via Antigravity CLI before push
set -euo pipefail
 
# Pass the list of changed files and mechanically catch contract violations
CHANGED=$(git diff --cached --name-only --diff-filter=ACM | grep '\.swift$' || true)
[ -z "$CHANGED" ] && { echo "No Swift changes. Skipping."; exit 0; }
 
# Non-interactive, stdout mode (replace YOUR_AGY_PROFILE with your own profile name)
agy run --non-interactive --profile YOUR_AGY_PROFILE \
  --prompt "Check whether these files violate the negative spec in docs/spec, and output only the violations as a JSON array. Return [] if none: ${CHANGED}" \
  > /tmp/agy_precheck.json
 
# Stop the push if the result is anything other than an empty array
if [ "$(cat /tmp/agy_precheck.json | tr -d '[:space:]')" != "[]" ]; then
  echo "Negative-spec violations detected:"
  cat /tmp/agy_precheck.json
  exit 1
fi
echo "Cross-file check passed"

What matters here is that Antigravity is wired in as part of a mechanical gate, not as a clever conversation partner. Bind the output to JSON; stop on anything but an empty array. The more you shut decision wobble out of operations, the more reproducible the two-tool setup becomes.

Where the boundary breaks, and how to prevent it

The most frequent accident is both agents touching the same file at once. Splitting it physically by branch was the most reliable fix. Assign Xcode-side work and Antigravity-side work to separate branches, and merge only after a human review. Marking ownership with [xcode] / [agy] in the commit subject lets you trace where each diff came from later.

Next most frequent is the mismatched definition of done. This is absorbed by making the verify.sh above the sole completion condition. A "it works now" state fixed in Xcode and a "tests are green" state refactored in Antigravity are both treated as incomplete unless they pass the same script.

#!/usr/bin/env bash
# scripts/verify.sh — the one completion gate any agent's code must pass
set -euo pipefail
 
echo "1/3 build"
xcodebuild -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone 16' \
  build -quiet
 
echo "2/3 unit tests"
xcodebuild -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone 16' \
  test -quiet
 
echo "3/3 cross-file check (negative spec)"
git add -A
scripts/agy-precheck.sh
 
echo "verify passed: this commit meets the completion condition"

The third is split observability. To read who changed what in one place, on top of the commit-subject prefix I keep an agent-run summary in docs/agent-log/, appended per date. Per-tool session logs disappear, but the summary committed to the repository does not. When chasing a bug, the last thing you can rely on is the record you placed in the canonical source.

Start small and move the boundary later

Trying to draw a perfect boundary up front usually collapses on paper. I started from a minimal setup against a single feature: tighten the UI on the Xcode side, run the cross-file check on the Antigravity side. Over about two weeks, a feel builds up — "this kind of fix is faster on Xcode," "this automation is more stable on Antigravity" — and I fold it back into the ownership boundary in AGENTS.md.

I treat the boundary not as something fixed but as something you move while operating. Xcode 27's agent is still a moving beta, and Antigravity keeps shipping small updates. When the tools change, the optimal boundary changes too. Assume it will change, and keep only two things immovable: the discipline of one source of truth, and the single completion gate. With those as the spine, operations hold up even as tools multiply.

If you try one thing next, write a single verify.sh and run one feature at hand through that exit. Just deciding on one definition of done makes the two agents cooperate with surprising ease.

Thank you for reading. I hope this helps the design of anyone running multiple agentic tools side by side.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.