How Shopify Gave AI Agents a Mobile Dev Environment

10 min read

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The engineering post

• We gave AI agents a mobile dev environment, Shopify Engineering, Oct 22 2026

Think about how a good hotel works. Nobody starts building a room when you walk up to the front desk. The room is already made. Bed done, towels out, lights on. You get a key, you use the room, you check out. Housekeeping resets it for the next guest. Rooms that sat empty too long get freshened up anyway.

That is close to exactly what Shopify built for its AI agents. They call it Remote Dev. The rooms are Macs. The guests are agents. Housekeeping is a set of scripts that keeps machines ready before anyone asks for one.

On October 22, 2026, three Shopify engineers, Michael Garfinkle, Mauricio de Meirelles and David Cortes, wrote up how it works. I'm going to walk you through the idea, how it runs step by step, and when it's worth copying.

Key takeaways

• Just 3 or 4 parallel agent workflows were enough to max out a developer laptop.
• Shopify's agent, River, ran on Linux. It could edit Swift but couldn't build or test the iOS app.
• Remote Dev keeps a pool of warm Macs, each with an Android emulator attached from a separate Linux VM.
• Time from requesting a Mac to seeing changes on a running device went from over 30 minutes to a few minutes.
• River's share of merged mobile pull requests went from 6% to 61%.
• Every session gets a Live Preview link for iOS and Android, so anyone can use the running app in a browser.

What problem does a remote dev environment for AI agents solve?

Shopify built agent workflows to work on mobile tasks in parallel. They hit the wall fast.

Three or four workflows maxed out a laptop. Compilers, simulators and emulators were all fighting over the same machine. And the laptop had to stay awake. If someone closed the lid by accident, the work stopped.

Their web and backend teams already had a way out. River, Shopify's AI agent in Slack, let them work without tying up their own machines. But River ran on Linux. It could edit Swift code, but building and testing the iOS app meant going back to the same laptops that were already maxed out.

So the team had two constraints, and neither had a good answer:

1. Too many builds sharing one Mac.
2. No iOS tooling on Linux.

Their own line sums it up: "Our ability to delegate work had outgrown our ability to run it."

Agents can write code faster than your hardware can prove it works. That's the whole problem.

How does the hotel comparison map onto Remote Dev?

Here is the comparison laid out piece by piece.

Hotel	Remote Dev
A room made up before you arrive	A Mac with main checked out, tools installed, apps built, caches warm
Getting a key at the front desk	An agent claims a ready Mac
A connecting room next door	A prebuilt Android VM attached to that Mac
Housekeeping after checkout	The Mac is destroyed and a replacement is prepared
Freshening rooms nobody used	Idle Macs are replaced with fresh main and rebuilt apps
Not cleaning every room at once	Rotation is staggered so the pool stays available

Where the comparison breaks is useful too. A hotel guest knows they're in a hotel. River didn't. Even with the machines running, it kept saying an iOS build can't run on Linux. Building the rooms was half the job. Teaching the guest to use them was the other half.

How does Remote Dev work, step by step?

Step 1: A fleet of remote Macs

Shopify set up a fleet of remote Macs with their development environment and iOS simulators. Agents connect to them over SSH.

Step 2: Getting Android onto a Mac

This was the tricky part. Android's emulator uses hardware virtualization. Running it inside a cloud VM needs nested virtualization, and macOS doesn't support that out of the box.

Their fix: run the Android emulator on a separate Linux VM that has nested virtualization turned on, and connect to it from the Mac. An agent can then build for both iOS and Android on the Mac and test on either platform, all inside the same SSH session.

Step 3: Keep the pool warm

The first version was slow. The initial app compile and checking out main took over 30 minutes. Shopify's monorepo is massive, so main alone is a big checkout.

So they stopped preparing a Mac after a request arrived. Instead they keep a pool of Macs ready in advance, with main checked out, tools installed, apps built and caches warm.

Step 4: Claim, sync, attach

When an agent needs a machine, it:

