# 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 # 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://2a2314a4-superwall-docs.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://2a2314a4-superwall-docs.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://2a2314a4-superwall-docs.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).