Manzanas Leases iOS Simulators to Agents

manzanas is BariBariGood’s open-source Mac daemon for sharing iOS simulators between coding agents and humans. It deals with a very plain mobile problem: many agents can write code in parallel, but the simulator on your Mac is still a scarce, stateful thing. The useful takeaway is that AI coding gets more believable when agents can reserve test devices, run repeatable specs, and leave evidence behind. For people asking about ai coding solutions roi for large teams, this is the interesting part: not more code generation, but fewer collisions around the expensive feedback loop.

A simulator lease is a short-lived claim on one simulator, so an agent can test without another agent changing the same device underneath it.

Look at the boring bottleneck first

manzanas is small, early, and very pointed. As of September 1, 2026, the GitHub repository showed 17 stars, an Apache-2.0 license, and a mainly Go codebase. Its README describes manzanasd as the daemon that owns the simulator registry, lease table, warm pool, action backends, streamers, golden images, and run journal.

That list matters because iOS simulator work is not just “run the app.” A useful test might need a booted simulator, a clean state, a logged-in fixture, an installed build, screen streaming, and a record of what happened. If seven agents all poke the same simulator, the test result is not evidence. It is noise with screenshots.

The project’s neat move is to put state ownership in one Mac-side daemon and keep clients thin. The README says clients include a CLI, an MCP facade, and SDKs, speaking a versioned JSON protocol over HTTP and WebSocket. That is the right shape for agentic coding because the agent should not learn every local simulator quirk; it should ask for a lease, run a spec, and return a journal.

The trap is to treat this as a generic “AI testing platform.” It is narrower and more useful than that. It is a coordinator for iOS simulator capacity, aimed at AI agents and humans who would otherwise trip over each other on the same Mac.

Why developers cared about this Show HN

The Hacker News appeal is easy to understand if you have ever watched an agent confidently finish a mobile change without opening the app. AI pair programming feels fast until the validation step is manual, flaky, or serialized through one developer’s laptop.

manzanas attacks that last-mile problem. The README’s “90% story” is effectively: lease a simulator, run a YAML spec, get evidence. Fleets, physical phones, and mirroring are described as optional chapters, not the starting point.

That restraint is good engineering taste. A dozen iOS simulators on one Mac sounds like a stunt, but leases are the real feature. Without leases, parallel agents compete. With leases, each run can be isolated enough to review.

There is also an honest objection. Local simulator orchestration is still local infrastructure. Macs sleep, Xcode changes behavior, simulators corrupt, and mobile UI tests can be slow even when perfectly scheduled. manzanas does not remove those facts; it gives agents a cleaner contract around them.

Treat the run journal as the product

The most important object in manzanas is not the simulator. It is the run journal.

A run journal turns an agent’s claim into something a reviewer can inspect. “I tested it” is weak. “I leased iPhone 15 Pro / iOS 18, started from golden image X, ran spec Y, captured steps Z, and exported the run” is much better.

For Claude Code, Anthropic’s coding agent, this suggests a practical boundary. Let Claude write or modify the app code, then require a simulator evidence step before the change is considered ready. That step can be a slash command, a hook, or a repo convention. Keep it boring.

A small repo note could look like this:

# Mobile validation rule

For iOS UI changes, do not mark the task complete until a simulator run exists.
Include the simulator model, iOS version, YAML spec name, and run journal path in the final message.
If manzanas is unavailable, say so and fall back to the manual test checklist.

That is enough repository memory. Do not turn the agent into your mobile test architect. Give it the local rule, the expected receipt, and the fallback.

The trap is to review the chat instead of the artifact. Chat logs are useful for debugging intent. Run journals are useful for deciding whether the app behaved.

Try it when simulator contention is real

manzanas is worth a look when you already have mobile work being split across agents, branches, or developers, and simulator contention is slowing the feedback loop. It is especially interesting for AI coding for teams that have one or more Mac hosts available and want agents to produce test evidence without each agent owning a whole machine.

It is probably overkill for a solo developer who runs one simulator and one agent at a time. The overhead only pays back when shared simulator state is causing missed bugs, duplicate setup work, or review uncertainty.

If you are using Claude Workshop patterns, keep this in the practical lane of the related training topic: define the boundary where an agent may touch a simulator, define what evidence must come back, and keep human review on the resulting app behavior. A related pattern shows up in Supafork Shares Agent Sessions, but manzanas is more concrete: it is about scarce iOS runtime capacity, not just sharing the agent session.

For ai coding solutions roi for large teams, the measurable question is simple: does shared simulator leasing reduce idle reviewer time and failed handoffs enough to justify running Mac hosts? Do not measure only lines of code. Measure how often an agent can produce a trustworthy mobile test receipt before a human opens the PR.

Fit and not-fit table

Use this table before you spend a Friday wiring agents to simulators.

A safe first experiment is tiny: one Mac, two simulators, one app flow, one agent command, one exported journal. If that does not make review easier, a bigger fleet will not save it.

For a Claude Code command, keep the request narrow:

/ios-check
Run the smallest available manzanas simulator spec for the changed iOS flow.
Return only:
- lease id
- simulator name and runtime
- spec name
- run journal path
- pass/fail summary
Do not modify app code during this command.

That last line is the hook boundary in plain English. Validation commands should validate. Mixing “fix while testing” into the same command makes the receipt harder to trust.

Common questions

• Does Manzanas improve ai coding solutions roi for large teams?

  It can, but only when simulator access is a real bottleneck. The likely return comes from fewer agent collisions, warmer test environments, and reviewable run journals. If your mobile review process is already fast and evidence-rich, manzanas may be interesting infrastructure rather than a high-ROI change.

• Can Claude Code use manzanas directly?

  Claude Code can fit this pattern through a narrow command, hook, or MCP tool boundary. The manzanas README mentions an MCP facade, which is the natural integration shape. Keep permissions scoped to leasing, running approved specs, and reading exported journals before you allow broader host actions.

• Is manzanas a replacement for CI?

  No, it is better understood as local simulator fleet orchestration for agent and developer workflows. CI still owns the final shared gate. manzanas is most useful before that gate, when agents need fast iOS feedback and reviewers need evidence that a mobile flow actually ran.

• Do I need a dozen simulators to learn from it?

  No, the idea is useful with two simulators. The dozen-simulator version makes the contention visible, but the core mechanism is the lease. Start with one Mac host, a warm pool, and a single repeatable spec before thinking about fleets.

• What is the biggest risk with AI coding and shared simulators?

  The biggest risk is giving agents broad Mac control and then trusting weak evidence. Shared simulators multiply both productivity and confusion. Use explicit leases, approved specs, and exported journals so each agent run has a clear boundary and a reviewable result.

Best ways to use this research

• Best for: mobile engineers already using coding agents on iOS work, especially where simulator state causes flaky handoffs.
• Best first artifact: a single /ios-check command that leases a simulator, runs one approved spec, and returns a journal path.
• Best comparison angle: compare “agent finished with no app run” against “agent finished with a leased simulator run and exported evidence.”
• Best limit to keep: do not let the simulator command also rewrite code. Separate fixing from validation.

Further reading

• manzanas — source
• Claude Code — overview
• Claude — Agent
• OWASP — Top 10 for Large Language Model Applications

Try the smallest useful version

If manzanas looks relevant, do not start with a fleet. Start with one repeatable iOS flow, one leased simulator, and one run journal that makes a reviewer’s job easier.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.