“I genuinely thought nobody else was building this. I was wrong.”
The Problem I Thought Only I Cared About
When I built OpenMob, the core frustration was simple and specific: Claude Code, Cursor, Codex — all of them could write Flutter code fast, but none of them could see the device. They couldn’t tell if a button actually responded to a tap, if a layout was broken on a real screen, or if a login flow genuinely succeeded. They were coding blind. And “it compiles” has never once meant “it works.”
So I built the bridge. OpenMob gives AI coding agents real eyes and hands on physical Android and iOS devices through MCP — 25 tools, no quota, no cloud dependency, completely self-hosted. It started as a QA tool at my last company and evolved into something I use every single day for AI-assisted Flutter development. I wrote about it, published it, and thought: well, this is a niche enough problem that the mobile developer community will take a while to catch on.
Then Google shipped ARTEMIS.
9,000+ GitHub stars. 873 forks. 99%+ completion rate on Google Research’s AndroidWorld benchmark. Native MCP server. Works with Claude Code, Cursor, Codex, Windsurf, Antigravity — literally almost every agent platform I care about. Two execution profiles. A full web console. A Python SDK. And an iOS roadmap.
I’m not going to pretend I don’t have feelings about this. I do. But more than anything, I’m genuinely impressed — and I’ve been deep in the README for two hours figuring out exactly how it compares to what I built, where each one is actually better, and whether I’m eventually replacing OpenMob with this.
Spoiler: yes, for most things. But the comparison is more interesting than that.
What ARTEMIS Actually Is — Not Just the Headline
ARTEMIS (I don’t think the acronym stands for anything, it’s just styled that way) is a Python-based Android automation framework from Google that turns natural-language instructions into reliable device interactions. The tagline is “let AI assistants and test suites use real phones like a human” — which is basically the same sentence I used to describe OpenMob’s core value proposition.
But the implementation goes considerably deeper than a simple MCP tool adapter.
The two execution modes tell you a lot about the architecture:
Flash profile is a fast reactive loop — one model, one screen observation, one action, repeat. About 3–5 seconds per step. No planning layer, no task graph, just a tight observe-act-observe cycle. History is compressed into visual summaries as the session grows rather than being capped, so it can run for a long time without hitting context limits. Best for routine, deterministic UI tasks where you know exactly what you want and just need something to execute it reliably.
Pro profile is a full multi-agent planning system — a Planner maintains a living Markdown task plan with milestones and verification checkpoints, an Operator executes against it with the full toolset (ADB diagnostics, video analysis, history recall, exploratory grounding), and a Checker verifies plan checkpoints and runs a final review against the original goal. Every single action passes a pre-execution safety net that checks the live UI tree before firing. Takes 15–40 seconds per step but handles 100+ step long-horizon workflows. You’d use this for complex multi-app automation, stability testing, or anything that needs a written report at the end.
The AndroidWorld benchmark result — 99%+ task completion across 100+ multi-step tasks spanning 20+ apps — is genuinely significant. Most Android automation tools fall apart on anything that requires more than a handful of steps because they lose context, fail to recover from unexpected UI states, or hit walls with custom Flutter/Canvas interfaces. ARTEMIS handles all three specifically: it uses element indices when accessible, falls back to coordinate-based targeting, and uses visual models for custom interfaces that standard accessibility APIs can’t read.
The web console is something I never built in OpenMob and honestly underestimated the value of: live screen projection, real-time agent reasoning stream, action trajectory visualisation, execution replay. You can watch what the agent is seeing and deciding, step by step. For debugging automation failures, that visibility is enormous.
How OpenMob and ARTEMIS Actually Compare — Point by Point
Let me be genuinely specific about this rather than vague.
Platform coverage: OpenMob covers Android through 25 MCP tools, with iOS tools present in the toolkit. ARTEMIS is Android-only right now — iOS is explicitly on the roadmap but not shipped yet.
Execution intelligence: ARTEMIS wins clearly. OpenMob exposes tools that an AI agent calls — screenshot the screen, tap this element, read the UI tree — but the intelligence for deciding what to do and how to recover from failures lives entirely in the calling agent. ARTEMIS has built-in execution intelligence: the Flash and Pro profiles have their own reasoning loops, their own recovery mechanisms, their own context management. When an action fails, ARTEMIS handles recovery itself. When OpenMob’s agent fails, the recovery is entirely up to Claude Code or whatever agent is calling the tools.
Benchmark validation: ARTEMIS has it, OpenMob doesn’t. 99%+ on AndroidWorld is a peer-reviewed, independently documented result. OpenMob has no equivalent. This is a real difference — it’s the difference between “it works in my experience” and “here’s measurable evidence of reliability.”
Setup and hosting: OpenMob is genuinely self-contained — one binary, no Python environment, no dependencies to manage. ARTEMIS requires Python 3.12+, ADB, scrcpy, FFmpeg, and runs as a server with a web console. The one-click start.sh installs everything automatically, but it's a meaningfully heavier setup. For someone who wants a lightweight MCP bridge they can drop into their existing workflow, OpenMob's surface area is smaller.
iOS support: ARTEMIS is Android-only right now with iOS explicitly on their roadmap. OpenMob has iOS tooling in the toolkit, though it’s not as mature as the Android side. Neither is a perfect solution for iOS device integration today — ARTEMIS doesn’t have it, and OpenMob’s iOS support has real rough edges worth knowing about before relying on it in production workflows.
Transparency and observability: ARTEMIS’s web console is a serious advantage. Real-time screen projection, reasoning telemetry, action trajectories, execution replay — you can actually see what the automation is doing and why. OpenMob’s tool output is text-based. For debugging complex automation sequences, the gap is significant.
Tool count vs. execution depth: OpenMob exposes 25 MCP tools covering a wide surface — screenshot, tap, swipe, install APK, read logcat, manage permissions, toggle network, record video, run test scripts. ARTEMIS exposes five core MCP tools (mobile_run_task, mobile_manage_task, mobile_get_device_state, mobile_inspect_trace, mobile_diagnose) but each one is backed by a full execution engine. OpenMob gives the agent fine-grained control over individual device operations. ARTEMIS gives the agent high-level task dispatch with built-in reliability. They're operating at different abstraction levels, not just different feature counts.
Multimodal targeting: ARTEMIS explicitly handles Flutter’s custom interface challenge — it uses element indices when available but falls back to coordinate-based and visual targeting for custom Canvas, Compose, and Flutter interfaces that standard accessibility APIs can’t see into. OpenMob reads the accessibility UI tree, which works for standard Android views but hits the same limitations any accessibility-based tool does on Flutter’s custom rendering. ARTEMIS’s visual fallback is a genuine architectural advantage for the exact framework I build in most.
Agent platform support: Both work with Claude Code. ARTEMIS explicitly supports Antigravity, Codex, Windsurf, Cursor, Cline/Roo, OpenClaw, and VS Code. OpenMob is built around the MCP standard, so it works with anything that speaks MCP. Functionally equivalent here, but ARTEMIS provides first-party configuration snippets and one-click installation for each platform.
I’m Replacing OpenMob With ARTEMIS For Android Work
I want to be direct about this rather than dancing around it.
For Android development specifically — which is the majority of where I need device integration day-to-day — ARTEMIS is the better tool. The built-in execution intelligence, the AndroidWorld benchmark validation, the web console for debugging, the visual targeting that actually handles Flutter’s rendering properly, the Python SDK for integrating into test pipelines — all of it is substantially ahead of what I built.
I built OpenMob to fill a gap. ARTEMIS fills that gap better, with more resources and engineering behind it than any solo developer maintaining an open source tool can realistically match. That’s not a criticism of OpenMob — it was the right tool to build at the time, and it solved the problem it was built to solve. But when a better solution exists, switching is the right call.
The iOS situation is more nuanced. ARTEMIS doesn’t support iOS yet, and OpenMob’s iOS tooling exists but isn’t as reliable as I’d want it to be for serious work. Honestly, neither tool fully solves iOS device integration today — so I’m watching ARTEMIS’s roadmap closely and hoping they get there before I need it more than I currently do.
But Something Interesting Is Happening Here
“Two tools, both trying to give AI agents eyes on a phone. Different abstractions, different strengths, possibly more interesting together than either is alone.”
OpenMob and ARTEMIS are solving the same problem from different angles. OpenMob is a fine-grained MCP tool layer — 25 individual operations an agent can compose freely. ARTEMIS is a task-oriented execution engine — high-level natural language dispatch backed by built-in intelligence.
The interesting thought experiment: what if those layers could work together? ARTEMIS’s execution intelligence driving OpenMob’s fine-grained iOS operations. OpenMob’s lightweight footprint handling the cases where ARTEMIS’s full server stack is more than you need. ARTEMIS’s Flash profile for rapid iteration, OpenMob’s specific tools for custom operations the ARTEMIS abstraction doesn’t directly expose.
I don’t know yet if that’s a contribution to ARTEMIS, an extension to OpenMob, or something else. ARTEMIS’s codebase is Apache 2.0 licensed, their CONTRIBUTING.md is active, and iOS support is explicitly on their public roadmap. The gap between “this is an interesting idea” and “I’m opening a PR” is mostly time and experimentation.
But I’m thinking about it. And the fact that I’m thinking about contributing to a Google project with a tool I originally built because I thought nobody else was working on this problem is a genuinely strange feeling to sit with.
What This Actually Means for Flutter Developers
If you’re a Flutter developer using AI coding agents and you haven’t set up any device integration yet — start with ARTEMIS on Android. The setup is more involved than OpenMob but the one-click script handles most of it, and what you get is substantially more capable than any alternative.
If you need iOS device integration today, honestly neither tool is fully there yet — ARTEMIS doesn’t support it, and OpenMob’s iOS tooling has rough edges. Keep watching ARTEMIS’s roadmap; iOS is explicitly listed as their next major platform.
If you’re thinking about the broader picture — giving AI agents real device verification as a standard part of a Flutter development workflow rather than an optional extra — ARTEMIS’s existence and 9k stars in a short time suggests the problem is being taken seriously at a level that changes what the default expectation should be. “Does this actually work on a real device” should not be a question that requires a human to answer manually every time.
I built something, someone larger built something better, and the net outcome is that the thing I cared about getting into the world — AI agents that can actually see and test mobile apps rather than guessing — is now significantly more accessible to developers who didn’t want to set up a custom tool. That’s a good outcome, even if it came with a twinge of “I thought nobody else was working on this.”
They were working on it. With rather more resources than me.
My original OpenMob article: I Built a Free, Open-Source Alternative to MobAI So My AI Agents Can Finally See My Phone
ARTEMIS: github.com/google/artemis
Tags: Flutter, Mobile Development, AI Coding Agents, Android, OpenMob, ARTEMIS, Google, MCP, Claude Code
I Built OpenMob So AI Agents Could See My Phone. Then Google Shipped ARTEMIS. 👁️📱 was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.