Rork will scaffold a React Native app faster than you can describe it. Type a prompt, watch an Expo app assemble itself, scan a QR code, and it's running on your phone in Expo Go. For the first afternoon it feels like the mobile sandbox finally caught up to the web ones.

Then you try to put it in front of real users, and you find the wall every sandboxed mobile agent shares: getting a React Native app onto a phone you don't own is not a deploy button. It's a pipeline — and the pipeline lives on your machine and Apple's, not in a browser tab.

The scaffold is the easy 80%

Sandboxed RN agents are genuinely good at the part they own. Screens, navigation, a component tree, some mock data, running in Expo Go. That's real value, and it's the part that demos well.

It's also the part that was never the hard part of shipping mobile. The hard part starts the moment you leave the sandbox's preview.

The App Store is not a deploy button

On the web, "ship it" is a push. On mobile, it's a process that a sandbox structurally cannot run on your behalf:

• An Apple Developer account ($99/yr) and a Google Play account, in your name.
• Signing credentials — distribution certificates, provisioning profiles, an Android keystore — generated and stored as secrets.
• A production build compiled for each store's requirements, with the right bundle identifier, version, and build number.
• Store review — screenshots, privacy labels, a description, an age rating, and a human at Apple who can reject you.

A browser-tab agent can't hold your signing keys, can't run eas build, can't submit a binary to App Store Connect under your account. None of that is a limitation of the AI — it's a limitation of running inside someone else's sandbox.

Native modules need a real build

The moment your app needs anything past the JS bridge — a camera, notifications, in-app purchases, secure storage, Skia, MMKV — you're past what Expo Go can run.

# This is the line that ends the sandbox preview:
npx expo prebuild            # generates the native ios/ + android/ projects
npx expo run:ios             # compiles the native app locally
eas build --platform ios     # or compiles it in the cloud for the store

Config plugins patch the native projects at build time. A development build replaces Expo Go for anything with a custom native module. This is normal, well-documented Expo work — and it requires a real build environment, a real app.json/app.config.ts, and a real EAS pipeline. A sandbox that only knows how to render into Expo Go can't follow you here.

OTA updates need a channel you own

Once you're shipping, you want to push a JS fix without a new store review. That's eas update — and it pushes to a channel tied to your project and your credentials.

eas update --branch production --message "fix the checkout race"

Installed clients on the production channel pull the new bundle on next launch. That whole loop — your EAS project, your channels, your build profiles in eas.json — is infrastructure you own. It can't live in a tool that doesn't have your account.

The agent that can do this lives in your repo

Here's the thing: a file-system agent can do all of the above. Claude Code or Cursor, sitting in your actual repo, can run eas build, read your eas.json, wire a config plugin, bump the build number, and walk the store submission — because it has access to your machine, your credentials, and your scripts.

The difference isn't intelligence. It's location. The sandbox agent is in a browser tab that ends at the Expo Go preview. The file-system agent is in the repo where the real pipeline runs.

What it takes to make the last mile boring

The reason the last 20% is brutal isn't that any single step is hard — it's that they're undocumented for your project, so your agent has to re-derive them. Make them explicit and the agent flies through them.

That's what we put in the OTF fitness kit: one Expo codebase that runs on iOS, Android, and web, an eas.json with the build profiles already defined, the EAS Update channel wired, a CLAUDE.md that tells the agent exactly how this app builds and ships, and the store-submission steps written down instead of folklore. You scan the QR to preview it in seconds — same as Rork — but the thing you bought knows how to leave the preview.

Rork getting you to a running preview in five minutes is real, and it's worth something. Just don't mistake it for shipping. The preview is the part that was always easy. The App Store is the part that decides whether anyone but you ever runs your app — and that part lives where your agent and your credentials are, not where the sandbox ends.