Designed to be quick, dependable, and seamless in your app experience.

In rebuilding RevenueCat Paywalls, we made a key architectural decision: to render paywalls natively instead of inside a WebView. That didn’t mean hard-coding layouts into the app — paywalls remain fully server-driven and remotely configurable — they simply render using platform UI instead of a browser engine. That choice impacts everything from load performance to accessibility, and from stability to long-term maintainability. Here’s why we made that call, what it delivers for your users, and how it enables your team to ship faster with confidence.

When it comes to conversion, every second counts

Paywalls sit at the tightest point in your revenue funnel. Delays or blank states aren’t just UX issues, they’re conversion leaks:

  • No WebView engine to spin up: A WebView has to initialize a separate rendering process before it can draw anything. Developers routinely see multi-second first-load stalls and even ‘blank’ states on initial launch. Native UI components are already included with the app binary, so rendering begins immediately, no need to wait for WebView to load. 
  • Less platform fragility: Web-based layers are tied to browser engines that update independently of your app, sometimes shifting rendering behaviors in subtle ways. Native screens remove that extra dependency layer, giving you more predictable performance.
  • Accessibility support, out of the box: System features like Dynamic Type, VoiceOver/TalkBack, contrast settings, and UIAccessibility traits are inherited automatically with native components.

What you get: faster first paint and fewer surprises when users reach the point of purchase.

Native “feels native” — and that matters

The closer your paywall matches platform conventions, the less cognitive friction your users feel.

  • Typography and Dynamic Type: Apple’s Human Interface Guidelines (HIG) recommend supporting Dynamic Type so text respects user settings. Native text controls handle this out of the box. In a WebView, you’d need to rebuild that behavior yourself.
  • Gestures, haptics, accessibility, motion: Interactions and animations behave exactly as users expect because they use the same system primitives as the rest of the app. 
  • Platform-consistent on Android: Native paywalls inherit Material styling and motion for free, rather than hand-coding lookalikes in HTML and CSS.

What you get: a paywall that looks and behaves like it belongs — on both iOS and Android — because it does.

RevenuCat Paywalls web UI

Backwards compatibility, built-in

RevenueCat Paywalls are built to remain stable even as your app and our SDK evolve. Every paywall you configure is versioned and stored on our servers, so it renders consistently across supported SDK versions.

  • Stable defaults: If a device is running an older SDK without support for the latest paywall features, RevenueCat automatically serves a default paywall so the purchase flow never breaks
  • Version-aware updates: As you adopt new SDK versions, you can take advantage of the latest components and layout options, knowing older clients will continue to display a reliable fallback
  • Continuous evolution: This approach balances stability and progress, ensuring paywalls created today remain usable — while giving teams the option to adopt new designs and capabilities when ready

What you get: paywalls that are backwards-compatible by default, and forward-compatible when you, and your users, choose to evolve.

Substantiating the choice

Here’s the shorter ‘engineering brief’ behind our decision:

  • Startup time: Removing WebView engine initialization improves first paint and reduces the risk of blank states on first open
  • Operational risk: Avoiding a second rendering engine minimizes unplanned breakages after OS or component updates
  • System integration: Native UI automatically inherits Dynamic Type, accessibility, haptics, and gestures, aligning with HIG and Material guidance without extra plumbing
  • Iteration speed: RevenueCat Paywalls is remotely configurable and experiment-ready — iteration isn’t tied to app releases even though rendering is fully native
  • No JS bridge, no hidden WebView: All purchasing logic stays inside the app process, handled through a PurchaseHandler object — there’s no message-passing across WKWebView or Android System WebView boundaries

The ideal tool for a revenue-critical screen

There’s no single architecture that’s best for every use case. But for a focused, conversion-critical surface like a paywall, the trade-offs break clearly:

  • Native maximizes speed, reliability, and platform fit, where they matter most
  • Remote configuration and experiments keep your iteration loop tight without introducing an embedded browser and its moving parts

For engineers who like to verify

If you’d rather read code than blog posts, you don’t have to take our word for any of this. RevenueCat Paywalls UI libraries are available in GitHub:

That’s why we chose native paywalls, and why our customers can ship faster while giving users a purchase flow that loads instantly, looks right, and works the same tomorrow as it did today.