Apple did not ship a model this time. It shipped a training pipeline: an 8B planning model thrown into 512 concurrent virtual iOS devices for online reinforcement learning, and the resulting scorecard reads 32.4% on UINavBench, a benchmark built from real iOS apps, tying Gemini-3.1-Pro.

The paper's own evaluation is laid out in Table 1 (see arXiv:2610.39264): with PPO trained to step 336 (two epochs), success rates are 32.4% on UINavBench, 2.3% on iOSWorld, and 32.8% on AndroidWorld, while the SFT baseline for the same architecture scores 16.7%, 4.5%, and 4.7%. The numbers are hard, but the same table also carries a piece of bad news the authors wrote down themselves.

The training environment: real devices turned into rollback-able sandboxes

The real bottleneck in online RL has never been the algorithm. It is the environment: it has to run concurrently and it has to roll back. The paper's answer is to run iOS devices inside cloud-hosted virtual machines. Each device gets its apps installed, is signed in with an Apple ID, and is captured as a snapshot. An episode ends by rolling back to that snapshot rather than tearing the session down, which brings restart latency down to roughly 10 seconds. Devices are driven over a VNC session through a typed action interface (tap, swipe, type, long press, home, wait) that mirrors physical-device behavior. During training the system runs 512 trajectories simultaneously, each with its own independent device and agent-environment loop.

That concurrency figure is the precondition for everything that follows. Without it, online sampling cannot keep PPO fed.

Splitting planning from grounding

The most direct architectural move is decoupling. The planning agent decides what to do; a separate grounding model translates that intent into x,y coordinates on the screen. The planning agent starts from Qwen3-VL-8B-Instruct and is first supervised-fine-tuned on human-annotated trajectories drawn from three sources: two in-house iOS datasets, one covering first-party apps and one covering third-party apps, plus the public GUIOdyssey dataset. GUIOdyssey consists of Android apps, and the paper includes it specifically for its multi-app trajectories, filling the missing app-switching behavior in the in-house iOS data. None of the three datasets natively record reasoning, so the chain-of-thought and remaining-plan targets are generated with Gemini.

On the grounding side, the team uses an internal 3B dense model finetuned on a large human-annotated dataset, reaching over 90% accuracy on its held-out test set. Because that model supports only directional swipes such as "swipe up" rather than precise location-based swiping, all swipe instructions are routed to Gemini-3.5-Flash. There are seven action primitives in total: Tap, Swipe, Text_Entry, Navigate_Home, Long_Press, Ask_User, and Task_Complete.

Two judges, and one guard against reward hacking

All rewards come from LLM judges, split across two levels. The paper calls this an LLM-as-a-Judge setup, and the two levels divide the work clearly. The dense judge is Gemini-3.5-Flash, invoked at every step: it looks at the before and after screenshots and returns success, fail, or overcomplete. To earn success, the before and after screenshots must show real progress toward the overall task, and the agent's reasoning and action must both match the visual state of the UI, so accidental progress from hallucinated reasoning counts as a failure. Unproductive loops get penalized by checking for repeated failed actions, and overcomplete penalizes the agent for continuing to act after the task is already satisfied. The terminal judge is Gemini-3.1-Pro, examining the final three screenshots plus the full action history and returning success, fail, or blocked_complete. That third label exists to protect cases with an unavoidable external barrier such as a paywall or a CAPTCHA, so the agent is not penalized for a state it could not act on.

The reward function carries one deliberate guard. Dense rewards are discounted with gamma = 1/2 while the terminal reward is not discounted at all. The reason is that step-level rewards create an incentive to artificially prolong trajectories in order to farm them; the undiscounted terminal reward keeps the actual objective, real task completion, from being diluted.

GiGPPO: feeding visually similar screens to the critic

