TL;DR
- Flow Builder is Paywall Builder leveled up. You keep every paywall element you use today, and you add quizzes, inputs, branching, and any screen before or after the paywall.
- It all sits behind one placement, so onboarding answers reach the paywall, and you build and test the journey as one, with per-screen metrics.
- Your onboarding builder and paywall builder keep working, but new features now ship to flows. If your onboarding is in native code, that is the easiest place to start.
- Flows are in beta and run on iOS SDK v4 and up today, with more platforms coming. Your current onboarding and paywalls keep running everywhere.
- Building and previewing a flow is no-code. The one developer task is the iOS SDK v4 upgrade.
We shipped Flow Builder a while back, and the easiest way to see it is as Paywall Builder leveled up. Build the paywall you would build today. Put a screen in front of it. Add a question, then branch to the next screen based on the answer. What started as a single paywall is now a flow. Your onboarding and your paywall move out of separate places and separate tests into one experience you build and measure end-to-end. Here is what that gets you and how to move when you are ready.
Where Paywall Builder ends
Paywall Builder is a strong single-screen tool. You compose a paywall from Adapty’s elements, set product tags for dynamic pricing, localize it, run an A/B test, and publish without an app release. You run real revenue through it, and it keeps working.
What you can build stays inside one paywall, though. You work with the paywall elements Adapty gives you, with no survey questions to ask and no branch to send two users down different paths. It covers that one screen, and nothing before it. A user only gets to the paywall after opening the app and moving through your onboarding. Whatever the onboarding setup is, or left out, is already in place, and by the time the paywall loads, the user has mostly decided.
What does a flow add beyond the paywall?
A flow is the advanced tier of the same builder. You keep every paywall element you already use, and you gain the screens and logic that turn a lone paywall into a guided journey: onboarding, a quiz, surveys, loaders, the paywall, a confirmation screen, all behind one placement and connected by logic you set in the editor. The Adapty SDK renders the whole thing natively, no web views.
That extra room is where the work gets interesting. A few things a single paywall can never do:
- Carry what the user tells you forward. A quiz answer on an early screen sets the paywall headline later, so someone who picks “lossless audio” sees “Your Hi-Res upgrade is ready” at the offer.
- Send different users down different paths. The flow branches on the answer, so “new to this” gets a few explainer screens while “returning” jumps straight to the paywall.
- React screen by screen. Inputs and quizzes capture goals or experience level, and the screens that follow adapt to them.
- Put the proof where it counts. Review cards and a countdown timer sit in the moment right before the ask.
- Reshape the whole onboarding without a release. Progress bars and loaders are yours to edit and reorder from the dashboard.
Same elements you trust, with much more room to build around them.
Side by side, capability by capability:
| Capability | Paywall Builder | Flow Builder |
|---|---|---|
| Scope | One paywall screen | Multi-screen flow: onboarding, paywall, and any screen in between |
| Screens behind one placement | One | As many as the journey needs |
| Rendering | Native | Native, no web views |
| Availability | All Adapty SDKs | iOS SDK v4+ today (beta), more coming |
| Elements | Text, media, products, carousels, cards, footers | All of those, plus quizzes, inputs, toggles, tabs, reviews, timers, progress bars, and loaders |
| Branching and conditional navigation | None | Yes, on user answers |
| Conditional logic and visibility | None | IF/THEN, AND/OR, show or hide |
| Variables in text | Product and pricing tags | Product tags plus quiz and input answers |
| In-screen personalization | Static content | Dynamic text from flow variables |
| A/B testing | Paywall-level, cross-placement | Flow-level, across flow variants |
| Analytics | Paywall metrics | Per-screen flow funnel |
| Localization | Yes | Yes, manual or AI |
| Offline fallback | Fallback paywall | Fallback flow |
| Updates without app release | Yes | Yes |
Everything in the left column still works. The right column is what the journey adds.
What about your current onboarding and paywall?
They keep working, and Adapty keeps supporting them. New features now ship to flows rather than the standalone builders, so flows are where the product goes from here.
If you built your own onboarding in native code, start there. You move those screens out of code and into the dashboard, then change or test them without shipping a release. You run onboarding and paywall as one flow. Add a fallback flow for offline.
Will my existing paywalls still work?
Yes. There is no rush, so move when it fits your release schedule.
There is no automatic conversion. A placement serves one content type, and you cannot turn an existing paywall or onboarding placement into a flow placement. You recreate the experience as a flow on a new placement with its own unique ID, then upgrade to iOS SDK v4 to serve it.
Why test the journey instead of two halves?
A paywall test tells you which paywall converts the users who reach it. An onboarding test tells you who reaches it. Neither answers the question that moves revenue: Does a different onboarding make a different paywall win?
Flow-level testing gets you closer. Build two flow variants on a flow placement, one with a richer onboarding feeding a goal-specific paywall, one leaner, and run a regular A/B test across them. Per-screen flow metrics point to the step where your users drop.
One honest limit: comparing a new flow against your old standalone paywall is a cohort comparison across two placement types, not a single A/B test, since cross-placement A/B tests are paywall-only today. Read the flow placement and the old paywall placement as separate cohorts, and expect the flow’s share to grow as users update.
The bottom line
Paywall Builder builds and tests your paywall. A flow is that paywall plus the screens before and after it: onboarding ahead, confirmation behind, all behind one placement, so you shape and measure the journey your users take, and your paywalls keep running while you move at your own pace.
Take the onboarding and paywall you already run, recreate them as one flow, and test the journey your users take.
