# 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

# Are Paywall Events and Urgency Messaging App Store Compliant?

Learn about Apple App Store compliance for paywall events like Paywall Dismissed and Transaction Abandoned, as well as urgency-style messaging.

This guide covers common App Store compliance questions about paywall interaction tracking and urgency-based messaging.

## Paywall Events Compliance

**Paywall Dismissed** and **Transaction Abandoned** events are compliant with Apple App Store guidelines. Tracking paywall interactions and purchase flow analytics is standard practice across the industry.

### Follow-up Flows

Re-engagement flows triggered by these events are also compliant, such as:

* Showing a different paywall with a discount after a transaction is abandoned
* Presenting alternative offers when a paywall is dismissed
* Push notifications to users who showed purchase intent

> **Note:** Push notification follow-ups require that users have opted into notifications. Always respect user notification preferences.

## Urgency Messaging Compliance

Apple does not explicitly ban urgency-style messaging on paywalls. Phrases like:

* "One-time offer"
* "You'll never see this again"
* "Limited time discount"

These are permitted, but with one key rule: **the offer must be genuine**.

### What to Avoid

Apple prohibits deceptive practices under their bait-and-switch guidelines. If your "one-time offer" keeps reappearing to the same user, Apple may flag this as deceptive marketing.

> **Warning:** If you advertise an offer as exclusive or time-limited, ensure it actually is. Showing the same "one-time offer" repeatedly to users who declined it previously could result in App Store rejection or removal.

### Best Practices

1. **Be honest** - If an offer truly won't return, you can say so
2. **Use genuine scarcity** - Time-limited offers should have real deadlines
3. **Track offer history** - Use user attributes to avoid showing "one-time" offers repeatedly
4. **Document your logic** - Be prepared to explain your offer strategy if Apple requests clarification

## Resources

For the complete App Store Review Guidelines, visit:

* [Apple App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)