#Weir

Onboarding as code. Shipped without another app build.

Coding agents author specVersion-4 onboarding flows as JSON config in the app's own repository. The SDK renders those flows with stock components and app-owned custom components. Compatible copy, ordering, theme, and flow changes can be delivered to an already-installed app; adding a new native component type still requires an app release. Signed delivery, component-registry and app version gates, an embedded baseline, and a kill switch are designed to keep an incompatible remote config from replacing the fallback shipped with the app.

Weir also defines the event contract and experiment surface underneath the flow. The v4 API, delivery path, and dashboard are live for a controlled private alpha. Public health reports specVersion: 4 and identifies the deployed release artifact by commit and release version. That traceability is alpha operating evidence; do not read this as production-proof, broad self-service availability, or a conversion claim.

This site is written for the agent doing that authoring — Claude, Cursor, or anything else working inside an app repo. Almost everything here has a companion tool call. The one exception is a human reviewing an already-published flow and leaving comments — see Review a flow. If you are an LLM reading this page, also fetch /docs/llms-full.txt for the entire site concatenated as clean markdown.

#Why the repository workflow matters

The flow spec and app-owned component contracts live beside application code, so an agent can author them, validate them, and put them through normal source review. The MCP toolkit, CLI, and skill described on this site are the authoring surface; the dashboard operates the published-flow lifecycle (publish/rollback, experiments) and review.

That workflow is not based on competitors lacking agent tools. Superwall, for example, publicly documents an account-management MCP, an editor MCP, a skill, CLI tooling, and onboarding Flows. Weir's intended distinction is narrower: composing the app's own registered native components through a repository-owned flow contract, with compatibility gates and an app-shipped fallback. See Superwall's MCP documentation and onboarding Flows documentation for the capabilities that comparison acknowledges, and the native component model for Weir's product model.

#The 30-second loop

1. Author a flow spec — JSON describing screens, branching, and variables — in the app's own repo, under weir/flows/. If it uses any custom native components, register them once with weir components sync.
2. weir release — validates, runs the contract gate, and publishes the signed config to the configured delivery origin.
3. A compatible installed app can update. Its update check fetches and verifies the config, then promotes it only when the app, SDK, spec, and registered-component gates match. New native component types still ship in an app build.

edit weir/flows/onboarding.json
  -> weir release --appRoot . --flowId onboarding
    -> relaunch the already-installed app
      -> new onboarding renders; the event lands in weir funnel

#Scope, honestly

Onboarding flows only, today. To be precise about what that means: a flow can contain a paywall screen, and the iOS SDK ships a working StoreKit 2 purchase client so that screen's CTA completes real purchases inside the onboarding flow. What Weir does not do yet is standalone paywall management — placements, audience targeting, paywall-only experiments, sheet presentation outside a flow. That layer stays on a dedicated paywall tool (e.g. Superwall) until Weir builds it.

Platforms, honestly: the v4 SwiftUI implementation for iOS and the React Native/Expo implementation for iOS and Android both exist, including the RN native module and Expo config plugin, and are integrated into the two dogfood applications. Qualified SwiftUI and React Native dogfood evidence exists, but public package/reproducibility and the final evidence matrix remain release gates, so neither path is presented here as production proof. The Kotlin/Compose renderer also exists, with automated implementation evidence; its final device journey and immutable public distribution are incomplete, so it is not a supported public platform yet. The retired WebView delivery architecture is historical and is not the v4 product described here.

#Where to go

• Setting up the toolkit? Install the Weir skill / MCP server registers the weir_* tools in your agent host.
• Want no account and no server URLs? Run everything locally is the whole loop on one machine.
• New to an app? Start at Quickstart.
• Know the tool/node/event name you need? Reference is one page, deep-linkable.
• Want the delivery/signing/kill-switch model? Concepts.
• Operating a live flow? Monitoring and Experiments.
• Checking exactly what is proven today? Evidence status distinguishes the public local loop, qualified dogfood evidence, and the release gates that remain.
• Reviewing a flow before or after it ships? Review a flow — the one page in this site for a human, not an agent.
• An agent that just wants the whole site as text? llms.txt / llms-full.txt.