How to Use Shipvo: The Beginner's Guide to Open-Source React Native OTA Updates

CodexFuse Team · 2026-11-05T05:16:45.218Z · 18 min read min read

How to Use Shipvo: The Beginner's Guide to Open-Source React Native OTA Updates

What Is Shipvo?

Shipvo is an open-source React Native framework that lets you publish signed over-the-air (OTA) updates to an installed app without a new store submission, and it ships a simulator that AI agents can drive. If you searched for how to use shipvo, here is the short version: you build your app once, publish JavaScript updates over the air to phones, and open the exact same release in a phone-sized simulator that an agent can see and operate. The project launched publicly on Hacker News on November 2, 2026, and its repository describes it as pre-launch and measured, with every simulator claim checked against real Android and iOS devices.

The idea behind shipvo react native work is a split that every mobile developer already lives with. Some parts of an app must go through the store: the native shell, the native modules, the declared permissions, and the signing trust root. Everything else, the JavaScript screens, features, and fixes built on capabilities the shell already declares, can travel over the air.

Shipvo makes that split explicit with a declared-capability shell manifest, so an update can never ask the phone for a permission the original install did not declare.

That safety story is why signatures matter here. Every Shipvo release is signed with Ed25519, and the signature is verified natively on the device against a public key built into the app, so an update cannot replace its own trust root. A SHA-256 hash generator shows the same integrity idea in miniature: Shipvo verifies SHA-256 and size before a bundle is staged, and staging is atomic, so a half-downloaded update never becomes the running app.

The control plane behind all of this runs on Cloudflare Workers, and the same infrastructure thinking applies to any self-hosted backend, which is why the basics of VPS hosting are useful background for running your own update server.

How Do You Use Shipvo? The Short Version

You use Shipvo by scaffolding an app with its CLI, running it in the simulator, building the native shell once, and then publishing every later change over the air with one command. The full first arc looks like this, and each step is explained in detail below.

1. Start a project with npx -y @shipvo/cli init myshop, move into it, install dependencies, and install the browser engine the simulator needs with npx playwright install chromium.
2. Run npm run sim to open your app in the phone-sized simulator, and check that the screens, navigation, and device features behave the way you expect.
3. Build the native shell with npx expo run:android (or the iOS equivalent) and install that store-style build on a device, so the phone has a shell to receive updates.
4. Change something small, a price, a label, a screen, and ship it with shipvo publish, which builds the Hermes bundle, hashes it, diffs it, and signs the release pointer.
5. Watch the staged rollout reach the first cohort, confirm the telemetry looks healthy, and widen the rollout from 1 percent to 10 percent and then to everyone.

That is the whole loop. Everything after this section is detail: what each piece does, how the simulator works, how rollouts and rollbacks behave, and how Shipvo compares with the other OTA tools you may already know.

What Do Shipvo OTA Updates Actually Change?

Shipvo OTA updates change the JavaScript layer of your app: the Hermes bytecode core runtime, plus screens and add-ons built on the shell's declared capabilities. They do not change native code, and they cannot add a native module or a permission that the installed shell does not already have. That boundary is the single most important thing to understand before you publish anything, because it decides whether a change can go over the air at all.

Here is how the project's own documentation draws the line. The native shell ships through the App Store or Google Play and contains the native modules, declared permissions, and signing trust root. The core runtime, the app's JavaScript as Hermes bytecode, ships over the air and signed.

Screens and add-ons, meaning new screens, features, and fixes built on capabilities the shell already declares, also ship over the air and signed. If your feature needs a brand-new native capability, that is a store release, not an OTA update, and no OTA tool can change that rule.

The practical payoff is speed on the changes that do qualify. A bug fix, a price change, a new screen built from existing components, or a copy update can reach every phone without a review queue. The sample app in the repository demonstrates the rhythm: the app checks for updates every 10 seconds while it is open, verifies the update, applies it, and logs the timings on screen.

A content change made in the per-app admin shows up on the phone in about 10 seconds.

How Do You Install Shipvo and Start Your First App?

You install Shipvo by scaffolding a project with its CLI, and the repository's own start sequence is four commands. Run npx -y @shipvo/cli init myshop, then cd myshop, then npm install, then npx playwright install chromium. The last command matters more than it looks: the simulator runs in a headless browser, so it needs a Chromium engine installed before npm run sim will work.

