The Expo Updates equivalent for native SwiftUI and Compose

Expo Updates solves a different stack

Expo Updates (via EAS Update) lets Expo and React Native teams push JavaScript and asset changes to installed apps between store submissions, organized by channel and branch. It's a mature, well-integrated part of the Expo release flow.

None of that reaches a team that writes SwiftUI or Jetpack Compose directly, without a React Native or Expo layer underneath. Those apps have no JavaScript runtime to update in the first place, so "Expo Updates for native iOS" isn't a configuration problem — it's a different tool entirely.

What Expo Updates is good at

For its actual audience, Expo Updates is a strong, low-friction way to iterate: publish a new JS bundle, target it at a channel, and let installed clients pick it up on next launch. It fits naturally into how Expo apps are already built and released.

Where it stops

It's scoped to the Expo/React Native runtime. If your screens are compiled Swift and Kotlin rather than interpreted JavaScript, there is no bundle for Expo Updates to replace, and the tool simply doesn't apply.

Where Pororoca fits

Pororoca is built for exactly that native case. It ships a signed, data-only screen document — never executable code — to an iOS 17+ SwiftUI runtime with a managed crash-safe store and embedded fallback, or to an Android API 26+ Compose runtime that verifies the document's signature and hashes before rendering it.

Manifests are Ed25519-signed, with the private key staying on a developer machine or in CI. Rollouts are deterministic by install ID, organized into channels, with one-command rollback and `applied` telemetry in the dashboard so you know a screen actually rendered successfully, not just that a publish call returned 200.

Everything ships through a publisher CLI and a remote publish step to the control plane, and the same actions are exposed to coding agents through an MCP server.

Channels give you separate cohorts for the same app — production, staged, or a named pre-release group — so the branch-and-channel habit an Expo team already has maps onto native screens instead of a JS bundle. Because rollout is deterministic by install ID rather than re-rolled on every request, a device that lands in the initial 10% stays in that cohort as you widen it, which is what makes comparing `applied` telemetry before and after a widen meaningful rather than noise.

Android and team limits, honestly

Android storage is host-managed today; the host keeps the last accepted document for offline use, but the previous-update crash recovery that exists on iOS is not yet in the Android SDK, the renderer surface is smaller, and full modifier parity with SwiftUI isn't there yet.

Not yet available: team members and RBAC, usage-based limits, automated alerts, cross-platform expression parity, and a hosted MCP transport. There's one Pro plan with a card-required 21-day trial, in BRL or USD.