The SDK side of RevenueCat is the easy part. The hard part is designing a paywall that users actually convert on. I've shipped enough of these to have opinions, and most of them come from watching conversion numbers go up when I removed things, not added them.

This isn't about code. It's about product. What to show, where to show it, and how to tell if it's working.

Show the paywall after the user has felt the product work, not before. The user who hit a limit is the user who's already decided your app is worth using.

The three decisions that matter

Everything else is detail. These three things move the conversion needle:

  1. Where the paywall lives in the flow. Is it the first thing the user sees after sign-up? After they hit a usage limit? Hidden in settings?
  2. What the user is paying for. Clear enough that they can explain it in one sentence.
  3. What they see when they tap the button. One price, or multiple? Monthly or yearly default? Trial or no trial?

Get these three right and the rest is polish. Get them wrong and no amount of copywriting saves you.

Where to put it

My rule: never show the paywall before the user has felt the product work. A paywall on the onboarding screen of a brand new install is a conversion killer unless your app is genuinely well known. The user doesn't know you yet, and they're not going to trust you with a credit card.

Three placements I've seen work in order of increasing aggressiveness:

  • Soft wall — the user hits a limit (5 habits, 10 notes, one export per day) and the paywall appears as the unlock. This has the highest intent because the user has already decided the product is worth using.
  • Feature gate — a specific feature (AI summaries, cloud sync, advanced filters) is marked with a Pro badge and opens the paywall on tap. Good for apps where the free tier is fully usable and Pro is additive.
  • Timed nag — the paywall appears after day 3 or after session 10. Easy to add, easy for users to dismiss. I only use this as a supplement, never as the primary placement.

I avoid hard walls — "pay to use this app at all" — unless I have a very good reason. The conversion rate is much lower than people expect, and you give up every user who would have stayed and converted later.

The thing you're selling

The headline on the paywall should answer "what do I get if I tap this button" in fewer than eight words. Not "Unlock Premium features". Not "Go Pro with advanced tools". Something like:

  • "Unlimited habits"
  • "Export to PDF"
  • "Offline mode, forever"

The more specific, the better it converts. "Premium" doesn't mean anything to anyone. "Unlimited habits" means exactly one thing.

One price or multiple

Default state: show the yearly plan, highlighted, with the monthly as a secondary option. Yearly almost always has better lifetime value per install even though monthly has a higher take rate. RevenueCat gives you the pricing strings already localized, so there's no excuse for showing "4.99" instead of "$4.99" or "€4,99".

If you offer a free trial, make the CTA button say "Start free trial" — the word "free" carries more weight than anything else on the screen. Then show the post-trial price underneath in smaller, muted text. Don't hide it, but don't lead with it.

Running an A/B test

RevenueCat has a feature called Experiments that lets you swap offerings for different groups of users without shipping a new build. You create two offerings in the dashboard, assign them to an experiment, and RevenueCat automatically splits traffic. You check the results in the dashboard after a few hundred installs.

The test I run first on every new app:

  • Offering A: Yearly plan only, no trial
  • Offering B: Yearly plan with 3-day free trial

That comparison tells you whether your product is strong enough to get users past the trial wall, or whether you need to warm them up with a trial first. Most apps I've shipped perform better with the trial. A few don't, and those I can sell the yearly plan outright.

The mistakes I made on my first paywall

A few things I did wrong so you don't have to:

  • Showed all five price options at once. Weekly, monthly, quarterly, yearly, lifetime. Users froze and closed the sheet. Cut it to one default + one alt and conversion went up.
  • Hid the restore button in settings. Got one-starred in reviews, then rejected by Apple. Put it on the paywall, directly beneath the purchase button.
  • Wrote "Premium Features" as the headline. Meaningless phrase. Replaced with the specific feature and conversion doubled.
  • Forgot to localize the strings. My Germany conversion was half my US conversion until I figured out the user was seeing English marketing copy next to a €4,99 price tag. Use the SDK's localized priceString and translate the rest.
  • Gated the entire app instead of a feature. Hard wall on day one. Bounce rate was 90%. Moved to a soft wall on usage limits and conversion improved because users had already become invested.

What to add next

Once the basic paywall is working, these are the next levers in order of impact:

  • Testimonials — a single screenshot of a real user saying the feature is worth it. Doubles conversion on consumer apps in my experience.
  • Feature comparison table — Free vs Pro, side by side. Makes the value clear without a wall of text.
  • Seasonal promos — temporary price drops tied to the app launch or a holiday. RevenueCat's offerings system makes this a dashboard change instead of a code change.
  • Win-back offers — users who cancel get a discounted re-up offer. This is a separate API surface but worth the effort on apps with enough volume.

You don't need any of this on day one. Ship the minimal paywall, get the three decisions right, then iterate.