Superwall Framework

Superwall paywalls are normally built in the visual editor. The framework is the other way to build them: as React code, in your own repo, reviewed and versioned like the rest of your app.

Everything after the build is unchanged. Paywalls are still delivered by the native SDKs, still shown through placements and campaigns, still experimented on from the dashboard, and still updated without an app release. The framework changes how a paywall is authored, not how it reaches your users.

"Paywall" is the dashboard's word for it, but the same project holds any screen you would rather change after shipping than release for: onboarding and quizzes, update-required and force-upgrade screens, rate-us and notification prompts, announcements, offers and win-backs. Each is a surface behind a placement, edited in code, previewed in the studio, and live on the next app open.

What you write

A paywall is a small React app in a superwall/ directory:

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 filename

config.ts declares the paywall's name and which products it sells. app/ holds the pages. Everything else is ordinary React: your components, your CSS, your dependencies. Four hooks connect it to Superwall, with useProducts() for live store prices, usePurchase() to make the sale, useActions() to close or restore, and useHaptics() for the tap.

You preview locally with superwall dev, which opens a studio with device frames, light and dark toggles, locale switching, and outcomes you pick for every purchase, restore and permission. superwall push then seals an immutable version and superwall promote points production at it. Users get the new paywall on next open, with no app review.

Why write a paywall in code

If you are comfortable in React you could build the UI yourself in an afternoon. What takes longer is everything around it, and that is the part the framework gives you:

• Prices you cannot get wrong. Products are declared as references like annual: "pro_5999_year". Price, period, and trial terms come from the App Store, Google Play, or Stripe at runtime, already localized and formatted. A reference your dashboard has no product for blocks the push outright, so a paywall cannot ship with a stale or hardcoded price.
• Purchases, restores, and trial eligibility, handled. The parts that are boring to write, easy to get subtly wrong, and expensive when you do.
• Shipping without an app release. A hand-rolled paywall is stuck behind your release train. A pushed one is live on next open, and rolling back is one promote.
• Campaigns and experiments still apply. A code paywall is A/B tested from the dashboard like any other, so you keep the measurement.
• Multi-step flows are natural. An onboarding quiz or web funnel is one paywall whose steps are pages on a stack router. No network between steps and no loading spinners.
• It lives in your repo. PRs, code review, CI, your component library, your design tokens. Use Tailwind, Motion, Rive, or plain CSS; the framework has no opinion.

Which should I use

Both ship the same way, and an app can use both. The framework trades the no-code loop for code-level control.

How it fits together

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

Go deeper

• Configuration, everything definePaywall accepts, 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.