1. Claims a ready Mac.
2. Syncs its branch.
3. Spins up a prebuilt Android VM instance and attaches it.

The agent keeps working in its own checkout, whether that runs locally or in the cloud, and syncs changes to the Mac. All scripts and builds then run on the Mac. With this, the time from requesting a Mac to inspecting changes on a running device dropped to a few minutes.

Step 5: Tear down and rotate

When a session ends, the Mac is destroyed and a replacement is prepared. Idle Macs also get replaced periodically, pulling fresh main and rebuilding apps and caches. That rotation is staggered so active sessions aren't interrupted and the pool stays available.

Step 6: Teach the agent it has a Mac

This is the step people skip, and it's the one that made the rest work.

The infrastructure was running, but River was blind to it. Shopify wrote a skill to teach agents how to test their changes and prove their work. It took several iterations. Early on, River kept forgetting about the remote Mac, went silent while it was talking to the Mac, or took a long time to get back to the user.

Two pieces of tooling fixed most of that:

• A CLI that wraps the SSH flags, so the agent doesn't have to get them right every time.
• tmux panes River can watch in real time, instead of sleeping or setting timeouts while the Mac runs long tasks.

Step 7: Make the agent prove its work

Code that compiles isn't code that works. With Remote Dev, agents can navigate the app, interact with elements, and capture screenshots or recordings on both iOS and Android.

For a bug fix, River reproduces the issue, records the broken behavior, makes the fix, then repeats the same steps to show before and after. The reviewer sees what changed instead of only reading a diff.

Shopify went one step further. River can now turn those recordings into explainer videos, with the app running inside 3D phone renders, plus animations and narration, all generated automatically.

Step 8: Let humans in with Live Preview

River could send screenshots, but people wanted to try the app themselves. So Shopify streams the iOS Simulator and Android Emulator from the Remote Dev environment to a Quick website over WebSockets. The browser shows the live device and sends your interactions back to the remote simulator or emulator.

Every session gets its own Live Preview for both platforms. Sessions are shareable, so several people can watch and work on the same running app. It also supports deep linking and live streaming of the mobile CLI.

No local setup, no builds to install, and you don't need a Mac.

What do the agents actually do with all this?

Each River session gets its own environment, so one agent can debug something on Android while another builds an iOS feature and a third tests a PR. Each task starts from Slack. Nobody opens Xcode or Android Studio locally.

The work Shopify hands off includes:

• Rebasing branches and resolving merge conflicts
• Checking CI failures
• Addressing PR feedback
• Triaging incoming crashes
• Reviewing code

Some workflows run overnight with nobody starting them. They pick up bugs, implement fixes, test them and open PRs, so the team starts the morning with fixes ready for review.

It also changed who can touch mobile. A web developer can fix a bug, a designer can iterate on a UI, and a PM can test a feature, all through Slack.

Did people actually use it?

Not at first. Some people had tried early versions of River and found builds not working, too slow, and not useful day to day. Shopify describes the shift as a psychological problem as much as a technical one. People were used to a local simulator they could use themselves.

So they marketed it internally. They turned River into a character, a person frustrated with mobile work who gets a real Mac at home, and suddenly everything works. One campaign was an AI-generated parody of the Mac vs PC ad.

Then they closed the loop. A fast, cheap classifier model called Jev watches all mobile River conversations, tags them, and the team categorizes each one by how good the outcome was. The failures go to an LLM that looks for improvements, and they run this iteratively using River, so River improves itself.

The number: River went from creating 6% of merged mobile pull requests to 61%.

When should you build something like this, and when shouldn't you?

This is my read of Shopify's write-up, not their advice.

Build it when:

• You run more than a handful of agent tasks at once. Shopify's ceiling was 3 or 4 per laptop. If you're past that, you already feel it.
• Your agents need to prove UI behavior, not just compile. Mobile is the obvious case. The point of the Mac is a real simulator that can record before and after.
• Your cold setup is slow. The warm pool exists because setup took over 30 minutes. That wait is what the pool removes.
• People outside the specialist team need to contribute. Live Preview turns a running app into a link anyone can open.

