Server-driven UI for iOS and Android

What server-driven UI actually means

Server-driven UI describes a screen as data — its structure, content, and behavior contracts — and renders it with native components on the device, instead of hardcoding that screen into a build. Done well, it lets a screen change without a new app release, while the app still renders with real native views rather than an embedded web page.

What it costs to build in-house

Larger mobile organizations have built internal systems along these lines, and the pattern is consistent: a schema for describing screens, native renderers on each platform that stay in sync with that schema, a way to sign or validate what a client receives, a staged-rollout mechanism so a bad screen doesn't reach everyone at once, and telemetry to know whether an update actually rendered. That's a dedicated platform investment, not a weekend project.

What Pororoca gives you out of the box

Pororoca is that system, already built: an iOS 17+ SwiftUI runtime with a managed crash-safe store and embedded fallback, and an Android API 26+ Compose runtime that verifies a document's signature and hashes before using it. Every document ships as an Ed25519-signed manifest, 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 visible in the dashboard. A publisher CLI validates and signs documents, a remote publish step delivers them to the control plane, and an MCP server exposes the same operations to a coding agent.

Adopting it in four steps

1. Validate the screen document you've authored for the target platform.

swift run pororoca validate .pororoca/documents --platform ios

2. Export a signed, immutable bundle.

swift run pororoca export .pororoca/documents \
  --output .pororoca/update --update-id first-sdui-screen \
  --private-key .pororoca/keys/private.key

3. Publish it at a conservative rollout percentage.

swift run pororoca publish .pororoca/update \
  --server https://pororoca-ota.fly.dev --app your-app-slug \
  --channel production --rollout 10 \
  --public-key .pororoca/keys/public.key

4. Confirm the endpoint the SDK calls resolves the update for an eligible install, then repeat the same four steps for the Android bundle with `--platform android` — the schema, signature, and rollout mechanics are identical, only the platform flag and runtime differ.

curl -i \
  -H "Authorization: Bearer $POROROCA_RUNTIME_TOKEN" \
  "https://pororoca-ota.fly.dev/api/v1/apps/your-app-slug/channels/production/resolve?install_id=docs-smoke-0001"

Android and team limits, honestly

Android storage is host-managed today, the previous-update crash recovery available on iOS is not yet in the Android SDK, the renderer surface is smaller than SwiftUI's, and full modifier parity between platforms isn't there yet. That gap matters most for a schema meant to work identically everywhere: a document that leans on an iOS-only modifier won't render the same way on Compose until parity closes.

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, in BRL or USD.