How Shopify Uses Remote Dev to Let AI Agents Develop Mobile in Parallel

Give an AI Agent a "remote mobile dev machine": How Shopify uses Remote Dev to run parallel mobile work

Shopify built Remote Dev for the AI Agent "River" in Slack: a fleet of remote Mac machines + Android emulators mounted on Linux, letting the Agent compile in parallel, test iOS/Android, take screenshots and record screen, and even do Live Preview; among merged mobile PRs, the share produced by River rose from about 6% to about 61%. https://t.co/N8UNEjy1b6

Why build it: Web/backend work could already be done remotely by River; but once 3–4 Agent workflows were opened for mobile, the local machine was maxed out by compilers and emulators, and closing the lid cut it off entirely. River runs on Linux: it can edit Swift, but actually building/testing iOS still had to go back to that already-maxed-out Mac. The delegation capability exceeded local compute, so they built Remote Dev.

What it can do · Parallel: one River session exclusively owns a full environment—can simultaneously fix Android, build iOS features, and test PRs. · Background autonomy: edit code, compile, run tests, operate emulators, take screenshots, open PRs; on failure, read logs and fix again. It can also automatically pick up bugs at night → fix → test → submit PR. · Verifiable: not just "it compiles"; the Agent taps the UI in a real emulator and records before/after; recently it can even turn screen recordings into explainer videos with 3D phone frames, animations, and voiceover. · Anyone can participate: web engineers, designers, and PMs can work on mobile via Slack without setting up Xcode/Studio locally.

Live Preview: remote iOS Simulator / Android Emulator are pushed to Quick sites via WebSocket; the browser shows the live screen and sends operations back. Each session automatically has dual-platform preview, shareable for multiple people to watch together; supports deep links and mobile CLI streaming. No local install, no Mac needed.

How it was built (engineering highlights!) 1. Machine fleet: remote Macs with the dev environment and iOS simulators installed; the Agent connects via SSH. 2. Android: cloud Macs don't support nested virtualization → put the Android emulator on a Linux VM with nested virtualization enabled, then attach it to the same SSH session. 3. Warm pool: cold start (checking out the giant monorepo + first compile) once took over 30 minutes → switched to a warm pool: main already checked out, tools installed, app built, caches warm; after the Agent claims one, it syncs the branch and attaches the prebuilt Android VM. Time to "see the change on a device" dropped to a few minutes. 4. Rotation: sessions are destroyed and replaced when they end; idle machines periodically refresh main and rebuild; rotations are staggered to preserve availability. 5. Teaching the Agent: write skills + a CLI wrapping SSH; for long tasks use tmux so River can observe in real time instead of blindly waiting with sleep/timeouts. Early on the Agent would "forget the remote Mac" or go silent for long stretches; iterating on skills fixed it.

Organizational side: habits and adoption The problem wasn't just technical, but psychological: everyone was used to poking at the emulator locally; early River was "slow, wouldn't compile, not usable" → people fell back to local. They pushed adoption with role-based internal ads "River finally has a Mac" (mimicking Mac vs PC). Data: River's share of merged mobile PRs went from 6% → 61%.

Self-improvement loop River is visible to multiple people by default. A cheap classification model, Jev, observes mobile conversations, tags them, and categorizes by outcome quality; failed cases are fed to an LLM to find improvements; River itself is used to iterate on the experience.

Outlook Real-time health monitoring → the Agent automatically opens PRs fixing crashes; multi-Agent parallel bug bash (multiple merchants, devices, languages, flows).