RevenueCat paywall offers powerful customization of paywalls that render full native views. However, there might be situations where you want to implement your own custom paywall while still leveraging RevenueCat to manage entitlements, offers and packages. This blog post will guide you through how to effectively run your custom paywall alongside a RevenueCat-powered paywall.
Why run multiple paywalls?
You might be wondering why you’d want to manage multiple paywalls simultaneously. Here are a few scenarios where this approach can be highly beneficial:
- Transition periods: You might have built a custom paywall before and are interested in progressively moving away from it to RevenueCat paywalls.
- A/B testing: You have your existing hard coded paywall, and you’ve now built a new paywall in RevenueCat that you want to test against.
- Targeted offers: For specific user segments, you might have unique pricing or promotional offers that require a highly customized presentations,
- Advanced logic: For complex onboarding flows or specific user journeys
Your app decides which paywall UI to show, but all purchases still flow through the RevenueCat SDK. This avoids duplicated logic, pricing mismatches, and entitlement bugs while giving you full control over presentation when needed.
Example end-to-end flow with
At a high level, an app with two different paywall types functions like this:
- User reaches a paywall decision point
- For example: end of onboarding, feature gate, or promotional entry point
- App requests Offerings for a specific Placement
- The Placement represents where the paywall is shown in the user journey
- RevenueCat returns the appropriate Offering
- The returned Offering may vary per user based on targeting rules
- App inspects Offering metadata
- Metadata determines which paywall should be displayed
- App chooses a paywall UI
- RevenueCat paywall UI
- Or a fully custom built paywall UI
- User selects a product
- Product and pricing data always come from RevenueCat
- Purchase is initiated via the RevenueCat SDK
- Identical purchase flow regardless of paywall UI
- RevenueCat updates entitlements
- App unlocks or restricts content based on CustomerInfo
This keeps presentation flexible while keeping the subscription system centralized and consistent. If you make use of RevenueCat’s Experiment feature, you can even test and compare how the different placements and paywalls perform in conversions.
Understanding RevenueCat Paywalls
RevenueCat’s paywalls are designed to simplify the process of displaying your products to users. As outlined in the RevenueCat Paywalls documentation, they allow you to create, manage, and test different paywall designs directly within the RevenueCat dashboard. They handle the fetching of product information and present it in a user-friendly way. All this without having to create new releases of your app when you make changes to your paywall.
For most new apps, implementing your paywall with RevenueCat is the best choice, allowing you to iterate and update your paywall without having to push new releases of your app to stores.
Implementing a custom built paywall
As mentioned earlier, there are cases when RevenueCat paywalls might not be enough. One such case could for example a key design element in your app that you want to also show in your paywalls. In a gamified app this could be for example a broken streak visualisation, that you want to surface in the paywall to communicate to the customer that subscription would allow them to amend the broken streak.
When you decide to implement a custom built paywall, you’re essentially taking control of the UI/UX. However, you’ll still rely on RevenueCat SDK for the backend operations: fetching product information and making purchases.