RevenueCat vs Superwall: billing infrastructure or paywall layer?
Neutral stack explainer comparing RevenueCat (billing/entitlements) vs Superwall (paywall surfaces). When teams use both, and where Rheo fits for journey experimentation.
Mobile subscription stacks split into layers faster than most roadmaps admit. RevenueCat and Superwall both show up in the same RFPs, Slack threads, and "what should we buy?" conversations. They are not interchangeable. RevenueCat is billing infrastructure. Superwall is paywall presentation. Many successful apps run both, plus a fourth layer for journey experimentation.
This post compares the two products neutrally, explains when teams adopt each (or both), and clarifies where Rheo fits without pretending to replace either billing or paywall tooling.
The four-layer mental model
Before comparing vendors, align on layers. Confusion usually means two teams are solving different problems with the same budget line.
┌─────────────────────────────────────────────┐
│ Journey (onboarding, branches, lifecycle) │ ← Rheo
├─────────────────────────────────────────────┤
│ Paywall presentation & paywall A/B │ ← Superwall, RC Paywalls, Adapty
├─────────────────────────────────────────────┤
│ Billing, entitlements, receipts │ ← RevenueCat, StoreKit, Play Billing
├─────────────────────────────────────────────┤
│ App binary + store distribution │ ← Your app
└─────────────────────────────────────────────┘RevenueCat lives in the billing row. Superwall lives in the paywall row. Rheo lives in the journey row. None of these rows fully substitutes for another.
For a fuller stack map, see /blog/flow-platform-subscription-stack.
What RevenueCat is built for
RevenueCat is the system of record for in-app purchases and subscriptions on iOS and Android. Core responsibilities:
| Capability | RevenueCat role |
|---|---|
| Products and offerings | Dashboard + SDK mapping to App Store / Play products |
| Entitlements | "Is this user premium?" answered server-side |
| Receipt validation | Cross-platform subscription state |
| Charts and metrics | MRR, churn, trials, cohort views |
| Webhooks | Server events for your backend |
| Paywalls (optional) | RC Paywalls product for template-based presentation |
| Experiments (optional) | A/B tests on offerings and paywall templates |
Buyer profile: engineering and finance who need reliable billing without maintaining StoreKit edge cases in-house.
Strengths: mature cross-platform SDK, developer trust, integrations ecosystem, clear entitlement APIs.
Typical limitation for growth teams: RevenueCat optimizes subscription state and paywall product tests. It does not own a visual editor for a ten-screen onboarding story, ATT branches, or cancel/win-back flows. RevenueCat Experiments targets paywall and offering hypotheses, not full journey graphs. See /blog/revenuecat-experiments-vs-flow-level-testing for when RC Experiments is the right tool.
What Superwall is built for
Superwall focuses on paywall surfaces: templates, triggers, presentation rules, and paywall-centric experimentation. It assumes billing exists elsewhere (often RevenueCat).
| Capability | Superwall role |
|---|---|
| Paywall UI | Templates, native and hybrid presentation |
| Triggers | When to show a paywall (events, placements) |
| Paywall A/B | Variant tests on paywall creative and layout |
| Analytics | Paywall impressions, conversions, holdouts |
| Remote paywall updates | Change paywall without app store release (within policy) |
Buyer profile: growth and product teams whose primary bottleneck is "which paywall design converts?"
Strengths: fast paywall iteration, growth-friendly dashboard, experimentation framed around paywall outcomes.
Typical limitation: Superwall does not replace billing SDK configuration, entitlement checks in your app shell, or multi-step onboarding before the paywall appears. It is not a full lifecycle flow platform for cancel surveys, win-backs, or permission education sequences.
Head-to-head comparison
| Dimension | RevenueCat | Superwall |
|---|---|---|
| Primary job | Billing and entitlements | Paywall presentation |
| Can work standalone? | Yes (many apps use RC only) | No (needs billing underneath) |
| Paywall UI | RC Paywalls (optional product) | Core product |
| Paywall A/B | RevenueCat Experiments | Core product |
| Entitlement source of truth | Yes | No |
| Receipt validation | Yes | No |
| Onboarding flow editor | No | Limited / not core focus |
| Webhooks for subscription state | Yes | Depends on billing integration |
| Best first purchase for | Any app taking money in-app | Teams optimizing paywall creative at scale |
Keyword takeaway for "revenuecat vs superwall": compare billing infrastructure vs paywall layer, not two products solving the same job.
When teams use RevenueCat only
Common pattern for indie and early-stage apps:
- RevenueCat handles products, offerings, and entitlements
- RC Paywalls or a simple native paywall covers presentation
- Onboarding is hardcoded in the app repo
- Experiments wait on releases or use RC Experiments on the paywall
This works until onboarding iteration becomes the bottleneck. At that point teams add a journey layer (Rheo) or a paywall specialist (Superwall), depending on where drop-off actually lives.
Integration guide: /blog/how-to-use-rheo-with-revenuecat.
When teams use RevenueCat + Superwall
A popular growth-stage stack:
- RevenueCat validates purchases and owns entitlements
- Superwall presents paywalls and runs paywall A/B tests
- Superwall triggers fire on events; RC confirms subscription outcomes
Why both: RevenueCat is the billing source of truth engineers trust. Superwall is the paywall experimentation surface growth wants to edit without shipping binaries.
Integration note: Superwall documentation describes pairing with RevenueCat for purchase handling. Your app still calls Purchases.configure at launch. Superwall presents; RevenueCat records.
What this stack still lacks: orchestration of the path into the paywall. If screen two of onboarding kills 40% of users, neither RC nor Superwall alone redesigns that sequence OTA with step-level analytics.
When teams use RevenueCat + Rheo (no Superwall)
Another common pattern:
- RevenueCat for billing and optionally RC Paywalls / RC Experiments
- Rheo for onboarding, paywall placement in the journey, and lifecycle flows
- Rheo triggers RevenueCat paywall presentation at a flow step via integration
Rheo does not manage, design, or optimize paywalls. External integrations (RevenueCat, Superwall, etc.) own paywall UI and billing. Rheo orchestrates native journeys and shows experiment impact on paywall steps via integration.
In this model, Superwall is optional. Teams that are satisfied with RC Paywalls may never add Superwall. Teams that want Superwall's paywall editor can insert a Superwall step the same way Rheo inserts a RevenueCat paywall node: as an external surface in the flow graph.
Where Rheo fits (the fourth layer)
Rheo answers questions neither RevenueCat nor Superwall is designed to own:
| Question | Best layer |
|---|---|
| Which offering price wins on the paywall? | RevenueCat Experiments or Superwall |
| Is the user entitled to premium? | RevenueCat |
| Should onboarding be three screens or seven? | Rheo |
| When should we show ATT relative to value props? | Rheo |
| What happens after paywall dismiss? | Rheo (branch edges) |
| Cancel survey and win-back path? | Rheo |
Rheo is journey experimentation: native multi-step flows, branching, channel A/B tests, and step-level funnel analytics. Paywall steps inside a Rheo flow delegate presentation to RevenueCat or Superwall. Rheo records surface_presented and surface_outcome on those steps so you can read journey variant impact on paywall arrival and conversion.
Positioning: fourth layer for journey experimentation, not a replacement for RevenueCat or Superwall.
Decision guide
| Your situation | Start with | Consider adding |
|---|---|---|
| First subscription app, small team | RevenueCat | Rheo when onboarding iteration hurts |
| Paywall is the only growth lever | RevenueCat + Superwall | Rheo if pre-paywall drop-off dominates |
| Onboarding changes weekly | Rheo + RevenueCat | Superwall only if RC Paywalls insufficient |
| Enterprise compliance on billing | RevenueCat (locked) | Superwall or RC Paywalls per growth needs |
| Expo RN app, OTA velocity | Rheo for flows + RC for billing | See Expo policy post for OTA boundaries |
Common mistakes when evaluating vendors
Treating Superwall as billing. It is not. You still need RevenueCat, native StoreKit, or equivalent.
Treating RevenueCat as a full funnel platform. It excels at subscription infrastructure. Full onboarding orchestration is out of scope.
Running paywall and journey experiments on the same users without a design. If Rheo changes who reaches the paywall while Superwall tests template B, readouts confound. Serialize tests or document factorial intent.
Expecting Rheo to replace paywall tools. Rheo integrates with them. Paywall UI and purchase handling stay in RevenueCat, Superwall, or your native implementation.
Ignoring fallback paths. Any paywall node in a journey needs explicit edges for dismiss, failure, and restore. Dead ends after a failed paywall presentation hurt conversion and skew experiment data.
Example stack by company stage
Indie (under 5k MAU)
| Layer | Tool |
|---|---|
| Billing | RevenueCat |
| Paywall | RC Paywalls |
| Journey | Hardcoded → Rheo when needed |
| Paywall A/B | RC Experiments when traffic allows |
Growth (paid UA, 10k+ MAU)
| Layer | Tool |
|---|---|
| Billing | RevenueCat |
| Paywall | Superwall or RC Paywalls |
| Journey | Rheo |
| Paywall A/B | Superwall or RC Experiments |
| Journey A/B | Rheo channels |
Mature (multiple apps, lifecycle focus)
| Layer | Tool |
|---|---|
| Billing | RevenueCat (standardized) |
| Paywall | Superwall per app or RC Paywalls |
| Journey + lifecycle | Rheo (onboarding, cancel, win-back) |
| Analytics | Product analytics + Rheo step funnels + RC revenue |
Summary
RevenueCat vs Superwall is not a winner-take-all choice. RevenueCat is billing and entitlements. Superwall is paywall presentation and paywall-focused tests. Together they cover money and the moment of purchase. Rheo covers the native journey that precedes and follows that moment, integrating with either paywall provider without replacing them.
Map your bottleneck honestly: billing reliability, paywall creative, or journey sequencing. Buy the layer that matches the hypothesis, then add adjacent layers when the next constraint appears.
Start for free and orchestrate onboarding around your existing RevenueCat or Superwall paywall integration.