Giving AI Agents a "Remote Mobile Dev Machine": How Shopify Runs Parallel Mobile Development with Remote Dev
Shopify built Remote Dev for River, its AI Agent in Slack: a fleet of remote Macs with Android emulators hosted on Linux, letting the Agent compile in parallel, test iOS/Android, take screenshots and recordings, and even run Live Previews. The share of merged mobile PRs produced by River rose from about 6% to about 61%.
https://shopify.engineering/remote-dev
Why build it
River could already do Web/backend work remotely. But once mobile ran 3–4 Agent workflows at a time, local machines were overwhelmed by compilers and emulators, and closing the laptop lid disconnected everything. River runs on Linux: it can edit Swift, but actually building and testing iOS still meant going back to that already-maxed-out Mac. Delegation had outgrown local compute, so they built Remote Dev.
What it can do
· Parallelism: each River session gets its own environment, so it can fix Android, build an iOS feature, and test a PR at the same time.
· Autonomous background work: change code, compile, run tests, operate the simulator, take screenshots, open PRs; on failure, read the logs and fix. It can also run overnight, picking up bugs → fixing → testing → opening PRs.
· Verifiable results: it's not just "it compiles"; the Agent taps through the UI in a real simulator and records before/after. Recently it can also turn recordings into explainer videos with 3D phone frames, animation, and narration.
· Anyone can participate: web engineers, designers, and PMs can drive mobile work through Slack without setting up Xcode/Studio locally.
Live Preview
The remote iOS Simulator / Android Emulator streams over WebSocket to a Quick site; the browser shows the live screen and sends interactions back. Each session automatically gets a dual-platform preview that can be shared for multiple people to watch together, and it supports deep links and live broadcasting via the mobile CLI. No local installation or Mac required.
How it's built (engineering essentials!)
1. Fleet: remote Macs have the development environment and iOS simulators installed; Agents connect via SSH.
2. Android: cloud Macs don't support nested virtualization, so the Android emulator runs on a Linux VM with nested virtualization enabled, attached to the same SSH session.
3. Warm pool: cold starts (checking out a huge monorepo plus the first build) once exceeded 30 minutes, so they moved to a warm pool: main is already checked out, tools installed, the app already built, caches hot. When an Agent claims a machine, it syncs the branch and attaches a prebuilt Android VM. Time to "see the change on a device" dropped to a few minutes.
4. Rotation: when a session ends, its machine is destroyed and replaced; idle machines periodically refresh main and rebuild; rotations are staggered to keep capacity available.
5. Teaching the Agent: they wrote a skill plus a CLI wrapping SSH; for long tasks they use tmux so River can watch in real time, rather than sleeping or waiting on timeouts. Early Agents would "forget the remote Mac" or go silent for long stretches, which was fixed by iterating on the skill.
Organizational side: habits and adoption
The problem wasn't only technical; it was also psychological. People were used to poking at simulators locally. Early on, River was "slow, failed to compile, hard to use," so people went back to local work. To drive adoption, they ran an internal ad campaign, "River finally has a Mac" (modeled on the Mac vs PC ads). The result: the share of merged mobile PRs produced by River rose from 6% to 61%.
A self-improvement loop
River is visible to many people by default. A cheap classification model, Jev, observes mobile conversations, tags them, and groups them by outcome; failure cases are then 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 to fix crashes; multiple Agents running parallel bug bashes (across merchants, devices, languages, and flows).