RevenueCat paywall best practices: layouts, alerts and win-back emails

You added RevenueCat, picked a paywall template, shipped, and now the dashboard shows a trickle of trials and a lot of "cancelled". The question is what to change first: the design, the price, the trial, or something else.

RevenueCat's own blog covers paywall design well, and you should read it. What it does not give you is the view from small developers with a few hundred installs a week, where every lost trial matters. This guide pulls together what those developers on r/AppBusiness and r/iosdev reported in 2026, plus the exact setup for the one habit that moved their numbers most: getting told about every cancelled trial the moment it happens.

Two terms first. A paywall is the screen that asks for payment. Trial to paid is the share of free trials that turn into a paid subscription. RevenueCat counts both from real store transactions.

What are the RevenueCat paywall best practices that actually work?

Show a preview of the paid feature, lead with one plan, place the paywall right after the user sees value, and measure correctly before you test anything. Then close the loop on cancellations with Slack alerts and same-day emails.

Here is the short version, with the evidence behind each line:

None of these are guarantees. They are what worked for specific apps, and several commenters pointed out that a price change can hide inside any "the paywall fixed it" story.

What should a high-converting paywall layout look like?

Put the locked feature itself at the top, one highlighted plan below it, and a single button. Everything else is secondary.

1. Show the thing, lock the depth

The most repeated lesson in the threads is that blur loses. One founder's first paywall blurred every result and "barely converted". Switching to a version that showed how many critical issues were found, with the findings locked, tripled conversion. A fitness developer does the same: every Pro feature gates with a preview of itself, the user's real muscle map with the breakdown blurred.

The reason is simple: the user now knows the paid version has something specific for them.

2. One hero plan, one alternative

Show the yearly plan selected by default, with its monthly equivalent in large type, and one other plan (monthly or weekly) beside it. Three or four plans in a grid makes people stop and compare instead of tapping.

3. Honest, clear terms

Apple requires the price, the billing period and what happens after a trial to be clear. A short line like "7 days free, then $39.99 per year. Cancel anytime in Settings" covers it and builds trust. Hiding it invites refunds and rejection.

4. One button, a visible close

Hard paywalls work for many apps (see our hard paywall vs freemium comparison), but a hidden close button annoys reviewers and users. One commenter flagged a paywall that could not be dismissed on desktop as the first thing they noticed.

Tip: RevenueCat Paywalls let you change layout and copy remotely without an app update, so you can run these tests without waiting on review.

Where should the paywall appear in your app?

Right after onboarding, once the user has seen a result, and again at each locked feature. Placement often matters more than design.

One TikTok-driven app shared its funnel: about 47% of users finished onboarding, about 90% of those saw the paywall, and 10 to 11% of paywall viewers bought, for roughly 5% install to purchase. The biggest leak was onboarding, not the paywall. If half your users never reach the paywall, no layout tweak can fix that.

A practical order:

1. Short onboarding (3 to 5 screens) that ends with a personal result.
2. Paywall immediately after that result.
3. Contextual paywall each time a free user taps a Pro feature, showing that feature's preview.
4. Never a paywall before the user has done anything.

How do you send RevenueCat trial cancellations to Slack?

Create a Slack app with an incoming webhook, then paste it into RevenueCat's Slack integration. It takes about ten minutes and posts every purchase, trial start, trial cancellation, renewal and billing issue to a channel.

The steps, from RevenueCat's docs as of November 2026:

1. Go to api.slack.com/apps, click Create New App, name it "RevenueCat" and choose your workspace.
2. Open Incoming Webhooks, switch it on, and click Add New Webhook to Workspace.
3. Pick a channel, for example #revenue, and authorize.
4. In the RevenueCat dashboard, open your project, go to Integrations, choose Slack, and paste the webhook URL.
5. Leave sandbox events off unless you are testing.

RevenueCat's Slack messages include the product and revenue but not customer attributes, so they do not show the user's email. The developer behind the 21% to 44% result went a step further: a custom webhook posts each event with the plan, country and a link to the user in their analytics tool, and flags trial cancellations "reach out".

