How to add an onboarding flow to an app without losing people on screen two.
You add an onboarding flow to an app with three pieces: a stored flag, a short run of screens, and a skip control on every one of them. The flag records whether this person has seen the flow, and the screens appear only while it is false. That is the entire build, and it is an afternoon of work. The hard part is deciding how few screens you can get away with. Each one is another moment a brand new user can close the app and never open it again.
Before you draw a single slide, check the flow is doing a job the interface cannot do on its own. A lot of app onboarding screens exist because the first real screen was confusing, and fixing that screen is cheaper and permanent; app design basics covers that side of it. This page covers how many screens to build, where permission prompts belong, how to store the flag, and what to measure once the thing is live.
See what one more screen costsThe short version
Show the fewest screens that earn their place.
A first run experience on a mobile app is worth building when your app asks people to do something unfamiliar, needs a permission before it is useful, or looks empty until data goes in. If none of those is true for your app, the honest answer is to ship without one and spend the time on the first screen instead.
When you do build one, the test is per screen rather than per flow: a screen stays only if a new user does something worse without it. Everything else is a slide you are asking a stranger to tap past before they have any reason to trust you.
Four decisions before you draw a screen
Decision one is the trigger. Almost every flow runs on first launch, which means you are explaining an app to somebody who has seen none of it yet. The alternative is to trigger a short walkthrough the first time a user opens a particular feature. It explains less, but it explains at the moment the explanation makes sense, and it never delays the app for people who do not need it.
Decision two is the count. Three to five walkthrough screens is the usual shape and the usual mistake. Two beats four whenever two will do. Decision three is the escape hatch. Put a visible Skip on every screen, not a small grey word in a corner. A flow people cannot leave is a flow they leave the whole app to escape.
Decision four is what the last screen does. A carousel that ends on a Done button drops the user into an empty app and wastes everything you just told them. Ending on the first real action instead, a sample item loaded or a first entry created, is the difference between an explanation and a start.
None of these has an answer you can look up, because the cost of a screen depends on who installed your app and why. The slider below has no benchmark built into it, on purpose. Put your own drop rate in once you have measured one.
Try it
What one more screen costs you
There is no benchmark built into this. Put in the drop you measured in your own app and the shape of the trade does the rest.
72 of every 100 reach the app
The other 28 installed it, opened it and left before using anything. Fire an event per screen shown and one on finish, then replace the slider with your real number.
Permission prompts do not belong in a walkthrough
The most common reason a first run experience exists is to ask for notifications, location or camera access up front. It is also the most common way one backfires. Android's own guidance is to request a permission in context, when the user starts to interact with the feature that needs it. It also says to leave a way out of any screen you use to explain the reason first.
There is a hard mechanic underneath the advice. Android flags a permission the user has denied twice as permanently denied, and later requests from your app will not raise a dialog at all. On iOS the behaviour is stricter still for notifications. Apple's documentation says the system prompts the person on the first authorization request and records the answer, and that later requests do not prompt at all. A prompt spent on screen two of a carousel, before anyone knows what your app does, is a prompt you never get back.
So the pattern that survives contact with users is two steps. Your own screen, inside your own interface, saying what the feature does and what it needs, with a clear way to decline. Then the system prompt, raised only for people who said yes to yours. Google's documentation is also specific about the aftermath. Do not link somebody to system settings to argue them out of a decision, and degrade the feature gracefully so the app still works without it.
Storing the flag, and what wipes it
The flag is the only piece of state the flow needs. In a React Native app it normally lives in device storage, and it belongs to the install. Delete the app, reinstall it, and your walkthrough screens run again. That is usually harmless. It stops being harmless when the flow ends in a sign-up form, because a returning user who reinstalls now has to log in before they can look at anything.
Which raises the question of whether onboarding should end in an account at all. Apple's App Store Review Guidelines are direct about this. An app without significant account-based features has to let people use it without a login. An app may not require personal information to function unless that information is directly relevant to the core functionality or required by law. A sign-up wall in front of a notes app is not a design choice, it is a rejection risk.
If your app genuinely does need accounts, treat the flow and the login as two problems and build them in that order. Let the user see the app first, then add user login at the point where an account buys them something specific, like syncing across their phone and tablet. Keep the seen flag on the device and the real preferences on the account, so a reinstall skips the slides without losing anyone's setup.
Apple, App Store Review Guidelines 5.1.1 data collection and storage
Measure the drop instead of borrowing one
There is no completion rate worth copying. Published onboarding figures come from other people's apps, other audiences and other definitions of finished. The trade between flow length and drop off is real, but its size is specific to your app. So instrument it before you argue about it.
Four events cover it: flow started, screen N shown, skipped at screen N, and flow finished. Fire an event for the first real action afterwards too, because a flow everybody completes and nobody acts on is worse than one people skip. That wiring is a short job if you set up mobile app analytics before launch, and a retrofit if you do not.
Then read the funnel screen by screen rather than as one number. A single screen losing a large share of its viewers is a specific problem with a specific fix, usually a permission ask or a sign-up form in the wrong place. A flat, even decline across all of them means the flow is too long, and the fix is to delete a screen and measure again.
Keep the figure next to your install numbers rather than on its own, because the two move together. A flow that holds most of a badly targeted audience is not beating one that holds half of a well targeted audience. That is why what happens after install shapes this number more than the screens do.
Which onboarding pattern fits your app
| Pattern | Screens before use | Explains a permission well | Ends in a real action | Main cost |
|---|---|---|---|---|
| No onboarding at all | 0 | No | nothing to end | New users never find the one feature that matters |
| One value screen | 1 | only if you add it | No | Almost nothing, as long as it is skippable |
| Walkthrough carousel | 3 to 5 | usually badly | No | Every slide is another place to leave |
| Guided first action | 0, it happens in the app | Yes | Yes | More build work than any slide deck |
| Sign-up wall first | a form | No | No | The steepest drop, plus a review risk |
Building the flow without hand writing every screen
A first run flow is a small amount of code wrapped in a large amount of fiddling. A pager, copy for each screen, a dot indicator, a skip control, a stored flag, then all of it again after you cut a screen. It eats an evening, then eats a second one when you change your mind about the order.
Newly is an AI app builder. You describe the app in plain English, including the flow you want people to see first. It writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month with no free plan, and iOS builds need your own Apple Developer account. The code stays yours: two-way GitHub sync from the Deploy tab, or a ZIP from Settings.
That matters more here than it sounds. Onboarding is the part of an app you rewrite most often, because you only learn what to say after strangers have used it. Being able to regenerate three screens, ship a build and read the funnel again in the same afternoon is worth more than getting the first version right.
Questions people ask about app onboarding
As few as earn their place. Three to five is the common shape, but the test is per screen: does a new user do something worse without it? If not, cut it. Two good screens beat five padded ones, and every screen you add is another point where somebody leaves before using the app at all.
Describe the first thirty seconds of your app
Write down what a new user has to understand before your app is useful to them, then build the flow around exactly that and cut the rest.
Start building