Once the install finishes, npm run sim opens your app in the simulator, and agents can open the same app through the MCP server, which is covered below. To get the app onto a real phone, build the native shell with npx expo run:android and install the resulting build. That shell is the thing users install from a store; everything after it can arrive over the air with shipvo publish.

Two environment notes from the repository are worth knowing up front. Contributing to Shipvo itself requires Node 22 and pnpm 10, which is a stricter toolchain than the npm-based start sequence for using it. And the sample app, a shop called tide-and-tackle, can be tried without writing any code: download its latest shell APK from the project's Releases page and install it on an Android 7 or newer phone.

How Does Shipvo Publish a Release?

Shipvo publishes a release by building the Hermes bundle, hashing it, creating bsdiff patches against earlier releases, and signing the release pointer with Ed25519. The command is shipvo publish, and the pipeline behind it is deliberately boring in the best sense: build, hash, diff, sign, serve. The signed envelope travels through the Cloudflare edge as static files, with one URL pattern per app, shell major version, and rollout band, plus immutable bundle files and bsdiff patches.

On the phone, the native runtime, written in Kotlin for Android, fetches the pointer, verifies the signature, downloads the bundle or patch, verifies SHA-256 and size again, stages it atomically, and reloads. If the new release fails to boot three times, the runtime discards it automatically, which is the crash-loop protection. You can also roll back to the previous release in one call, so a bad release is a one-command retreat rather than an emergency store submission.

The repository is candid that these numbers come from measurement, not marketing. Its OTA figures were taken on a real low-end phone, a Redmi 9A with 2 GB of RAM, and the headline patch figure in the project description is 64 KB patches. Treat that as the project's measured small-patch case, not a promise about your app: your patch size depends on how much of your bundle actually changed.

The iOS OTA runtime is verified on the iOS Simulator in continuous integration on every change, covering fetch, verify, stage, reload, and cold start.

What Are Staged Rollouts in Shipvo?

Staged rollouts in Shipvo are cohort bands served as static signed pointers from the edge: 1 percent, then 10 percent, then everyone, with no device registry. Because the bands are static files rather than a database lookup, there is no per-device tracking server to run, and the rollout decision is just which signed pointer a device reads. That design is also why the control plane can stay small: it is a Hono worker on Cloudflare using KV, D1, and R2 storage.

Here is what the bands mean in practice, worked out for an app with 10,000 installs. At 1 percent, about 100 devices are offered the release, which is enough to catch a crash that only appears on real user data. At 10 percent, about 1,000 devices get it, which is where performance and telemetry patterns become trustworthy.

At everyone, the remaining roughly 8,900 devices follow. If the 1 percent cohort shows failures, the rollback is one call, and the other 99 percent never saw the bad release at all.

Telemetry comes with every release: applied, reverted, cold-start time, download size, and download time. That combination is what makes a staged rollout a decision instead of a guess. You are not watching a dashboard for vibes; you are watching applied versus reverted counts and cold-start times at each band, and widening only when the numbers stay clean.

What Is the Shipvo AI Simulator?

The shipvo ai simulator is a phone-sized simulator that lets an AI agent use your app without a phone, through the Model Context Protocol (MCP). The agent opens an app with open_app("tide@latest"), which returns the first screen as an accessibility tree with refs, and then uses tap, type, scroll, back, and screenshot to operate it. The package that makes this possible is @shipvo/mcp, and it plugs into Claude, Cursor, Claude Code, or PiPilot with a short server configuration.

The configuration the repository shows is a single MCP server entry that runs npx -y @shipvo/mcp. Once it is connected, an agent can also control the simulated device itself: set_device decides what the phone has, such as a barcode in front of the camera, a location, whether a fingerprint matches, whether a payment is approved, or whether the network is off. A second package, @shipvo/device, gives apps one device API for camera, location, biometrics, payments, notifications, share, and network, and that API is real on phones and simulated in the simulator.

The honesty mechanism is explicit simulation. Every simulated event is logged as simulated, and no simulated payment or fingerprint is ever presented as real. What the agent sees is what a person using a screen reader would see: only the items of a rail that are on screen, nothing hidden behind a modal sheet, and system dialogs worded the way Android or iOS words them.

