# 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

# Handling Deep Links

Handle Superwall deep links for paywall previews and web checkout redemption.

> **Warning:** **Beta**The KMP SDK is in beta and its API may change between releases.

Superwall uses deep links for two things: previewing paywalls on a real device, and redeeming web checkout codes. Both flow through one call.

## Pass the URL to Superwall

```kotlin
val handled = Superwall.handleDeepLink(url)
```

It returns whether the SDK recognized and handled the link, so you can fall through to your own routing when it did not:

```kotlin
fun onDeepLink(url: String) {
    if (Superwall.handleDeepLink(url)) return
    myRouter.navigate(url)
}
```

> **Note:** `handleDeepLink` is **guard-exempt**, so you can call it before `Superwall.configure` without hitting `SuperwallError.NotConfigured`. That is deliberate: cold-starting from a deep link is its primary use, and it would be useless if you had to sequence it behind configuration.It takes a `String`, not a platform URL type, so it is callable from `commonMain`.

## Wiring it up per platform

The SDK takes a plain `String`, so the only platform-specific part is getting the URL from the OS to your shared code.

**Android**, from the activity that receives the intent:

```kotlin
// androidMain
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    intent?.data?.let { Superwall.handleDeepLink(it.toString()) }
}

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    intent.data?.let { Superwall.handleDeepLink(it.toString()) }
}
```

Declare your intent filter in `AndroidManifest.xml` as you would for any deep link.

**iOS**, from your `App` or `AppDelegate`:

```swift
// SwiftUI
.onOpenURL { url in
    Superwall.shared.handleDeepLink(url: url.absoluteString)
}
```

> **Note:** Register your URL scheme with the OS as usual: an `intent-filter` on Android, a URL type in your
> Xcode target on iOS. Superwall does not do that part for you.

## Web checkout redemption

When a user buys on the web and returns to your app, the redemption arrives as a deep link. Observe the outcome through the delegate:

```kotlin
import com.superwall.sdk.kmp.models.redemption.RedemptionResult

class MyDelegate : SuperwallDelegate {
    override fun willRedeemLink() {
        showSpinner()
    }

    override fun didRedeemLink(result: RedemptionResult) {
        hideSpinner()
        when (result) {
            is RedemptionResult.Success -> unlock(result.redemptionInfo)
            is RedemptionResult.Error -> showError(result.error)
            is RedemptionResult.ExpiredCode -> showExpired(result.info)
            is RedemptionResult.InvalidCode -> showInvalid()
            is RedemptionResult.ExpiredSubscription -> showExpiredSubscription()
        }
    }
}
```

Every case carries the `code` that was redeemed.

> **Warning:** `willRedeemLink` and `didRedeemLink` are analytics hooks: they arrive on a **background thread on Android**. The spinner calls above need a main-thread hop on Android. See [Platform differences](/docs/kmp/guides/platform-differences#delegate-threading).

## Superwall app links

`SuperwallDelegate.handleSuperwallDeepLink` reports links of the form `yoursubdomain.superwall.app/app-link/...`, broken into path components and query parameters:

```kotlin
override fun handleSuperwallDeepLink(
    fullURL: String,
    pathComponents: List<String>,
    queryParameters: Map<String, String>,
) {
    // Route based on pathComponents
}
```

> **Warning:** **This hook is iOS only.** `superwall-android` has no equivalent delegate method, so it is never invoked on Android.`Superwall.handleDeepLink(url)` itself works on **both** platforms. Only this structured callback is missing. On Android, parse the URL yourself in the activity that receives it.

## Paywall previews

Deep links are also how you preview a paywall on a real device from the dashboard. Point the link at your app and pass it to `handleDeepLink`.

> **Note:** On **Android**, previews need the SDK's debug activities declared in your own manifest. The KMP library declares the paywall activity but not the debug ones. See [Platform differences](/docs/kmp/guides/platform-differences#in-app-paywall-previews-on-android) for the snippet. This path is not yet verified end-to-end on KMP.