If you want that richer version, use RevenueCat Webhooks (Pro plan) instead and format the Slack message yourself. Filter on these fields, per the RevenueCat event docs:

type == "CANCELLATION"
period_type == "TRIAL"
cancel_reason == "UNSUBSCRIBE"   # user turned off renewal, not a billing failure

Watch out: a CANCELLATION with cancel_reason BILLING_ERROR is a failed charge, not someone saying no. Do not send those people a "why did you leave" email.

How do you email users who cancel a trial?

Store the user's email in RevenueCat, catch the trial cancellation webhook, and send one short, personal email the same day. RevenueCat's own tutorial uses a Zapier hook for this; a small serverless function works the same way.

Step 1: save the email as an attribute

In the SDK, after the user signs in or gives you their email, call Purchases.shared.attribution.setEmail(email) on iOS (the $email reserved attribute). Without this, the webhook tells you a user ID, not who to write to.

Step 2: catch the webhook

Point a RevenueCat webhook at your endpoint and set an authorization header so random requests are rejected. When the filter above matches, look up the subscriber's $email and send.

Step 3: send a message people answer

The developer who doubled trial to paid said a blunt question beat any survey. Something like:

Subject: Quick question about [App]

Hi, I'm the developer of [App]. I saw you cancelled your trial, which is completely fine. Could you tell me in one line what was missing or what didn't work? I read every reply myself.

[Your first name]

Plain text, from a real person, no discount in the first email. The replies tell you which paywall promise did not match the product, which is the input your next paywall test needs.

Watch out: only email people who agreed to hear from you, include a way to opt out, and follow the email law where your users live. Do not scrape emails from receipts.

Why must you check your numbers against RevenueCat first?

Because your analytics is probably undercounting, and you will optimize against noise. RevenueCat sees real store transactions; your event tracking only sees what your code successfully sent.

The developer above found their analytics logged 10 trial conversions in a window where RevenueCat counted about 48, caused by a wrong API key failing silently and two event bugs. A commenter's advice was to make reconciliation a scheduled job that compares RevenueCat totals to analytics per cohort and fails loudly if they drift.

A related trap: on r/iosdev, a developer panicked that 80% of trials showed as "Expired" due to billing issues. A RevenueCat employee replied that "Expired" just means the trial ended without converting, so check the actual reason before blaming the integration.

What paywall mistakes cost indie developers the most?

Blurring everything, testing on paid traffic, and changing three things at once. Here is what the threads warn about:

• Judging the paywall on ad traffic. One developer saw about 2% conversion from paid installs and about 12% from organic, same paywall. Test on the traffic you will actually have.
• Changing price and layout together. Commenters on the "killed the free trial, doubled the price" thread pointed out you cannot tell which change worked. See free trial vs no trial for a cleaner test.
• Calling a test too early. The 30.1% vs 24.1% result above was, in its author's words, not significant yet. Wait for a few hundred paywall views per variant before deciding.
• Ignoring billing errors. They look like churn but need a different fix (grace periods, reminders), not a new paywall.
• Too many plans. Pick the plan mix deliberately; our weekly vs yearly pricing guide covers the trade-offs.

How do you run a paywall test without fooling yourself?

Change one variable, split traffic evenly, and decide in advance how many views you need. RevenueCat Experiments can split users between two offerings and report revenue per user, which is the number that matters.

A simple four-week plan:

Results vary widely by niche and price. A health app and a utility app can need opposite paywalls, which is why the testing habit matters more than any single layout. The App Store Apps pack has the full pricing and paywall test sequence in order, with the listing and content work that brings traffic to it.

Where to go from here

1. Connect RevenueCat to Slack tonight and watch a week of events.
2. Compare RevenueCat's trial and purchase counts with your analytics and fix the gap.
3. Rebuild the paywall around a preview of the locked feature and one highlighted plan.
4. Start emailing trial cancellers who opted in, and log what they say.
5. Test one change at a time and judge it on revenue per user.

The App Store Apps pack adds the step-by-step lessons, paywall and pricing test templates, and launch checklists for $19, and all 16 Money Printer packs are $39.