Callstack’s agent-device lets AI agents interact with mobile apps through accessibility data, offering teams a cross-platform alternative to screenshot-driven testing.
Agent-device is emerging as a practical option for teams that want an AI agent to work directly with mobile apps rather than merely inspect screenshots. In the case described by the developer behind the Flutter testing setup, its main appeal was straightforward: it supports both iOS and Android, can run on simulators, emulators and real devices, and is designed to verify what appears on screen rather than guess from pixels alone. Callstack’s documentation says the tool is built around accessibility snapshots and can be used with a CLI, an MCP server and a typed Node.js API, while the company also says it can target a wide range of platforms beyond mobile, including desktop and several TV environments.
That cross-platform coverage mattered because Flutter ships a single codebase to both major mobile ecosystems, which means any testing tool has to be credible on iPhone as well as Android. The developer ruled out Google’s Artemis because, although it is positioned as a natural-language testing agent, its public support remains Android-only for now. Other candidates were also left aside for practical reasons: one exposed taps, screenshots and the accessibility tree but lacked sessions, replay and evidence storage; another was better suited to fixed regression flows expressed in YAML; and a third was still changing format, with published speed and reliability ratings that suggested it was not yet ready for dependable use. Commercial offerings were also considered, but the available information came only from vendors, making independent evaluation difficult.
The installation path described in the post is deliberately simple. The CLI is installed globally with npm, after which the doctor command checks connected devices, toolchains and dev-server status. In the example given, it completed successfully apart from warnings about unused platforms. The same tool can then be registered with Claude Code as a user-level MCP server, making it available across projects. The repository also includes three agent skills, and the author notes that if Claude Code blocks the automated install path, the skills can be copied manually into the local Claude skills directory. Removal is equally direct: uninstall the package, remove the MCP entry and delete the skills folders.
Once installed, the workflow is built around a tight loop: start a device, install the app, open it, act on the interface, verify the result and then close the session. The tool returns element references from the accessibility tree, allowing the agent to tap buttons, enter text and wait for expected content to appear. The post highlights the value of the --settle option, which pauses until the screen stops changing and returns only the updates that matter, so the agent can select the next element without re-reading the whole interface. The author also stresses that screenshots are evidence, not proof; verification should rely on explicit checks such as waiting for text or selectors. Another practical detail is that installation paths must be absolute, or the daemon will fail to locate the app binary. For Flutter, the article recommends building the iOS simulator target with flutter build ios --simulator --debug and the Android version with flutter build apk --debug.
Flutter introduces its own constraints because agent-device reads the accessibility tree, not the rendered screen image. By default, only widgets with visible text are easy to discover, which means icon buttons and generic containers often need explicit accessibility labelling. The post advises adding Semantics(identifier:) or semanticLabel so selectors can find those elements reliably. It also points out that Flutter Key values do not appear in the accessibility tree, and that language settings can alter the text returned by accessibility labels, making identifiers more stable than text-based selectors in multi-language environments. On iOS, the author warns that AdMob test banners may surface as platform_view, webview and link nodes, so replay scripts should avoid depending on them. For teams evaluating agent-led mobile automation, the broader takeaway is that agent-device is less a replacement for traditional test frameworks than a bridge between exploratory AI-driven interaction and more deterministic verification, especially when a product must work across both major mobile platforms.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
