V-Droid swaps the LLM's job from generating a tap to scoring candidate taps and reaches 59.5% on AndroidWorld at 4.3 seconds a step; phoneshell's loop still asks one model to generate the tap

Two different jobs for the same model. Generate the next action from the screen, or score a short list of candidates someone else proposed. V-Droid rebuilt a mobile agent around the second job and reports gains on every benchmark it ran and a 6.1x speedup besides. phoneshell has never tried the swap on iOS.

V-Droid, accepted to MobiCom 2026 and posted on arXiv under the title "Advancing Mobile GUI Agents: A Verifier-Driven Approach to Practical Deployment" (arXiv:2503.15937, Gaole Dai, Shiqi Jiang, Ting Cao, Yuanchun Li, Yuqing Yang, Rui Tan, Mo Li and Lili Qiu, v1 20 March 2025, current v5 21 February 2026), changes which job the language model does. Almost every mobile GUI agent, phoneshell among them, hands a screen to a model and asks it to generate the next action directly: a tap coordinate, an element id, a typed string. V-Droid instead discretizes the screen into a set of candidate actions and asks the model to verify each one, scoring it rather than inventing it, with the highest-scoring candidate executed. The reported numbers: 59.5% on AndroidWorld (5.2 points above the agents it compares against), 38.3% on AndroidLab (2.1 points above), 49% on MobileAgentBench (9 points above), at 4.3 seconds per step, which the paper reports as 6.1 times faster than existing mobile agents. The arXiv abstract names none of those comparison agents, so both the point gains and the speed multiple are the authors' own framing, not independently checked here against a specific baseline.

What changed, and when

The mechanism behind V-Droid's numbers has three parts. A discretized action space turns "tap somewhere on this screen" into a short, enumerable list of candidates, which is what makes verifying them tractable at all. A prefilling-only workflow lets the verifier score every candidate in roughly the time a single forward pass takes, rather than generating token by token for each one, which is where the speed comes from rather than from a smaller model. And pairwise progress preference training teaches the verifier to prefer the candidate that moves a task forward, using a scalable human-agent joint annotation scheme to collect the training signal at scale rather than relying only on hand-labelled trajectories. None of the three parts is new in isolation, discretized action spaces and preference training both predate this paper, but combining them into a verifier that replaces the generator, rather than one that merely filters a generator's output after the fact, is the paper's actual claim.

phoneshell has never run this experiment, on either platform it could run it on. Its MCP server exposes 23 tools, observe, tap, type, swipe, 49 named gestures, picker-wheel and popup handling, app launch, and phone_do for chaining several steps, directly to whichever model an MCP client connects. The model reads an accessibility tree and a screenshot and calls a tool. Nothing in that loop proposes several candidates and scores them; the model generates one action and phoneshell executes it, gated only by the 14 label patterns that stop a tap on something that looks irreversible, which is a safety check on the output, not a quality check on the choice. V-Droid's swap, generation to verification, has not been tried against iOS's accessibility tree, which already differs from Android's in ways this site has covered before: cleaner on first-party apps, degraded on some third-party ones.

Two roles for the same model

What it means for someone building a phone agent's action loop

V-Droid's gains are real numbers against unnamed baselines, which means the honest claim available from the abstract alone is narrower than "verification beats generation." It is "this particular verifier, trained this particular way, beat whatever the authors compared it against, on Android." Whether the architecture generalizes to iOS, where phoneshell's own board already sits at a 89.7%-to-96.6% ceiling on first-party apps with nothing left to discriminate between models, is a separate question the paper does not address and phoneshell has not tested. A verifier only has something to score if the generator side still has meaningful room for error; on a benchmark already near ceiling, there may be little headroom for a verifier to recover, which would make V-Droid's approach look stronger on Android's harder average case than it would on phoneshell's current, saturated iOS task set.

The architectural lesson that does transfer, independent of the specific numbers, is that where a safety or quality check sits in the loop changes what it can catch. phoneshell's 14-pattern confirm gate runs after the model has already committed to one action, checking only whether that action's label looks dangerous; it has no visibility into whether a different, safer, equally task-advancing action was available and skipped. A verifier architecture would, by construction, see every candidate at once and could in principle reject an entire class of actions before any of them execute, not just flag a label pattern after the fact. That is a different failure mode than the ones already documented for phoneshell's confirm gate, and it suggests the next place to look is not just a better pattern list but a different point in the loop for a check to live.

• A reported 6.1x speedup over unnamed baselines is a comparison claim, not an absolute latency fact; phoneshell's own per-task timings (37.7 to 68.3 seconds across six models) are not directly comparable, since they measure a full multi-step task rather than a single step.
• The title mismatch between arXiv's submitted version and the MobiCom acceptance is a minor inconsistency, not a substantive one; it says nothing about the reported numbers, only that the venue's title and the preprint's title were never reconciled.
• Discretizing the action space is the precondition for everything else V-Droid does. A platform where "the next action" is genuinely open-ended, free-form text entry, an arbitrary gesture sequence, would need a different discretization scheme before a verifier architecture could even be defined for it.

Check it yourself

# V-Droid's abstract, reported numbers, and code
curl -s https://arxiv.org/abs/2503.15937
# https://github.com/V-Droid-Agent/V-Droid

git clone https://github.com/Blomega/phoneshell && cd phoneshell
bin/phoneshell mcp-config          # the 23 tools exposed, one generation call per step
grep -n "confirm\|CONFIRM_PATTERNS" phoneshell/*/config.py

What would prove this wrong

• We read V-Droid's point gains and speedup as specific to its Android baselines and not yet shown to generalize to iOS or to phoneshell's own task set. That is wrong if V-Droid's full paper, or a reproduction, reports results against a named, independently reproducible baseline on a benchmark phoneshell also runs; we would then be able to check the claimed deltas directly rather than taking them on the abstract's word. Untested as of this writing, through 31 December 2027.
• We predict that adding a verifier step to phoneshell's loop, scoring a small discretized set of candidate taps drawn from the accessibility tree's interactive elements before executing one, would produce a measurable drop in the handful of failure modes already catalogued in FINDINGS.md as "plausible wrong action taken with confidence" rather than in the modes caused by the stack silently lying about success, which a verifier cannot fix because it never sees them. This is falsifiable the day such a variant is built and run against the existing 58-task board.