# 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 # Permission Prompts Request system permissions like notifications, location, and camera at the right moment in your flows. Requesting permissions is a natural part of many flows, especially onboarding. Rather than prompting for notifications or location access at a random moment, you can ask at the right point in a flow after the user understands the value. Permission prompts are not a standalone element. They are a [tap behavior](/docs/dashboard/dashboard-creating-paywalls/paywall-editor-styling-elements#tap-behaviors) called **Request Permission** that you attach to a button or other tappable component. When the user taps it, the system permission dialog appears. ![A permission prompt configured as a tap behavior](https://2a2314a4-superwall-docs.staffbar.workers.dev/docs/images/flows_perm_prompt_example.jpg) ## Available permissions * **Notification:** Ask for permission to send system notifications. * **Background Location:** Request location access when the app isn't in use. * **Location:** Request location access while the app is in use. * **Read Images:** Access the user's photo library/camera roll. * **Contacts:** Access the user's contacts. * **Camera:** Access the device camera. * **App Tracking Transparency:** Ask to track the user across apps and websites. * **Microphone:** Access the device microphone. > **Note:** Permission prompts require iOS SDK 4.12.5+. ## If Granted / If Denied You can add follow-up actions that run depending on the user's response. Use the **If Granted** section to add actions that run when the user allows the permission, and **If Denied** for when they decline. For example, you could navigate to the next page on grant, or show a different page explaining why the permission matters on deny. ## Testing permissions in the editor You can test permission prompts directly in the editor preview without deploying to a device. When a permission request fires, the editor shows a simulation toast with **Grant** and **Deny** buttons. Clicking either one triggers the corresponding **If Granted** or **If Denied** follow-up actions, so you can verify your entire permission flow works before shipping. ![](https://2a2314a4-superwall-docs.staffbar.workers.dev/docs/images/flows_tips_mock_perms.jpg) ## Testing callbacks in the editor Custom Callback actions can also be tested in the editor. When a callback fires, the editor shows a simulation toast with **Success** and **Failure** buttons. If the callback is configured as **Blocking**, the action chain pauses until you click one. If it's **Non-blocking**, the chain continues immediately and you can click whenever you're ready. This lets you test both paths of your callback logic without writing any SDK code. ![](https://2a2314a4-superwall-docs.staffbar.workers.dev/docs/images/flows_mock_callback.jpg) ## Best practices * Request permissions **after** providing value. Users are more likely to accept. * Explain the benefit clearly (e.g., "Get notified about exclusive deals"). * Consider placing permission prompts after a purchase or key engagement moment. For more guidance on iOS, view Apple's Human Interface Guidelines [here](https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission).