Onboarding updates without a new app release

The problem: onboarding never stops changing

Onboarding tends to get rewritten more than any other screen in a subscription app — a new value-prop test, a shortened flow, a reordered step — and every version has historically meant another build and another wait for store review.

That churn is exactly what a staged, reversible delivery path is for: a screen that changes monthly (or weekly) accumulates release overhead faster than almost anything else in the app, and a bad onboarding variant is also one of the few mistakes that can quietly suppress activation for every new user until someone notices.

The workflow in four steps

1. Validate the onboarding document against the target platform schema before signing — this catches a state field, action, or slot the host app doesn't declare support for, so the failure shows up locally instead of on a device.

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

2. Export a signed, immutable bundle for the new onboarding variant, with a unique update ID distinct from the previous version — update IDs can't be reused, which is what keeps release history honest.

swift run pororoca export .pororoca/documents \
  --output .pororoca/update --update-id onboarding-v2 \
  --private-key .pororoca/keys/private.key

3. Publish it to a small rollout percentage first, so only a deterministic slice of new installs by install ID sees the new flow while the rest keep the version you already know works.

POROROCA_API_TOKEN=pororoca_live_... 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. Watch `applied` telemetry in the dashboard to confirm the new flow is actually rendering for the cohort, then widen through the same staged rollout used for any other screen, or roll back in one command if completion rates drop.

status → publish 10% → observe → 25% → observe → 50% → observe → 100%

It's the same signed-document, deterministic-rollout workflow as a paywall or any other screen — onboarding isn't a special case, just a screen that changes often enough that this matters more, and one where a bad variant is easy to miss without `applied` telemetry, since a confused new user rarely files a bug report.

Limits and the trial

On 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, and full modifier parity with SwiftUI isn't there yet — worth accounting for if your onboarding flow leans on iOS-specific presentation that Android can't yet mirror exactly.

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.