If you only take five things from this article: open with the outcome your app delivers, ask questions that visibly change the experience, request permissions in context instead of on launch, place your paywall where motivation peaks, and treat the whole flow as something you rework weekly. Everything below is the reasoning and the order of operations.
Start with the job, not the tour
A new user gives you one first session, and most of their decision happens inside it. They did not download your app to learn your interface. They downloaded it to lose weight, learn Spanish, fix their budget, or kill twenty minutes. Your first screen should name that job in the user's words. Feature tours answer a question nobody asked; the job-first opening answers the only question that matters: am I in the right place?
A useful drill: write the first screen as if it were the answer to the App Store search query that brought the user here. If someone searched "calorie tracker", the first screen should confirm they found one, not introduce your brand values.
Ask questions that change what happens next
Personalization questions are the strongest pattern in modern onboarding, and the most abused. The rule: only ask what you will visibly act on. Ask a goal, then show the plan adapting to it. Ask experience level, then change the starting content. Every answered question raises commitment, but only if the user can see the answer doing something. Questions that vanish into a database read as a survey, and surveys get abandoned.
Three to six single-tap questions is a healthy core for most categories. Habit-change apps go much longer and get away with it because every answer visibly shapes the plan. For what flow length looks like across categories, see our breakdown of how many onboarding screens top apps use.
Sequence permissions, never stack them
Nothing marks a lazy onboarding like the notification prompt firing on first launch, before the app has shown anything. Each permission request needs its own moment, preceded by a screen that explains what the user gets. Notifications after the user sets a goal worth reminding them about. Photos when they take the action that needs the camera roll. Location when the feature that uses it is on screen.
On iOS this is not just polish: the system prompt is effectively one-shot, and a declined prompt is very hard to recover from. Prime first, ask second. We wrote up the full pattern in push notification permission prompts.
Place the paywall deliberately
For subscription apps the paywall is part of onboarding, not something that happens later. The default that works for most categories: paywall at the end of the flow, after the personalization loop has built up a concrete picture of value, and before the user lands in a free experience they may settle into. Where you put it, how you frame the trial, and what you show first are the highest-leverage tests you can run. The specifics are big enough that we gave them their own guide: when should your app show the paywall?
Design for the drop-off curve
Every onboarding flow is a funnel, and you should be able to see it as one. Instrument each screen. The shape tells you what to fix: a cliff at one screen means that screen is broken (too much text, an unearned permission ask, a form where a tap should be). A gradual slide everywhere means the flow lacks momentum and needs earlier proof of value. No data means you are redesigning on vibes.
Judge changes by activation and early retention, not completion alone. Shortening a flow almost always raises completion; if it also lowers Day 7 retention, you optimized the wrong number. Benchmarks for what good retention looks like are in our retention benchmarks guide.
Ship it like a growth surface, not a release
The teams that win at onboarding are not the ones with the best first version. They are the ones that iterate every week, because their onboarding does not ride the release train. When a copy change needs a build, review, and a phased rollout, iteration dies and the flow fossilizes.
This is the problem Setgreet exists to solve: onboarding flows render as real native screens in your app, and changes go live in minutes without an App Store release. Start from a category-matched flow, watch the per-screen funnel, ship the fix the same day. The getting started guide shows the full loop.
The mistakes that keep repeating
- The feature dump. Eight slides of interface explanation before any value. Users retain almost none of it.
- Asking without acting. Personalization questions whose answers change nothing visible.
- Permission stacking. Two or three system prompts in the first thirty seconds.
- Login before value. Forcing account creation before the user has seen anything worth an account.
- Shipping once. Treating onboarding as a launch deliverable instead of the highest-traffic funnel in the product.
A first-session checklist you can run this week
Install your own app fresh, on a real device, and walk the first session with a stopwatch and a notebook. Score it against these questions:
- Does the first screen name the job the user came for, in their words?
- How many seconds until the user sees something personal to them? Under 60 is the bar.
- Does every question visibly change what happens next? Cut the ones that do not.
- Is any permission requested before its value is obvious? Move it.
- Could a distracted user complete the flow with one thumb, on a train? Every typing field is a toll booth.
- When the paywall appears, does it reference anything the user just said? A generic paywall after a personalization flow wastes the flow.
- What happens on a network drop, a backgrounded app, a force quit? Broken resume states silently eat cohorts.
Then compare your notes against the funnel data. The screen you found tedious is usually the screen with the drop-off cliff; the fix you guessed is usually worth testing first. This audit takes an hour and routinely finds the biggest win of the quarter.
One more habit separates the teams that compound from the teams that stall: put a recurring 30-minute onboarding review on the calendar, every week, with the funnel chart open. Not to redesign anything, just to answer "what is the one thing we change this week?" Onboarding decays quietly as the product, the audience, and the acquisition mix shift under it. The weekly question keeps it honest.
Frequently asked questions
Should onboarding come before or after sign-up?
Deliver value, or at least a concrete preview of it, before asking for an account. The exception is apps where the account is the product, like banking or messaging. If sign-up must come first, keep it to one screen and defer everything optional.
How long should mobile onboarding take?
Under two minutes of active time for most apps, even when the flow runs 10-plus screens of single-tap questions. Time-to-first-value matters more than screen count or seconds elapsed.
How often should we change our onboarding?
Review the funnel weekly and ship at least one meaningful iteration per month. If your tooling makes that expensive, fix the tooling first; iteration speed compounds more than any single redesign.