Skip it, or wait, when:

• You run one agent at a time. A laptop handles that. You'd be paying for a fleet to solve a problem you don't have.
• Your environment boots in seconds. A warm pool, rotation and teardown are a lot of moving parts if cold start is already fast.
• You haven't taught the agent. Shopify had the machines running and River still said iOS couldn't build on Linux. Infrastructure without the skill gets you nothing.
• You can't measure it. Shopify tracked merged PR share and graded conversations with a classifier. Without some version of that, you won't know if it's working or just running.

What does one session look like, end to end?

Here is a bug fix session as a diagram in words, using only the steps Shopify describes:

Slack message: "fix this bug"
  -> River claims a warm Mac from the pool
  -> syncs its branch, attaches a prebuilt Android VM
  -> reproduces the bug, records it
  -> edits code in its own checkout, syncs to the Mac
  -> builds and runs tests on the Mac, watched through tmux panes
  -> repeats the same steps, records the fixed behavior
  -> opens a PR with before and after recordings
  -> reviewer opens the Live Preview link and tries it
Session ends
  -> Mac destroyed, a replacement is prepared

And here is the pool idea as a small sketch. This is my own illustration of the pattern, not Shopify's code:

type Mac = { id: string; state: "ready" | "claimed"; builtAt: number };

async function claim(pool: Mac[], branch: string) {
  const mac = pool.find((m) => m.state === "ready");
  if (!mac) throw new Error("No warm Mac available yet");
  mac.state = "claimed";
  await syncBranch(mac, branch);
  await attachAndroidVm(mac);
  return mac;
}

async function release(pool: Mac[], mac: Mac) {
  await destroy(mac);
  pool.splice(pool.indexOf(mac), 1);
  pool.push(await warmNewMac());
}

async function rotateOneIdle(pool: Mac[], maxAgeMs: number) {
  const stale = pool.find(
    (m) => m.state === "ready" && Date.now() - m.builtAt > maxAgeMs
  );
  if (stale) await release(pool, stale);
}

Three functions carry the whole idea. claim is the front desk. release is housekeeping after checkout. rotateOneIdle refreshes one stale room at a time, which is the staggering: you never take the whole pool offline at once.

The slow work, warmNewMac, happens while nobody is waiting on it. That's the trick. You move the 30 minutes out of the request path.

FAQ

What is Shopify Remote Dev?

Remote Dev is Shopify's system that gives its AI agent, River, a remote mobile development environment. Each session claims a pre-warmed Mac with iOS simulators and an attached Android emulator, so agents can build, test and record both apps without using a developer's laptop. Shopify described it on October 22, 2026.

How does Remote Dev run the Android emulator on a Mac?

Android's emulator needs hardware virtualization, and running it in a cloud VM requires nested virtualization, which macOS doesn't support out of the box. Shopify runs the emulator on a separate Linux VM with nested virtualization enabled and connects it to the Mac. Agents then build and test both platforms in the same SSH session.

Why does Remote Dev keep a pool of warm Macs?

Checking out Shopify's massive monorepo and compiling the apps took over 30 minutes. By preparing Macs in advance, with main checked out, tools installed, apps built and caches warm, the wait from requesting a Mac to seeing changes on a running device dropped to a few minutes.

Did Remote Dev change how much code AI agents ship at Shopify?

Yes. River went from creating 6% of merged mobile pull requests to 61%. Shopify credits more than the infrastructure: internal campaigns to change local development habits, and a feedback loop where a classifier model called Jev tags River conversations so failures feed improvements.

If you run agents in parallel, time your cold setup this week and write the number down, then try the free tools on Art of Code for the small jobs in between. Shopify is hiring mobile engineers for this work, and you can find more roles like it on the Art of Code job board.

Written by Adithya Guttha, Founder of Art of Code.