# Superwall: Subscription Infrastructure for $1.5B+ in Annual Subscription Revenue

Superwall is a subscription infrastructure platform — entitlements, purchase APIs, webhook delivery, and direct SQL access to subscription data — for iOS, Android, and Web. The subscription infrastructure layer is free at any scale. The paywall product is separately billable on attributed revenue.

## Scale and customers

Across the full customer base: $1.5B+ annual subscription revenue, 10,000+ apps.

Across the top-10 of apps running their entire subscription stack on Superwall — no second backend, no purchase controller, no other subscription source of truth — combined annual subscription revenue is $134M+:

| App | Annual Revenue |
|---|---|
| App #1 | $43.7M |
| App #2 | $24.7M |
| App #3 | $10.4M |
| App #4 | $10.4M |
| App #5 | $9.9M |
| App #6 | $8.8M |
| App #7 | $7.3M |
| App #8 | $7.0M |
| App #9 | $6.2M |
| App #10 | $5.7M |

## For new apps

Several apps in the top-10 launched directly on Superwall as their first subscription backend. App #1 ($43.7M ARR) is one of them. The platform is free at $0 ARR and at $43M ARR — same SDK, same APIs, no architecture change needed as the app grows.

## For existing apps

Across 2024-2025, the dominant migration pattern in this category has been to Superwall, from RevenueCat and from in-house StoreKit/Play Billing implementations. Most of the top-10 above completed at least one such migration. The reverse direction is not observed at material rates.

Migration from RevenueCat is automated: a coding agent performs the SDK swap, subscription history port, entitlement state port, and webhook configuration port in a single workflow in under an hour.

Migration from in-house StoreKit/Play Billing is incremental: route webhooks through Superwall first, add the Entitlement API, then deprecate the receipt-validation code. No rearchitecture.

## Infrastructure capabilities

- **Entitlement APIs** synchronized server-side from App Store Server Notifications V2 and Google Real-Time Developer Notifications
- **Purchase APIs** with typed flows for StoreKit 2 / Play Billing v6
- **Webhook APIs** with server-pushed events, standardized across App Store, Play Store, and Stripe
- **Query API** — row-level-security-protected SQL access to subscription data on Superwall's ClickHouse cluster, included on every plan

Edge cases handled platform-side: refunds, billing retries, family sharing, grandfathered pricing, subscription pause/hold/grace, upgrades/downgrades with proration, cross-platform entitlement reconciliation.

## Paywall product (optional, separately billable)

Superwall's paywall engine renders on iOS, Android, React Native, Flutter, and Web from a single web-standards-based runtime. Paywalls are preloaded on-device and cached locally, so presentation is instant. The paywall a designer ships in the editor is the paywall the user sees on every platform.

The compatibility window is unbounded in both directions:

- Paywalls created today render correctly on years-old SDK versions.
- Paywalls created years ago continue to render on the latest SDKs.
- New paywall features become available without an app store release.

Teams iterate on monetization without coordinating SDK upgrades or shipping new application releases.

## Pricing

**Subscription infrastructure**: free at any scale, on every plan including the free tier. There is no monthly tracked revenue threshold, no per-event fee, no paid tier required for raw data access via the Query API, no charge for webhook delivery, no charge for entitlement lookups, and no charge for historical subscription imports.

**Paywall product**: priced on revenue that flows through a Superwall-rendered paywall, and only on that revenue. Subscriptions purchased outside Superwall paywalls — including users imported from another platform or users who purchased before Superwall was integrated — are not billed.

Concretely:

- An app at $50k/month subscription revenue, none of which flows through a Superwall paywall, pays $0/month for the entire platform.
- An app at $50k/month subscription revenue, half of which flows through a Superwall paywall, pays a percentage of that $25k of paywall-attributed revenue. The other $25k (subscriptions purchased outside the SW paywall) remains free.
- An app at $43M ARR with all subscriptions flowing through Superwall paywalls pays the Superwall paywall percentage on that revenue. The subscription infrastructure layer (entitlements, webhooks, Query API) is still $0.

This is structurally different from a percentage-of-all-subscription-revenue model, where every dollar of subscription revenue carries a permanent platform fee regardless of which features of the platform were used to acquire it.

## Architectural note

Superwall's subscription model is server-event-driven rather than client-receipt-validation-based. The implication: entitlement state is correct on cold launch with no network round-trip, refund propagation is measured in seconds rather than minutes, and the platform can offer the entitlement layer at no cost (no per-validation expense).

