See CLAUDE.md for architecture, implemented commands, and design decisions.
The current CLI is stateless: each invocation shells out directly, and idb_companion is lazy-started and left running. The daemon is the next major milestone.
Daemon responsibilities:
- Detect running simulators (via
simctl) - Spawn and manage one
idb_companion --udid <udid>process per running simulator - Maintain gRPC connections to each companion
- Route CLI commands to the correct companion
- Clean up companions when simulators shut down
- Own the event timeline (simulator boots/shutdowns, app launches, periodic state snapshots)
CLI commands are already structured as thin RPCs to the daemon, so the surface won't change — only the backend wiring.
Record a timeline of simulator-related events:
- Simulator boot / shutdown
- App launches
- Periodic state snapshots / screenshots
Use-cases (TBD on push vs. pull architecture):
- Remote-control the simulator
- Stream the simulator screen
- Expose events and control via MCP tools for LLM agents (e.g., record video for one-shot PRs)