Firebase Remote Config vs server-driven UI

Two different jobs that look similar from a distance

Firebase Remote Config lets you change key-value parameters in a live app without a release — a price string, a feature toggle, a copy variant already coded into the UI. Server-driven UI, the category Pororoca is built for, goes further: the screen's structure itself is sent as data and rendered natively, so you can change what's on screen, not just which of several pre-built branches is active.

What Remote Config is good at

Remote Config is simple, fast to adopt, and works across whatever platforms Firebase supports. For flipping a value your UI already knows how to display — a limit, a flag, a string — it's hard to beat for how little setup it needs.

Where it stops

Every possible outcome of a Remote Config value has to already be built and shipped in the app. It can pick between paths you compiled in advance; it can't hand the client a new screen structure it hasn't seen before, and it has no built-in signing, staged-rollout-by-install, or screen-level rollback model of its own.

Where Pororoca fits

Pororoca ships the screen itself as a signed, data-only document to a native runtime — an iOS 17+ SwiftUI runtime with a managed crash-safe store and embedded fallback, or 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 if a screen needs to come back, and `applied` telemetry visible in the dashboard so you can see whether the new screen actually rendered on real devices.

A publisher CLI and remote publish step move signed bundles to the control plane, and the same operations are available to a coding agent through an MCP server.

Because every document is signed before publish, a malformed or tampered value can't silently reach the UI the way an unvalidated remote-config parameter could — the runtime checks the manifest's Ed25519 signature and hashes before it ever renders. And because `applied` telemetry is tied to the specific update ID your CLI generated, you can trace a live screen change back to the exact publish command and rollout percentage that shipped it, rather than just a generic parameter name and its last-known value.

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 available 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, card-required 21-day trial, billed in BRL or USD.