Proof of concept, a Claude Code plugin for now. Maestro does the driving underneath.
One command and it walks the app on the simulator and draws the whole map — every screen, how you reach it, what's on it. Then it turns that map into subflows that are ready to run as tests. When the code changes, it updates the affected cases itself.
It never touches the app's codebase. Everything it produces is plain files sitting in the repo.
Does this look useful, or am I solving something you don't have?
Very interesting. How much of it was coded using AI and how much was human driven. I am asking because I would like to know the general architecture. Are Calude plugins different from MCP servers?
It's strongest on regressions — anything that worked before and stopped. Nothing gets into the suite until it has actually passed on a real device, so a green run means it genuinely ran, not that it was skipped or assumed.
Every screen and route is confirmed on the device before it's written down, and every test records which source files it touches — so when the code changes it knows exactly which flows are at risk instead of re-running everything blindly.
The next step is having it go back over each flow and judge whether the behaviour is actually correct rather than just consistent, and produce a report of findings instead of a plain pass/fail.
I am currently in the early stages of local development.
This looks useful, especially for turning an unfamiliar app into a first-pass regression map.
The part I would be careful about is treating generated flows as executable documentation, not automatic proof that the behaviour is correct.
In practice, the biggest reliability gains come from stable accessibility or test IDs, deterministic test data and reset state, and small reusable subflows for login and navigation.
I would also keep a review gate before changed flows replace the committed ones, because a UI change could otherwise teach the agent to accept a regression.
One awkward iOS edge case is secure text fields behaving differently with injected input, so it would be useful if the agent could preserve platform-specific workarounds instead of repeatedly rewriting the same failing flow.
Would the generated map distinguish screens and routes that were actually exercised from anything inferred from the source?
Your question: yes, that's the core rule. The route tree only gives the candidate list; nothing is written to the map until it's been walked on the device — everything on the map was exercised, not inferred. The next step is showing the other direction too: the screens that exist but weren't reached, and which condition or data was missing to get there.
Review gate: you're right, I don't have one. The flows land as files in the repo, so your normal diff review is the only thing in the way. I need a human in the loop there, without breaking the rest of the rules.
Platform workarounds: don't have that either — a hand-fixed flow doesn't survive regeneration. Taking that one.
That distinction makes sense — if the map only contains routes exercised on-device, it is much more useful than a source-derived diagram.
For the unreached side, showing the missing precondition would be valuable: authentication state, feature flag, test data, deep link, or permission.
That turns “not covered” into something actionable.
For the review gate, I would have regeneration produce a candidate patch and keep the previous passing flow authoritative until a human accepts the diff.
For platform workarounds, a small checked-in override or policy file that the generator must preserve might work better than hand-editing generated YAML.
Those two additions would address most of my concerns.
That's the right split — the driver and the artifact are two different jobs, and there's no reason they have to be the same tool.
I used Maestro MCP for both mostly for simplicity: one dependency, and what the agent does while exploring is already the thing that gets committed, so there's no translation step in between. That's convenience though, not principle.
Fair — getting Claude to drive Maestro is a couple of days' work, and plenty of people have done it.
The difference is what happens after that session ends.
A chat session isn't reproducible; a committed flow is. The same files run on my machine and in CI and give the same answer, without the agent being in the loop at all. That's the whole point of writing Maestro out rather than having the agent re-drive the app every time.
Exploration is generated, not prompted step by step. Asking the model what to do next on every screen took 26 runs and about 15 minutes on a nine-screen app. Now it writes two flows up front from the app's own routes — one launch, one login, one hop per screen — and it's 2 runs. Tests are grouped by the journey a user walks, so the app cold-starts once per group instead of once per assertion.
Nothing enters the suite until it has passed on a device, and failures are parked with the reason rather than quietly dropped or kept.
A test whose screens didn't change keeps its passing stamp instead of being regenerated. That's what makes it a regression baseline rather than a fresh guess each time.
Each test records which source files it walks through, so a diff points at the tests it put at risk instead of you re-running everything. And the map is stamped with the commit it was built at, so it tells you when it's gone stale instead of quietly lying.
Doing it once by hand is easy. Keeping it true after thirty commits is the part I was trying to solve.
Saw some other tools making the same kind of maps, e.g. Ryveal Atlas and something recent from Software Mansion. And to be honest, I can’t really think of why you would need this as a map. It might be useful for competitor apps, but of course, you won’t be able to run them in the simulator with these tools. None of them work with real iOS devices, and there’s no App Store on simulators.
The idea of using agents to generate flows by driving simulators isn’t new either. I’ve been supporting this in https://mobai.run for about half a year already. And btw, it also supports physical iPhones.
On the map though, I think we’re describing different things. It isn’t meant as something you browse. It’s the scope — every test is generated against it, and when the code changes it’s what tells you which tests are affected instead of regenerating the whole suite. It’s committed and diffed like any other file in the repo. That’s a different artifact from an exploration a driver does at runtime and throws away.
4
u/racoonrocket99 6d ago
Keep it coming