RevenueCat Paywalls (free) vs paywall code in your repo: how to choose

First, the honest part: RevenueCat Paywalls is free under $2,500 monthly tracked revenue (then 1% of what you track), and for a lot of apps it is simply the right answer. Remote paywall changes without app releases, curated templates, an AI editor that generates a paywall from a description, multipage flows, A/B experiments, analytics integrations — at zero cost up to the threshold. If that solves your problem, use it and ship. We sell a paywall module ourselves and we're telling you this up front, because a comparison page that pretends the free option doesn't exist is marketing, not a decision tree.

So the real question is: which kind of paywall owner are you?

What dashboard paywalls give you

• Speed and iteration without releases. Change copy, layout, pricing experiments from the RevenueCat dashboard; no App Store review cycle.
• Proven templates and an AI editor. Start from curated layouts or describe what you want.
• Experiments and analytics wired in. A/B testing and conversion reporting without additional instrumentation.

What dashboard paywalls cost you (the constraints)

These are facts from RevenueCat's own docs, not opinions:

• SDK floors: react-native-purchases ≥ 8.11.3 for single-page paywalls, ≥ 10.6.0 for multipage; iOS 15+ / Android 7+; no watchOS, tvOS, or visionOS.
• The paywall lives in their component system. Paywalls are composed in the dashboard and rendered by their native UI SDK. Custom layouts are constrained to their template components. Your paywall is — structurally — a document in their system, not code in your repo.
• Setup is still multi-step. Store products, entitlements, offerings, and sandbox testing don't go away; the dashboard saves you the client UI, not the store plumbing.

Adjacent vendors confirm the pattern: Adapty is free under $5k/mo tracked revenue (then 1%, 30,000+ apps); Superwall is free to $10k MAR (then 1%, Startup $49/mo, 10,000+ apps, with a React Native runtime). All three monetize tracked revenue at scale — none of them sell you the code.

What code-in-your-repo gives you

• The paywall is yours. Files in src/, reviewed in your PRs, versioned in your git history, vendored forever. No dashboard dependency for layout, no vendor component constraints, no "what happens to my paywall if I leave."
• A typed, validated config instead of a remote document. One config file, validated at app startup by a strict zod schema — a bad value names its field and fails at launch, not in production silence.
• Integration into your app's own state. An entitlement hook (useEntitlement(id) → { active, loading, refresh }) gating your features directly, and analytics events you route anywhere.
• Agent-installability with proof. This is the newer part: if a coding agent installs your paywall, the install can end with a machine-checkable receipt — files present, dependencies installed, tsc --noEmit clean — instead of "looks right." (More on the pattern: agent-installable modules.)

What code-in-your-repo costs you

Honesty cuts both ways: you lose remote iteration. A copy change means an app release. A/B testing means building or buying it yourself (client-side flags, your own analytics). You own the maintenance of the screen. If your paywall copy changes weekly and you experiment aggressively, dashboard tooling exists precisely for you — use it.

The decision tree

1. Under $2.5k MTR and templates are fine? → RevenueCat Paywalls. Done. Ship.
2. Need remote changes / frequent A/B without releases? → RC Paywalls (or Superwall/Adapty — same category, compare their floors and fees yourself).
3. Targeting watchOS/tvOS/visionOS, or below iOS 15 / Android 7? → dashboard paywalls don't cover it; code in your repo does.
4. The paywall must implement a bespoke design system, or live in the repo for review/compliance reasons? → code in your repo.
5. You build via a coding agent and want the install machine-verified? → code in your repo, with an install that ends in a verify receipt.

Both branches still need the same store-side work — products, entitlements, disclosures, the rejection checklist. And the branches can mix: RevenueCat's SDK handles purchases and entitlements in both worlds; the question is only who owns the paywall UI — their dashboard, or your repo.

If you land on branch 3–5 and use React Native: the inno9 paywall module is exactly that branch — six TypeScript files in src/paywall/, RevenueCat-wired, with the verify receipt at the end. $79 one-time, code lives in your repo (details). The full from-zero path is in the React Native paywall guide.

FAQ