The technical contribution here is called GiGPPO. It starts from the idea behind GRPO and GiGPO, comparing multiple rollouts of the same task against each other to estimate value. But GiGPO depends on states recurring exactly, which almost never happens in a UI setting. With only 4 or 8 rollouts per task, grouping by exact state equality degenerates into singletons, and relaxing the condition to "visually similar" would push that bias straight into the critic.

GiGPPO routes around averaging. Each state is paired with the screen whose 64-bit perceptual hash is closest in Hamming distance among the sibling trajectories of the same task, and a small multilayer perceptron then predicts the value directly from the hidden embeddings of the state and its neighbor, the neighbor's return (its discounted dense sum plus the undiscounted terminal reward), and the Hamming distance between the two screens. The payoff is faster convergence: on UINavBench, GiGPPO at step 75 and step 168 already performs comparably to standard PPO at step 168 and step 336.

The scorecard: where it wins, where it loses

Start with the wins. UINavBench covers 36 real iOS apps and 116 tasks, and it is the benchmark closest to the training environment of the three. At step 336, PPO reaches 32.4%, tying Gemini-3.1-Pro's 32.4%, ahead of Gemini-3.5-Flash at 28.4% and Qwen3.8-27B at 19.6%, and nearly double the 16.7% of the SFT baseline. AndroidWorld is the out-of-distribution generalization test, with 116 tasks across 20 real apps, and there PPO at step 336 reaches 32.8%, close to seven times the SFT baseline's 4.7%. The paper argues this shows the framework teaches generalizable navigation strategies rather than merely memorizing iOS-specific trajectories.

Now the losses. iOSWorld has 133 tasks over 26 synthetic apps, 46 of them specifically testing personalization preferences. On this benchmark PPO at step 336 scores just 2.3%, below its own SFT baseline of 4.5%, so more training on real apps made the agent worse on synthetic ones. The paper offers a concrete failure shape: when the agent searches for a synthetic app by name and hits a name collision with a real iOS app, it tries to install it from the App Store, or assumes the synthetic app is a web service and searches for it in Safari, because the training set included Safari search tasks. The learned prior is being steered in the wrong direction.

A second gap comes from swapping the grounding model. In an appendix experiment using the SFT-trained planning agent, UINavBench gives 12.7% with the pure 3B grounder, 14.7% with Gemini-3.5-Flash, and 16.7% with the 3B model handling most actions and Gemini taking over swipes alone. On iOSWorld, that hybrid configuration scores only 1.5%, worse than the pure 3B model's 3.0%. The "agent" being discussed is really three things stacked together, and the score shifts when any one of them does.

What I think

Three points.

First, the headline "ties Gemini-3.1-Pro" holds, but only on the benchmark of real apps, and the price is a collapse on the synthetic-app benchmark. This is not an implementation defect. The training distribution directly sets the generalization boundary: real iOS data taught it what iOS looks like, and synthetic apps do not look like that.

Second, in this scoring setup, the opponent is also serving as a judge. The dense judge is Gemini-3.5-Flash, the terminal judge is Gemini-3.1-Pro, swipe grounding goes to Gemini-3.5-Flash, and the simulated user answering Ask_User steps is Gemini-3.5-Flash. So "an 8B model ties Gemini-3.1-Pro" is not methodologically wrong, since the comparison happens inside the same decode-and-execute framework, but it is the authors' own evaluation, there is no third-party reproduction, and the scoring loop leans heavily on closed models.

Third, what is probably transferable is not the 32.4% but the recipe: decoupling planning from grounding, a dense-plus-terminal two-level reward with asymmetric discounting, a device farm that buys concurrency through snapshot rollback, and a GiGPPO that substitutes perceptual-hash neighbors for exactly recurring states. A parallel open-source line comes from the ClawGUI framework, whose ClawGUI-2B reaches 17.1% on MobileWorld GUI-Only (arXiv:2604.11784); this paper describes it in its related-work section as an end-to-end single policy plus GiGPO on Android emulators, and lists three points of difference. Both tracks are pushing the same thing: getting GUI agents to learn, from real interaction, how to get back up after making a mistake.