MobileCode: the opencode Fork for Mobile Apps

Search for mobilecode and you land on four different things, two of which sit close enough together to cause real trouble. There is a four-day-old GitHub repository that forks opencode and teaches it to build iOS and Android apps. There is an Android app on Google Play, by a different author, that drives an opencode server from your phone. There is a C editor for phones that happens to share the name. And "mobile code" was a security term long before any of them existed. This piece is about the fork, and the first job is telling it apart from the rest.

Four things answer to the same name

The repository is hsandhu/mobilecode, created on 5 September 2026, carrying 225 stars and 26 forks when I checked it on 9 September. MIT licence, mostly TypeScript, and exactly one contributor: Rob Sandhu. Its README states the thing plainly rather than building up to it — a fork of opencode that knows about mobile projects.

The Play Store app is io.apuyou.mobilecode by Arthur Puyou, past a thousand downloads. Reading its description next to the fork's is the fastest way to see why the collision matters, because the two solve opposite halves of one problem. Puyou's app says it "lets you control your OpenCode sessions remotely from your phone," connecting to a server running on your own machine, and it needs a direct network route, so the same LAN or something like Tailscale. That moves the interface onto the phone while the work stays at your desk. The fork does the reverse: the interface stays at your desk and the device moves into the session. Install one while expecting the other and nothing will behave the way you predicted.

The third, dev.mark.mobilecode, is a C editor written on a phone for use on phones, with per-line wrapping, bracket-based folding and Termux integration. No relation to any of this. And SC-18 in NIST SP 800-53 still owns "mobile code" in its original meaning: code that arrives across a network and executes locally, which is where the searchable volume for the plain two-word phrase actually sits.

What the fork adds on top of opencode

opencode is not a small parent to fork. anomalyco/opencode dates to 30 April 2025 and sits above 205,000 stars; if you want the wider comparison, our opencode versus Claude Code writeup covers where it lands against the obvious alternative. mobilecode inherits the whole surface: terminal UI, desktop app, web UI, any model provider, MCP, plugins and skills. Then it adds one thing the parent doesn't do.

Open a session inside a mobile project and a device pane opens by itself, next to the conversation. Behind that pane, npx serve-sim or npx serve-avd starts on whichever machine is running the mobilecode server and streams the simulator or emulator into the app, with Start, Stop, Reload and Open in browser controls sitting on top. Project detection reaches two directories below the session root, so an app parked in a subfolder still gets found. Skills and plugins come along from opencode unchanged, which means anything from a curated skills library you already run keeps working inside the fork.

What counts as a mobile project is a specific list rather than a vibe. On iOS: Xcode projects and workspaces, CocoaPods, and Expo apps. On Android: Gradle projects and Expo apps. Take that literally instead of assuming your particular layout is covered.

One Play button, two platforms, one Metro server

The React Native case is the one the project leads with, and it shows what the fork is actually for. Press Play once and mobilecode starts a single Metro server, builds both native projects, and launches them into embedded Simulator and Emulator panes together. Missing native project? expo prebuild generates it. Pods get installed, and the emulator reaches Metro through adb reverse. One Metro serves both platforms.

The per-platform mechanics are pleasantly boring. iOS runs xcodebuild against the first shared scheme, then simctl install and simctl launch. Android runs ./gradlew :<module>:assembleDebug, then adb install -r -g and an explicit launch intent. Status walks through Building, Installing, Launching and Running, and a failure surfaces the first compiler or Gradle error with the full log one click away in the device pane. All of it is also exposed over HTTP, at /api/device-preview plus start, stop, run and run/stop, which is the seam you'd use to wire it into anything else. That HTTP surface puts it in the same family as the macOS harness browser-use shipped: a local daemon an agent talks to, rather than a library it imports.

Then comes the constraint worth planning around: one project at a time. The simulator, the emulator and the Metro port are shared, so starting a project stops whatever else was running. Switch back to a tab whose project had been live and mobilecode brings it back, relaunching the installed app without a rebuild where it can. That's the right design for one machine, and it also tells you exactly what happens when you want two things building at once. The honest answer is a second machine. Giving the agent its own hosted box is the cheap version of that: Zentor is a cloud AI computer that sits next to your laptop rather than replacing it, so the agent can keep reading issues, drafting the changelog and chasing docs while your Mac is tied up holding an emulator port.

`device_run` is the part that changes how the agent behaves

Everything above is a nicer window. The device_run tool is the part that changes the loop.

It lets the agent build and launch the app itself, wait for the result, then read the build error and the log tail. The README is blunt about the payoff: the agent can fix a failing build "without you pasting logs." Anyone who has spent an afternoon as a clipboard between a compiler and a chat window knows how much of the session that consumes, and it is genuinely the least interesting work in the building.

