# 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

# Tips

Practical advice for building effective flows.

Want to watch some of these tips in action? Check out this video:

[Watch on YouTube](https://youtu.be/lkIxyC6tQwo)

### Setting custom user attributes

Setting custom user attributes inside a flow is one of the most useful techniques available. Any tap behavior can set a user attribute, which means buttons, multiple choice selections, and other interactive elements can all tag users with data as they move through the flow.

Once a user attribute is set, you can use it in a few different ways:

* **Within the same flow.** Personalize a later screen with the value (e.g., "Awesome John, welcome to the app!"), route to a different page via branching, or change which products and offers to show.
* **In your app.** Use the [SuperwallDelegate](/docs/sdk/guides/using-superwall-delegate) to send it straight to your analytics provider, create user cohorts, or handle it however you need.

For example, a "Next" button can do more than navigate to the next page. It could, for example, also read from a multiple choice selection, and set its selection to a custom user attribute. By using the tap behavior of "Set Attribute", the value will be set to the user:

![](https://json-ld-superwall-docs-staging.staffbar.workers.dev/docs/images/flows_ca.jpg)

In addition, your app can handle the attribute using the delegate:

```swift
extension MySuperwallDelegate: SuperwallDelegate {
    func userAttributesDidChange(newAttributes: [String : Any]) {
        // The attribute set in the flow is sent here
    }
}
```

This works for any data you collect in a flow, not just multiple choice. Text input values, quiz responses, demographic selections, and preferences can all be stored as attributes and forwarded to your analytics, CRM, or backend.

### After purchase behavior

By default, when a user makes a purchase, the paywall or flow will close. But in Flows, you might want to continue. For example, you could show a thank-you message or collect feedback.

To set something like this up:

1. Select the purchase action on your button.
2. Look for the **After purchase** section.
3. Add one or more actions:
   * **Close:** Dismisses the flow (the default).
   * **Navigate Page:** Advances to the next page in the flow. This is the most common choice for flows where the purchase happens mid-journey.
   * **Open URL:** Opens a link after purchase.
   * **Custom Action:** Triggers a custom action in your app.
   * **Custom Placement:** Registers a placement after purchase.
   * **Set Attribute:** Sets a user attribute when the purchase completes.
   * **Set State:** Updates a state variable.

![](https://json-ld-superwall-docs-staging.staffbar.workers.dev/docs/images/flows_tips_post_purchase.jpg)

The **Navigate Page** option is particularly useful in flows. Instead of closing after purchase, the user moves to the next connected page. This opens up use cases like:

* Showing a personalized welcome or thank-you message.
* Collecting feedback about why they subscribed.
* Presenting an upsell for an add-on product.
* Guiding users through initial setup.
* Placing a paywall in the middle of a flow and continuing the journey after conversion.

Purchase actions also include an **On Abandon** section. Use it when users should take a different path if they open the purchase sheet and cancel before completing the transaction. For example, you can close the Flow, navigate to a recovery page, set a state variable, or register a custom placement.

For the full option list and SDK requirements, see [Purchase outcome actions](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-styling-elements#purchase-outcome-actions).

### Simulate permission prompts

Using the permissions tap behavior, you can test Flows without having to run it on device. The canvas view will allow you to mock either response when you interact with a component with the permission behavior:

![](https://json-ld-superwall-docs-staging.staffbar.workers.dev/docs/images/flows_tips_mock_perms.jpg)

### Use indicators for longer flows

If your flow has more than 3-4 pages, add an Indicator element. Users are more likely to complete a flow when they can see:

* How far they've come.
* How much is left.

Progress visibility reduces abandonment, especially in onboarding flows where users might otherwise wonder "how much longer is this?"

### Keep flows focused

Flows work best when they have a clear, single purpose:

* **Onboarding:** Gathering preferences and introducing the app.
* **Cancellation:** Understanding why users are leaving and offering alternatives.
* **Upsell:** Guiding users to a higher tier or add-on.

If a flow is getting too long or trying to do too many things, consider splitting it into multiple flows. A focused 5-page flow is better than a sprawling 15-page one. When building a new flow, build linear first so all your pages are created and connected in a straight line, then test the basics to make sure navigation works and content looks right, and finally add branching once the foundation is solid. It's much easier to debug a simple flow than a complex one, so get the basics working before adding sophistication.