If you already work with an AI coding agent, our guide on how to use Claude Code covers the agent workflow that pairs naturally with driving an app this way.

How Good Is the Simulator Compared With a Real Phone?

Shipvo answers that question with a parity harness instead of a claim, and the published results are specific enough to quote. The harness runs the same flows on the simulator, an Android emulator, and an iPhone simulator, and compares every screen. The current result is 100 percent actionable parity on Android and iOS across the 13-screen purchase flows.

The native-feature flow is where the numbers get more interesting, because the project publishes its gaps instead of hiding them. On that flow, 18 of 21 screens match at 100 percent on Android, the three gaps are listed in the project's parity document, and iOS matches at 100 percent, with the orders themselves compared as well. Native-feature parity for camera, location, permissions, and payment prompts is measured on Android, and iOS is next, according to the repository.

Read those numbers for what they are: a pre-launch project's own measurements, published with the method and the gaps attached. They are a stronger signal than an unmeasured claim, and a weaker signal than independent verification, which does not exist yet for a project that is days old. The right way to use them is as a reason to try the simulator on your own flows, not as a guarantee about yours.

How Do You Self-Host the Shipvo Control Plane?

You self-host the Shipvo control plane by deploying its Cloudflare Worker yourself, since the control plane is a Hono worker using KV, D1, and R2, and the repository lists self-hosting as a supported path. The hosted control plane lives at api.shipvo.dev and the hosted simulator at sim.shipvo.dev, but neither is mandatory: the same worker code is in the repository under services/control-plane, and the docs include a self-hosting guide.

Self-hosting is where the self-hosted react native ota story gets concrete. Your control plane serves the signed pointers, the immutable bundles, the bsdiff patches, and the web artifacts for agents, and it also hosts the per-app admin at /app/<id>/admin. That admin is a real product surface, not a debug page: it shows live content, prices, offers, orders, and history, and it can publish to every phone in seconds.

The same typed owner commands are available to agents with a token.

Two licensing notes matter before you commit to this path. The framework itself is Apache-2.0, which the repository states plainly. The hosted control plane may be offered under a source-available license, while self-hosting stays permitted, so read the license file in the repository before you build a business on the hosted service rather than your own deployment.

A Docker target for the control plane is planned, not shipped, so today self-hosting means the Cloudflare Worker route.

Shipvo vs Hot Updater: Which Self-Hosted OTA Tool Fits?

Shipvo vs Hot Updater is the comparison most self-hosting teams will actually make, and the two tools differ more in philosophy than in feature checklists. Hot Updater is an open-source, self-hosted OTA framework with plugin-based storage and database integrations, designed for teams that want to choose their own storage, database, build, and hosting providers. Shipvo is an open-source framework with a fixed Cloudflare control plane, signed add-ons, a per-app admin, and an agent-operable simulator built in.

The table below compares Shipvo with the OTA options a React Native team shortlists in 2026. Treat every third-party figure as vendor-reported, and read the comparison as orientation, not a ranking, because these products change fast and the right choice depends on your stack.

The context for all of these is the CodePush retirement. Microsoft retired Visual Studio App Center, including CodePush, on March 31, 2025, and the original CodePush repository was later archived, which is why every tool above exists in its current form. Bitrise forked the SDK and maintains it, and its service went generally available on March 10, 2026, according to an independent comparison of the six tools.

Hot Updater's documented trade-off is the honest one for all self-hosted options: you remain responsible for selecting, deploying, securing, and maintaining the backend infrastructure.

So the decision is really about what you want to own. Choose Shipvo if the agent-operable simulator and the built-in admin matter to you, and you are comfortable with the Cloudflare control plane. Choose Hot Updater if you want to assemble your own storage and database stack and keep every infrastructure choice in your hands.

Choose a managed option if you would rather pay someone else to run the update server. None of these is a rival to be defeated; they are different answers to the same post-CodePush question.

What Are Shipvo's Limits and Risks?

Shipvo's biggest limit is its age, and the repository does not hide it. The project was created on October 29, 2026, its public launch was November 2, 2026, its status badge reads pre-launch, and at the time of writing it had 281 commits, 26 releases, and only 2 GitHub stars. That is a small, young project, and a small project can change direction, break APIs, or stall in ways a mature tool will not.

