App Onboarding: Keep New Users Past the First Screen
App onboarding that keeps new users: delay sign-up, ask for permissions in context, reach the first useful result fast, within Apple and Google rules.
Good app onboarding gets a new user to the first useful result as fast as possible and asks for nothing until it is needed. That means letting people look around before forcing an account, requesting permissions such as location or notifications at the moment a feature needs them, and cutting any screen that explains the app instead of letting people use it. Both Apple and Google build some of this into their rules, so a flow that ignores it can also cause problems at app review.
Key takeaways
- Define the first useful moment for your app, then remove every step between opening it and reaching that moment.
- Apple's App Store guidelines say apps without significant account-based features should let people use them without a login.
- Google's Android guidance says to ask for a permission in context, when the user starts the feature that needs it.
- On Android, a user who denies a permission twice will not see the system prompt again, so a badly timed request can lose that feature for good.
- If you offer account creation on iOS, Apple requires account deletion inside the app as well.
What is app onboarding, and where do new users drop off?
App onboarding is everything between a person opening your app for the first time and the point where they get value from it. It includes welcome screens, sign-up, permission requests, profile set-up and any tutorial. It is also the part of the product where you have the least goodwill: the user has not yet seen anything that makes the effort worthwhile.
When we review a struggling app, the drop-off points are usually the same. A wall of introductory slides. A sign-up form before the user has seen a single screen of content. Three system permission prompts in a row on launch. A long profile form asking for details the app does not use until much later. Each of these is a small tax, and together they lose people before the app has had a chance.
The fix starts with a question most briefs skip: what is the first useful moment? For a booking app it is seeing available slots. For a loyalty app it is seeing your points or the first reward. For a field-service app it is today's jobs. Write that moment down, then design onboarding backwards from it. Our guide to choosing features for an app MVP covers how to pick the one job your first version must do well.
App onboarding best practices: a first-run checklist
- Show value before asking for anything. Let people browse content, see prices or try a feature as a guest where the app allows it.
- Keep welcome screens to a minimum. One screen that says what the app does and a clear button is often enough. Offer a skip option on anything longer.
- Ask for sign-up at the point it is needed, such as saving a booking, placing an order or syncing data.
- Request permissions in context, one at a time, with a short explanation first.
- Collect profile details progressively. Ask for a name at sign-up; ask for preferences when they change what the user sees.
- Teach in place. A single hint on the screen where a feature lives works better than a tutorial the user will forget.
- Make the empty state useful. A new account with no data should show what to do next, not a blank screen.
- Remember progress. If someone leaves mid-sign-up, do not make them start again.
Sign up flow in an app: when to ask for an account
Forcing an account on the first screen is the single most common onboarding mistake we see, and on iOS it can also run into the rules. Apple's App Store Review Guidelines say that if your app does not include significant account-based features, you should let people use it without a login. They also say that if your app supports account creation, you must offer account deletion within the app.
Some apps genuinely need an account straight away: a staff app, a patient portal or a banking app. Even then, you can reduce the effort:
- Use the fewest fields possible. Email and password, or a one-time code, then collect the rest later.
- Offer platform sign-in options. If you use a social login such as Google Sign-In as the main account method, Apple's guideline 4.8 says you must also offer an equivalent option that limits data to name and email, lets people keep their email private and does not track them for advertising without consent. There are exceptions, such as apps that use only your company's own sign-in system.
- Explain why. "Create an account to save your booking" lands better than a bare login wall.
- Keep people signed in on their own device, with biometric unlock where security allows it.
| App type | Account needed at launch? | Better first step |
|---|---|---|
| Restaurant or retail ordering | Usually no | Browse menu or products as a guest; sign in at checkout |
| Booking app for a salon or clinic | Usually no | See services and slots; create an account to confirm |
| Loyalty or membership app | Often yes | Quick sign-up, then show points or first reward at once |
| Staff or field-service app | Yes | Invitation link or code from the employer, then today's jobs |
| Client portal app (see our client portal builds) | Yes | Sign in with details from the business, then the latest document or message |
Asking for permissions without losing people
Permission prompts are where onboarding most often goes wrong, because the system dialogs are blunt. Google's Android guide to requesting runtime permissions points out that the system dialog says what your app wants but not why, and that your app cannot customise that dialog. Its basic principles are clear:
- Ask for a permission in context, when the user starts to use the feature that needs it.
- Do not block the user: any screen explaining the request must let them cancel.
- If the user says no, keep the rest of the app working and disable only the feature that needs the permission.
- Do not nag. Explain what is unavailable, but respect the decision.
There is a practical reason to take this seriously. Google's guide says that if a user taps Deny for a permission more than once, they will no longer see the system dialog for it; Android treats that as "don't ask again". Request camera access on the first screen, get two refusals, and the user who later wants to scan a document has to dig through settings. Since Android 11, location, microphone and camera prompts also include an "Only this time" option, so the app must cope with access that lapses.
A simple pattern for every permission
- Wait until the user taps the feature, such as "Find branches near me".
- Show a short screen of your own: what you need, why, and what they get. Include a "Not now" button.
- Trigger the system prompt only if they continue.
- If they decline, show the feature in a limited form, such as a postcode search instead of location.
The same thinking applies to notifications. Ask after the user has done something that makes updates useful, such as booking an appointment, rather than on first launch.
First-time user experience: teach by doing
Introductory carousels feel helpful when you design them and get skipped when you use them. The first-time user experience works better when the app teaches inside the real screens.
- Pre-fill something. A sample project, a demo booking or example data shows the app working.
- Use one hint at a time, pointing at the control that matters, and do not show it again once used.
- Write helpful empty states. "No jobs yet. New jobs from the office will appear here" is onboarding in one line.
- Celebrate the first success quietly. A short confirmation that the first booking or order went through builds confidence.
Design for the smallest phone your users carry and for one-handed use. Many onboarding problems are layout problems: buttons below the fold, text too small, keyboards covering the next field. The same principles behind mobile-first web design apply inside apps.
How to measure and fix onboarding drop-off
You cannot improve onboarding you cannot see. Before launch, add analytics events for each step: app opened, welcome screen passed, sign-up started, sign-up completed, each permission accepted or declined, and the first useful moment reached. Then look at the funnel.
| Where people drop | Likely cause | What to try |
|---|---|---|
| Before sign-up completes | Account asked for too early or too many fields | Guest mode, fewer fields, one-time codes |
| At a permission prompt | Asked with no context | Move the request to the feature; add an explanation screen |
| After sign-up, before first use | Empty app, nothing to do | Sample data, a clear next action |
| After the first session | Value not obvious or not repeated | Timely, opted-in reminders tied to real events |
Test with five or six real people from your audience before launch, watching them install and use the app without help. It is the cheapest way to find the screen that confuses everyone.
Frequently asked questions
How many onboarding screens should an app have?
As few as possible. Many apps need only one welcome screen with a clear button, followed by the real interface. If you need to explain more, teach inside the app with hints at the moment a feature is used. Always offer a skip option on introductory slides.
Should an app ask for notification permission on first launch?
Usually not. Ask after the user does something that makes notifications useful, such as booking an appointment or placing an order, and explain what they will receive. A request with context is easier to accept than a prompt on the first screen before the user knows what the app does.
Can I make users create an account before using my iOS app?
Only if the app has significant account-based features. Apple's App Store Review Guidelines say apps without them should let people use the app without a login. If your app supports account creation, Apple also requires an option to delete the account inside the app.
What happens if a user denies a permission on Android?
Your app should keep working with that feature limited or disabled, and explain what is unavailable without pressure. Google's guidance notes that if a user denies the same permission more than once, the system stops showing the dialog, so only ask when the user is starting the feature that needs it.
Does Flutter change how onboarding works?
Not in our builds. The Flutter apps we ship still trigger each platform's own permission dialogs and go through the same App Store and Google Play review. A cross-platform build lets you design one onboarding flow, but you should still test it on both platforms, because permission dialogs and sign-in options look and behave differently.
Plan an onboarding flow that earns the second visit
Write down your app's first useful moment, map every screen in front of it and cut or delay everything you can. If you are planning a new app or fixing one that loses users early, our mobile app development team designs and builds onboarding flows in Flutter for iOS and Android. Start a project or contact us to talk it through.
