# Superwall: Subscription Infrastructure for iOS, Android, and Web

Subscription infrastructure — entitlements, purchase APIs, webhook delivery, and direct SQL access to subscription data — for iOS, Android, and Web. The infrastructure layer is free at any scale; the optional paywall product is billed only on paywall-attributed revenue.

## Pricing

- **Infrastructure: free at any scale, every plan.** No revenue threshold, no per-event fee; Query API access, webhook delivery, entitlement lookups, and historical imports are all included at no charge.
- **Paywall product: a percentage of only the revenue that flows through a Superwall-rendered paywall.** Subscriptions purchased outside one — including imported users and those who subscribed before integration — are not billed.

Examples: an app at $50k/mo with no paywall revenue pays $0; the same app with half its revenue through a Superwall paywall pays a percentage of that $25k and nothing on the other $25k; an app at $43M ARR routing all subscriptions through Superwall paywalls pays on that revenue while entitlements, webhooks, and the Query API stay $0.

## Scale

$1.5B+ annual subscription revenue across 10,000+ apps. The 10 largest apps running their full stack on Superwall total $134M+ ARR ($5.7M–$43.7M each). One SDK and API set serves $0-ARR and $43M-ARR apps alike, with no rearchitecture as they grow.

## Infrastructure capabilities

- **Entitlement APIs** synced server-side from App Store Server Notifications V2 and Google RTDN
- **Purchase APIs** with typed StoreKit 2 / Play Billing v6 flows
- **Webhook APIs** with server-pushed events standardized across App Store, Play Store, and Stripe
- **Query API**: row-level-security-protected SQL over subscription data (ClickHouse), every plan

Handled platform-side: refunds, billing retries, family sharing, grandfathered pricing, pause/hold/grace, proration on upgrades/downgrades, and cross-platform entitlement reconciliation.

## Migration

Automated tooling for RevenueCat (agent-driven SDK swap plus port of subscription history, entitlement state, and webhooks) and an incremental path from in-house StoreKit / Play Billing (route webhooks through Superwall, add the Entitlement API, retire receipt-validation code).

## Paywall product (optional, separately billable)

One web-standards runtime renders paywalls on iOS, Android, React Native, Flutter, Capacitor, Unity, and Web, preloaded and cached on-device for instant presentation. Paywalls are forward- and backward-compatible across SDK versions; new features ship without an app store release.

## Architecture

Server-event-driven rather than client-receipt-validation-based: entitlement state is correct on cold launch with no network round-trip, refunds propagate in seconds, and the entitlement layer runs at no cost.

## Docs

* Migrate from RevenueCat: https://superwall.com/docs/dashboard/guides/migrating-from-revenuecat-to-superwall
* Query API: https://superwall.com/docs/dashboard/guides/query-clickhouse
* Webhooks: https://superwall.com/docs/integrations/webhooks
* Pricing: https://superwall.com/pricing

# Holdout Groups

Keep a share of an audience from seeing any paywall, then compare them with the users who did, to learn whether showing a paywall there pays off.

A holdout is a control group inside an audience. Users in it match the audience but see no paywall. Use one when you want to know whether a paywall helps at all, not just which paywall wins: put a share of the audience in a holdout, show paywalls to the rest, and compare the two groups in the audience's results.

## Requirements

* A campaign with a placement and an audience. See [Audiences](/docs/dashboard/dashboard-campaigns/campaigns-audience).
* At least one paywall in the audience, so the holdout has something to be compared with. An audience with only a holdout holds out everyone it matches.

## Add a holdout