The second limit is scope: OTA updates cannot touch native code, permissions, or modules, so any feature that needs a new native capability still needs a store release. The third is platform maturity: the iOS OTA runtime is verified on the iOS Simulator in CI, while native-feature parity measurement on iOS is still next, so Android is the better-measured platform today. The fourth is operational: self-hosting means you run the control plane, the storage, and the incident response, and the Docker target that would simplify that is still planned.

None of this makes Shipvo a bad choice, but it does make it a choice to try on a side project or a new app first. The sample shop app exists for exactly that reason: run it in the simulator, publish a test release, stage it to yourself, roll it back once on purpose, and only then decide whether the framework earns a place in a production app. If you keep your releases in version control, our guide on how to use Git covers the branching and push workflow that pairs with publishing releases from a repository.

Who Should Use Shipvo, and Who Should Skip It?

Shipvo fits React Native developers who ship JavaScript changes often, want staged rollouts with automatic rollback, and want AI agents to test the app without a device farm. It fits particularly well if you already work with agents, since the simulator turns "let the agent try the checkout flow" from a device-lab project into an MCP call. It also fits teams that like self-hosting, since the control plane is a worker you can run yourself.

Skip Shipvo for now if you need a battle-tested OTA service with years of production history, if your app is Expo-managed and EAS Update already covers you, or if your next release needs new native modules anyway. Skip it too if your team cannot afford to babysit a pre-launch dependency, because the price of a young open-source project is attention, not money. Revisit it in a few months, when the release history and the iOS parity measurements will tell you much more than any launch-week article can.

Sources

Shipvo repository, github.com/shipvo/shipvo — fetched November 5, 2026. (Project description, README features, start commands, release pipeline, staged rollouts, simulator and MCP tools, parity results, repository layout, license, pre-launch status, creation date, commits, stars, releases.)

WeSearch, "Show HN: Shipvo – open-source RN OTA updates and an AI-drivable simulator" — Show HN record, November 2, 2026; fetched November 5, 2026. (Launch date, canonical repository URL, open-source React Native OTA framing.)

Revopush, "App Center CodePush Alternatives for React Native" — updated August 23, 2026; fetched November 5, 2026. (CodePush retirement March 31, 2025; Hot Updater as open-source self-hosted plugin-based OTA; Stallion and Hot Updater patch delivery; self-hosting responsibility.)

Extension Booster, "CodePush Is Dead: 6 React Native OTA Tools Compared" — fetched November 5, 2026. (Bitrise CodePush general availability March 10, 2026; EAS Update, Hot Updater, and Bitrise positioning; delta figures flagged as self-reported.)

MobileApp.wiki, "OTA Updates: Ship Fixes Without the App Store" — fetched November 5, 2026. (What OTA updates can and cannot change; EAS Update and CodePush background; runtime-version matching rule.)

Frequently Asked Questions

Is Shipvo free?

Shipvo the framework is open source under Apache-2.0, so using the code costs nothing. Running it costs whatever your hosting costs: the Cloudflare Worker, KV, D1, and R2 usage for a self-hosted control plane, or whatever the hosted service charges once its pricing is published. The repository links a pricing page, but no prices are quoted here because they were not verified at write time.

Does Shipvo work with Expo?

Yes, in the sense that matters for getting started: the start sequence uses npx expo run:android to build the native shell, and the repository lists Expo among its topics. Shipvo is not EAS Update, though, and it does not run inside Expo Go. It is its own runtime and control plane that happens to build its shell with Expo tooling.

Can Shipvo update native code?

No. Shipvo OTA updates change the JavaScript layer: the Hermes bytecode runtime and the screens and add-ons built on capabilities the shell already declares. A new native module, a new permission, or a change to the native shell itself requires a store release, exactly as with every other OTA tool.

What happens if a Shipvo update crashes on launch?

The runtime discards a release that fails to boot three times, automatically, and you can roll back to the previous release in one call. Combined with staged rollouts, that means a crashing release should reach only the first small cohort before it is pulled, not your whole install base.

How is Shipvo different from Hot Updater?

Hot Updater is a plugin-based, self-hosted OTA framework where you choose your own storage and database stack. Shipvo adds a fixed Cloudflare control plane, a per-app admin, signed add-ons, and an AI-drivable simulator with measured device parity. Choose Hot Updater for maximum infrastructure choice, and Shipvo if the simulator and the built-in admin matter more to you.