Superwall Framework
Build paywalls, onboarding funnels, and web checkout flows as React mini-apps — in your repo, with your tools, shipped without an app update.
The Superwall Framework lets you build paywalls, onboarding funnels, and web checkout flows as code. Each one is a small React app in a superwall/ directory inside your repo: a config.ts that declares its name and products, an app/ directory of pages, and whatever components, styles, and assets it needs. Superwall provides everything else — products, purchases, localization, trial handling, and the bridge to the native SDKs — so you never touch native code to change what your users see.
superwall/paywalls/pro/
├── config.ts definePaywall({ name, products: { annual: "pro_5999_year" } })
├── app/ pages — index.tsx, plans.tsx, layout.tsx
├── components/ everything that is not a page
└── messages/en.ts localized strings, discovered by filenameYou preview locally with superwall dev, which opens a studio with device frames, light/dark toggles, locale switching, and simulated purchases. When you're happy, superwall push seals an immutable version, and superwall promote points production at it — your users get the new paywall on the next open, no app review required.
The framework requires the headless paywalls feature to be enabled on your Superwall application. If a push tells you it isn't, contact us to have it turned on.
Why code-first?
- It's just React. State, components, hooks, CSS — nothing to relearn, and your existing component patterns carry over. Use Tailwind, Motion, Rive, or plain CSS; the framework doesn't care.
- Version-controlled and reviewable. Paywalls live in your repo, go through your PR process, and ship from CI if you want them to.
- Ship without app releases. Pushed paywalls are delivered remotely by the same SDKs you already use. Promote a new version — or roll back — in seconds.
- Store data stays store-owned. Prices, periods, and trials come from the App Store, Google Play, or Stripe at runtime, localized and formatted for each user. You never hardcode a price.
- One flow, many steps. Multi-page onboardings and funnels are a single paywall whose steps are pages on a navigation stack — no network between steps, no loading spinners.
How it fits together
| Piece | What it does |
|---|---|
superwall (npm) | The framework: definePaywall, hooks, navigation, the build |
superwall (CLI) | create, dev, push, promote, publish |
| The studio | Local preview at localhost:6100 — devices, themes, locales, simulated outcomes |
| The dashboard | Where pushed paywalls, versions, and products live; campaigns decide who sees what |
| The native SDKs | Present your paywall in-app, deliver product data, run purchases |
Your app keeps presenting paywalls exactly as it does today — through placements and campaigns. The framework changes how paywalls are built, not how they're shown.
Start here
Quickstart
Scaffold a project, preview your first paywall in the studio, and ship it.
Project structure
How a superwall/ directory is laid out and which files to commit.
Pages & navigation
Build multi-page flows with file-based routes and a stack router.
Purchases
Declare products, read live prices, and handle every purchase outcome.
Go deeper
- Configuration — everything
definePaywallaccepts, from presentation style to trial reminders. - Web checkout — sell the same paywall on the web with one config key.
- Variables & personalization — react to user attributes, device state, and placement parameters.
- Localization — one file per locale, picked automatically from the device.
- Examples — complete standalone projects, each teaching one idea.
How is this guide?