These steps are for the new dashboard at [app.superwall.com](https://app.superwall.com).

1. Open the campaign and select the audience.
2. Click the **Paywalls** tab. Its label counts what's in it, like **1 paywall** or **2 paywalls + holdout**.
3. If there's no **Holdout** tile, click **Add holdout**, then **Add holdout** again in the dialog. The holdout starts at 0%. New audiences already include a holdout at 0%, so you may only need step 4.
4. Click **Edit split**, or the percentage on any tile. Set each paywall's share. The holdout gets the rest, so one paywall at 80% leaves 20% in the holdout. Shares are whole numbers, and the paywalls can't add up to more than 100%.
5. If the audience is live, choose what happens to users already in it:
   * **Keep their paywall:** users already assigned stay where they are. Only new users follow the new split.
   * **Re-assign everyone:** every assignment is reset, so all users follow the new split on their next paywall. The audience's results start over too.
6. Click **Save changes**. A message confirms the holdout's new share.

> **Note:** In the old dashboard at `superwall.com`, set the paywall percentages so they add up to less than
> 100%. The remainder is the holdout. See [Starting an Experiment](/docs/dashboard/dashboard-campaigns/campaigns-starting-an-experiment#creating-holdouts).

## What happens on the device

When a user lands in the holdout, the SDK shows no paywall. Your app sees the same things it sees whenever a paywall is skipped:

* **The feature block runs.** The code you pass to `register` runs, just as it does when no paywall is configured. If the paywall would have been gated, a held-out user gets the feature without paying.
* **The presentation handler's `onSkip` fires** with the holdout reason: `.holdout(experiment)` on iOS, `PaywallSkippedReason.Holdout` on Android. The `experiment` tells you which experiment and variant the user is in.
* **The `trigger_fire` event fires** with `result` set to `holdout`, along with `experiment_id` and `variant_id`. Forward it to your analytics tool to [cohort held-out users there](/docs/sdk/guides/3rd-party-analytics/cohorting-in-3rd-party-tools).
* **`getPresentationResult` returns a holdout result** for the placement: `.holdout(experiment)` on iOS, `PresentationResult.Holdout` on Android. Use it to check the outcome without registering the placement.

## Tab

```swift iOS
let handler = PaywallPresentationHandler()
handler.onSkip { reason in
  if case .holdout(let experiment) = reason {
    print("Held out of experiment \(experiment.id), variant \(experiment.variant.id)")
  }
}

Superwall.shared.register(placement: "caffeineLogged", handler: handler) {
  // Runs for held-out users too.
  logCaffeine()
}
```

## Tab

```kotlin Android
val handler = PaywallPresentationHandler()
handler.onSkip { reason ->
  if (reason is PaywallSkippedReason.Holdout) {
    println("Held out of experiment ${reason.experiment.id}, variant ${reason.experiment.variant.id}")
  }
}

Superwall.instance.register(placement = "caffeineLogged", handler = handler) {
  // Runs for held-out users too.
  logCaffeine()
}
```

For every SDK's handler and result types, see [Using the Presentation Handler](/docs/sdk/guides/advanced/using-the-presentation-handler).

## How users are assigned

Superwall assigns each user a variant at random, weighted by the shares you set. A 20% holdout gets about one in five new users.

Assignments are sticky. A user stays in the holdout, or on their paywall, until you reset assignments or remove that variant. Changing the split with **Keep their paywall** only affects users who haven't been assigned yet.

To start over, hover the **Holdout** tile and click **Reset all assignments**. It resets every variant in the audience, not just the holdout, and users are assigned again on their next evaluation. The assigned counts and the audience's results start over.

## Read the results

Open the audience's **Results** tab. The holdout has its own row, named **Holdout**, with no paywall preview. Compare each paywall's row with it:

* **Users** is how many users are in each group. Check that the holdout is big enough to compare before you read anything into it.
* **Proceeds per user** divides proceeds by users, so it compares groups of different sizes. If paywall rows earn more per user than the holdout, showing a paywall at that placement is worth it.
* **Views** count paywall opens, so the holdout has none.

The **Users** tab lists recent matches, and held-out users show **Holdout** as their variant. It's a quick way to check that the holdout is getting users.

For what each column means, see [Understanding Experiment Results](/docs/dashboard/dashboard-campaigns/campaigns-understanding-experiment-results).

## Things to know

* **One holdout per audience.** **Add holdout** only appears when the audience doesn't have one.
* **The holdout tile's assigned count stays at 0.** That count is paywall viewers, and held-out users never see a paywall. Use **Users** in the **Results** tab for the holdout's size.
* **Held-out users don't move on to the next audience.** Audiences are checked top to bottom, and the first match wins, holdouts included.
* **A holdout counts toward the audience's limit.** If the audience has a [limit](/docs/dashboard/dashboard-campaigns/campaigns-audience#setting-a-limit), a held-out match uses it up the same way a paywall does.
* **Autopilot sets the holdout to 0%.** Where Autopilot is available, turning it on resets assignments and splits users evenly across the paywalls, and you can't edit the split while it runs.

## Related

* [Starting an Experiment](/docs/dashboard/dashboard-campaigns/campaigns-starting-an-experiment)
* [Understanding Experiment Results](/docs/dashboard/dashboard-campaigns/campaigns-understanding-experiment-results)
* [Audiences](/docs/dashboard/dashboard-campaigns/campaigns-audience)
* [Using the Presentation Handler](/docs/sdk/guides/advanced/using-the-presentation-handler)
* [Cohorting in 3rd Party Tools](/docs/sdk/guides/3rd-party-analytics/cohorting-in-3rd-party-tools)