The catch is time. A cold xcodebuild plus a Gradle assemble plus two installs is not a two-second round trip, and an agent that iterates on a failing build will sit in that loop repeatedly, which means the machine holding the simulator has to stay awake and stay yours for as long as the loop runs. A laptop that sleeps when you close it is a poor host for work measured in unattended half-hours. That gap is the one Zentor fills: a hosted cloud AI computer that stays awake so the retry loop has somewhere to land, running alongside your existing install rather than in place of it.

15,695 commits, one contributor, four days old

The GitHub page reports 15,695 commits on a repository created four days ago, which is a number to read carefully rather than be impressed by. Almost all of that history belongs to opencode; the commit list is full of upstream messages like "fix(opencode): route SAP AI Core reasoning variants" that predate this fork entirely. The default branch is dev, and the sole release is tagged 1.18.29, published 6 September, which is opencode's version line rather than a fresh 0.1.0.

None of that is a criticism. It is the normal shape of a young fork, and it tells you what the maintenance question really is. The interesting risk isn't whether the mobile pane works; it's whether one person keeps rebasing onto a parent that ships constantly. The patches/ directory and a commit reading "test(opencode): guard patched dependency versions" suggest the author has thought about it. Four days of history is not enough to know how that goes.

What has to be installed before any of it runs

The requirements are heavier than the install line implies, and they are where most first attempts will stop.

iOS needs macOS with Xcode, and serve-sim wants Node 20 or newer. Android needs the SDK platform-tools and at least one AVD already created, plus a JDK that your project's Gradle version actually supports. Package names are read out of the built APK with aapt2, which means the SDK build-tools have to be present too. Installation itself is a shell one-liner that drops a release binary into ~/.mobilecode/bin and puts it on your PATH, or a bun install from source.

Configuration is inherited wholesale. mobilecode keeps opencode's format and locations, so an existing opencode.json, your provider credentials, plugins and skills carry over untouched, config still lives in ~/.config/opencode, data in ~/.local/share/opencode, and environment variables keep the OPENCODE_ prefix. That inheritance includes model choice, which is the part people forget to treat as a decision: the model that reads a Gradle stack trace well is not necessarily the one you want writing the release notes, and Zentor's integrations pages exist so you can pick per task instead of settling once.

If you want the desktop build, bun run build:macos produces MobileCode.app plus a .dmg and .zip. It's unsigned by default, so the first launch needs a right-click and Open; passing --sign with a Developer ID certificate and the APPLE_API_KEY trio gets you a notarised build instead.

Is mobilecode free, and what does MIT actually cover here

Yes, and the licence is clean. mobilecode is MIT, built on opencode, and it keeps opencode's MIT licence and copyright notice intact. There's no separate commercial tier in the repository and no contributor licence agreement to sign before you can use it.

Free software with a heavy toolchain is still not free of cost, though. The bill moves from the licence to the hardware: a Mac that can run Xcode, an emulator that wants RAM, and enough uninterrupted time for the agent to iterate. Zentor's own pricing is deliberately small against that — three days and 1,000 credits to try it, then $20 a month for 1,000 credits — because the point is adding a machine that stays up, not replacing the one you develop on.

FAQ

Is mobilecode free to use?

Yes. It's MIT licensed and free to run, and it keeps the MIT licence of opencode, which it forks. You supply your own model provider access through opencode's existing configuration.

Is mobilecode a fork of opencode?

Yes, and the README says so in its first line. It forks anomalyco/opencode and keeps that project's configuration format, file locations, OPENCODE_ environment prefix, plugin system and skills, then adds mobile project detection, the embedded device pane and the device_run tool.

Can an AI agent build iOS and Android apps?

It can drive the build. With device_run, the agent triggers xcodebuild or ./gradlew assembleDebug, waits for the result, and reads back the first error plus the log tail, so it can act on a failure without a human relaying output. What it cannot do is conjure a toolchain: Xcode, the Android SDK, an AVD and a compatible JDK still have to be installed and working on the machine running the server.

Which MobileCode is on the Google Play Store?

Two unrelated ones. io.apuyou.mobilecode is a phone client that connects to an opencode server on your own machine over the local network or a VPN. dev.mark.mobilecode is a C editor for phones. Neither is the hsandhu/mobilecode fork described here, which has no mobile app of its own.

Does mobilecode work on Windows or Linux?

Android builds are not macOS-bound, but the iOS half is: Xcode and the iOS Simulator only exist on macOS, and the macOS desktop app is the only packaged build the repository ships. Treat it as a Mac-first tool as of September 2026.