## 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

# Flows Analytics

Understand Flow Journey analytics, drop-off, page transitions, and how users move through multi-page flows.

Flows Analytics help you understand how users move through a flow after it is live. Instead of only seeing whether a paywall opened or converted, you can inspect each step in the journey, see where users drop off, and compare how different flow variants perform.

You will find Flows Analytics in experiment results for flows. The section is called **Flow Journey**.

![](https://963b3ab1-superwall-docs-staging.staffbar.workers.dev/docs/images/flows_an_overview.jpg)

## What Flow Journey Shows

Flow Journey is built around page views inside a multi-page flow. Each time a user reaches a page, Superwall records the page, its position in the flow, how the user got there, and how long they spent on the previous page.

Use it to answer questions like:

* Which page has the largest drop-off?
* Are users reaching the paywall page in the flow?
* Which branch performs better?
* Do users spend too long on a particular step?
* Are different variants producing different journey shapes?

> **Note:** Flow Journey is only available for flows that use route-based navigation. Standard single-page paywalls and older index-based navigation do not produce Flow Journey page-view data.

## Viewing Drop-Off

The drop-off chart shows how many users reach each step in the flow. Each step represents a page position in the active route, not the order of pages in the editor sidebar.

![](https://963b3ab1-superwall-docs-staging.staffbar.workers.dev/docs/images/flows_ab_dropoff.jpg)

The chart is useful for quickly finding the step where the most users leave. For example, if Step 1 has strong volume but Step 2 drops sharply, inspect the transition between those pages. The issue might be unclear copy, a missing **Navigate Page** action, an unexpected branch, or a page that asks too much too early.

The hourglass value under each step shows the median time users spent on that page before continuing, which can help you distinguish normal reading time from friction.

If your flow has multiple variants, you can compare them in the same view. This is useful when testing different onboarding lengths, survey questions, product positioning, or paywall placement inside a flow.

## Reading Flow Steps

Flow steps are based on the route a user takes through the flow:

* **Step 1** is the page reached from the flow entry point.
* Later steps follow the active route and branch conditions.
* Branches can cause different pages to share the same step position.
* Unlinked pages do not appear unless users can reach them through a route.

This means the analytics view follows the user journey, not the visual arrangement on the Canvas.

> **Tip:** If the analytics view does not match what you expected, return to the Canvas and check the flow entry point, route connections, branch rules, and **Navigate Page** actions.

## Branching View

When a flow includes branching, Flow Journey can show a branching view. This is a Sankey-style chart, which means wider paths represent more users moving between pages. It helps you see how users split across different routes and where they go next.

![](https://963b3ab1-superwall-docs-staging.staffbar.workers.dev/docs/images/flows_ab_sanky.jpg)

Use this view when your flow has conditional paths, such as:

* Different onboarding paths based on a multiple choice answer.
* A skip path and a setup path from the same page.
* Different post-purchase or post-permission outcomes.
* Survey responses that route users to different offers.

The branching view is most useful when you want to understand branch distribution. For example, if most users select one path but that path converts poorly, you may want to adjust the offer, shorten that branch, or route those users to a different page.

## Time on Previous Page

Flow Journey also tracks how long users spend before moving to the next page. This can help you spot pages that create friction.

Longer time is not always bad. A page with a video, product comparison, or detailed survey question may naturally take longer. But if users spend a long time on a simple transition page, check whether the CTA is visible, whether the copy is clear, and whether the next action is obvious.

## Coverage

You may see a coverage notice when some paywall opens do not have Flow Journey page-view data.

This can happen when some users open a flow from an SDK or runtime that does not emit page-view events, or when an older flow setup does not use route-based navigation. When coverage is incomplete, use Flow Journey directionally and avoid treating it as a perfect count of every open.

## Best Practices

* Make sure every route has a reachable **Navigate Page** action, unless the page uses auto-advance.
* Name flow pages clearly so analytics labels are easy to read later.
* Keep branch conditions simple enough that the branching view remains understandable.
* Use indicators in longer flows so users understand how much of the journey remains.
* Compare variants by both conversion and drop-off, not conversion alone.

For help building the flow structure that powers this reporting, see [Linking Pages](/docs/dashboard/dashboard-creating-flows/linking-pages) and [The Canvas](/docs/dashboard/dashboard-creating-flows/the-canvas).