Lifecycle & Events

What a paywall knows and when, the preload rule that shapes every entry animation, and the SDK events you can react to.

The SDK preloads paywalls hidden before showing them. Your components mount long before anyone is looking, so a mount-timed animation (a useEffect on mount, Motion's initial/animate firing on mount, a CSS animation on load) has already finished by the time the paywall appears. This one fact shapes every entry animation you'll write.

Gate entry animations on presentation, never mount

The presentation signal is useSuperwallSnapshot().paywall. It flips from undefined when the paywall is actually shown:

import { useSuperwallSnapshot } from "superwall/hooks";

const opened = useSuperwallSnapshot().paywall !== undefined;

<motion.div
  initial={{ opacity: 0, y: 14 }}
  animate={opened ? { opacity: 1, y: 0 } : { opacity: 0, y: 14 }}
/>

Unlike an event listener added in an effect, the snapshot cannot miss the moment. It reads current state rather than waiting to be told.

Value-driven animations gate on both conditions. A price count-up starts when opened && raw !== undefined, never when the store delivers the price (it would play while hidden), and never on a missing value (it would land on a made-up figure):

const rawPrice = Number(annual?.variables.rawPrice);
const raw = Number.isFinite(rawPrice) ? rawPrice : undefined;

React.useEffect(() => {
  if (opened && raw !== undefined) {
    const controls = animate(price, raw, { duration: 0.9, ease: "circOut" });
    return () => controls.stop();
  }
}, [opened, raw]);

The with-motion example is the reference for both patterns. The ownership rule that goes with them: animation libraries animate inside a page, moving between pages is the router's job, so spamming navigation can never fight your component animations. See Transitions.

Events you can react to

import { useSuperwallEvent } from "superwall/hooks";

useSuperwallEvent("transaction_complete", () => haptics.success());
useSuperwallEvent("freeTrial_start", () => { /* trial began */ });

Event	Fires when
`paywall_open`	The paywall is presented (or re-presented). Prefer `snapshot.paywall` for anything render-driving.
`transaction_complete`	A purchase succeeded, whoever started it. A restore does not fire this event; see Purchases.
`transaction_abandon`	The store sheet was closed.
`transaction_fail`, `transaction_timeout`	The store reported a failed or timed-out purchase. `purchase()` resolves `failed` with `reason: "sdk"`. iOS only: the Android SDK does not send these.
`transaction_start`	The store sheet is about to open. iOS and Android.
`freeTrial_start`	A trial actually began. Also triggers the configured trial reminder.
`restore_start`, `restore_complete`, `restore_fail`	The restore lifecycle, also on `snapshot.restore`. iOS sends all three; Android sends only `restore_fail`.
`paywall_close`	The host dismissed the paywall.
`experiment`	The experiment assignment arrived (`experimentId`, `variantId`, `campaignId`).
`back_button_input`	Android hardware back. Only sent when the dashboard reroutes it to the paywall, which a framework paywall cannot enable, so in practice it never arrives and the SDK dismisses on its own.
`game_controller_input`	Controller input, needs `gameControllerEnabled: true` in config.
`event_tracking_behavior`	The app's analytics opt-out level (`all`, `superwallOnly`, `none`), also on `snapshot.eventTrackingBehavior`.
`message`	Every incoming SDK message, the debugging firehose.

Subscriptions last the component's lifetime; an inline arrow handler is fine.

For products, variables, and introductory-offer eligibility, use the dedicated hooks instead of events. They read current state and cannot miss data that arrived before your component subscribed. Data arrives progressively after open (paywall id → products → variables → eligibility → experiment), which is one more reason every read is guarded.

Dark mode

The device decides; the framework maintains a dark/light class on <html>. Style with plain CSS and write no wiring:

:root { --bg: #fdfef6; --fg: #0c0b0a; }
:root.dark { --bg: #1c1b19; --fg: #fdfef6; }

Don't use @media (prefers-color-scheme: dark) as the mechanism, it cannot see what the device reports and ignores the studio's theme toggle. The class is the mechanism. Styling has the full treatment, including Tailwind.

Dev vs device

The same paywall is hosted by the studio in superwall dev and by the SDK on device, over the same protocol. You pick purchase outcomes in one and the store does in the other, product variables come from your dashboard in one and from the store on the other, and numeric product variables arrive as strings on device (device numerics like daysSinceInstall stay numbers). The full comparison table is in The studio.

The platform stylesheet

Published paywalls receive a small Superwall-owned stylesheet at serve time, platform-wide behavior like scroll control. Previews apply the same one, so local and published render identically. Set SUPERWALL_RUNTIME_URL in the project .env only if you need previews to use a local build of that platform layer.

Gate entry animations on presentation, never mount

Events you can react to

Dark mode

Dev vs device

The platform stylesheet

On this page