# 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

# Web Checkout FAQ

Frequently asked questions about web checkout.

### How does restoring memberships work when you've purchased via web checkout?

When the user taps on the restore link in the paywall, we'll do the normal restore flow for on-device subscriptions. However, if you've enabled web checkout and the restored
entitlements don't match the entitlements belonging to the products on the paywall, we'll present an alert asking the user if they'd like to check for purchases on the web. This will
take them out of your app to the [plan management screen](/docs/web-checkout/web-checkout-managing-memberships) where they can get a redemption link to restore their purchases.

### Does Superwall email customers after checkout?

Yes. By default, Superwall emails the address used during checkout with instructions and a redemption link to activate the purchase in your app. The email is sent from `Your app name <support+your-app-name@superwall.app>` with the subject `Your activation link from your app name`.

![](https://963b3ab1-superwall-docs-staging.staffbar.workers.dev/docs/images/web-checkout-redeem-email.png)

To turn these off, use the "Disable Superwall Emails" setting in your Stripe app settings — see [how to disable the activation link email](/docs/support/web-checkout/3969573187-how-do-i-disable-the-activation-link-email-for-web-checkout).

### Do customers who use Sign in with Apple Hide My Email receive web checkout emails?

Yes. If customers check out with an Apple private relay address, such as `abc123@privaterelay.appleid.com`, register Superwall as an allowed email source in Apple Developer.

Superwall sends web checkout emails from your app-specific Superwall address, such as `support+your-app-name@superwall.app`. These emails include activation and subscription management links. Apple can reject those emails for Hide My Email customers unless `superwall.app` is registered as an email source for Sign in with Apple.

Configure this before launching web checkout:

1. Go to [Apple Developer Services Configuration](https://developer.apple.com/account/resources/services/configure).
2. Open **Configure Sign in with Apple for Email Communication**.
3. Add `superwall.app` as an email source. If you prefer to authorize a specific sender, add your app's Superwall sender address, such as `support+your-app-name@superwall.app`.

![](https://963b3ab1-superwall-docs-staging.staffbar.workers.dev/docs/images/sign-in-with-apple-email-sources.png)

Once registered, Apple will allow emails from Superwall to be delivered to private relay addresses.

For Apple's requirements, see [Configure private email relay service](https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service).

> **Warning:** If you skip this step, customers who use **Hide My Email** may not receive web checkout emails
> from Superwall. If customers already checked out before the email source was registered, ask them
> to request a new link from your `https://{your-domain}.superwall.app/manage` page after the sender
> is configured.

### What happens if a user taps the redemption link multiple times or shares it?

Redemption codes are single-use and tied to a specific device. Once a code has been redeemed, it cannot be used again on a different device.

However, users can visit the manage page and request a new redemption link. This generates a new code that can be used to activate access on another device.

#### Without accounts (`identify` not called)

If you're not using accounts with Superwall (i.e. you never call `identify`), we allow up to **five active devices** per user. When a sixth device redeems a code, the **first device** to have redeemed a code will automatically lose access. This helps prevent abuse while still supporting reasonable multi-device usage.

#### With accounts (`identify` called)

If you are using accounts with Superwall (i.e. you call `identify` with an `appUserId` when someone logs in), then entitlements are tied to the user ID, not the individual device.

* If two different `appUserIds` redeem codes, **only the most recently identified user will retain access**.
* If the **same `appUserId` is used across multiple devices**, all those devices will **automatically share access** without needing to redeem again.

This system ensures flexibility while protecting against unauthorized sharing of redemption codes.

### How do I associate a web checkout purchase with a user in my app?

The short answer — use Superwall's [user identification APIs](/docs/sdk/quickstart/user-management#identified-users). When you configure Superwall, or a user signs in or out, you can always associate their login status to Superwall's SDK:

```swift
Superwall.shared.identify(userId: user.id)
```

This will ensure that the user is associated with the web checkout purchase.

### A user paid on the web and can't access their purchase in the app. What should I do?

Direct them to your app's plan management page so they can retrieve their redemption link or manage billing. For example: `http://yourapp.superwall.app/manage`

### Can I sell lifetime or consumable products through Stripe?

Yes. Create a Stripe one-time price, import it into Superwall, and add it to a web paywall. For lifetime access, attach the entitlement the product should unlock. For consumables, usually leave the product without an entitlement and use `CustomerInfo.nonSubscriptions` to credit the user's account after purchase.

Learn more in [Stripe One-Time Purchases](/docs/web-checkout/web-checkout-stripe-one-time-purchases).

### When should I use Redirect mode instead of Redeem mode?

Use **Redirect mode** when you need to:

* Show a custom success or onboarding page after purchase
* Perform additional verification or collect more information before granting access
* Integrate with your own deep linking or authentication infrastructure
* Track conversions in your own analytics before redemption

Use **Redeem mode** (the default) when:

* You want Superwall to handle the entire redemption flow automatically
* You don't need custom post-purchase logic
* You want the simplest integration

Most apps should use Redeem mode. You can always switch between modes in your [Application Settings](/docs/web-checkout/web-checkout-configuring-stripe-keys-and-settings#post-purchase-behavior).

### What data is passed to my redirect URL in Redirect mode?

When using Redirect mode, the following query parameters are automatically appended to your custom URL:

**Standard parameters**:

* `app_user_id` - The user's identifier from your app (if you called `identify`)
* `email` - The user's email address from checkout
* `stripe_subscription_id` - The Stripe subscription ID, or the Stripe Checkout session ID for one-time purchases

**Custom parameters**: Any placement parameters you set when creating the web checkout link will also be included.

**Example redirect**:

```
https://yourapp.com/success?
  app_user_id=user_123&
  email=user@example.com&
  stripe_subscription_id=sub_1234567890&
  campaign_id=summer_sale
```

You can use this data to verify the purchase, link it to your user account, or perform custom onboarding. Learn more about [post-checkout redirecting](/docs/sdk/guides/web-checkout/post-checkout-redirecting).