App Onboarding: First-Run Screens and Permission Prompts

What onboarding is for

Apple's guidance on onboarding starts with a high bar: ideally people understand an app simply by using it, and if onboarding is necessary, the flow should be "fast, fun, and optional". Onboarding is not a goal in itself. Its job is to get someone to the first useful moment, such as their first booking, their first saved item or their device connected, as quickly as possible, and to set up only what that moment needs. Write that moment down before designing any screens.

Teach by doing, not by slides

Apple's onboarding guidance gives several practical rules:

• Teach through interaction. People grasp and remember a task better when they perform it than when they read about it. Let them try an action safely instead of showing a picture of it.
• Prefer tips in context. A short tip shown next to the feature, when someone reaches it, often works better than one long flow at the start.
• Keep any required flow brief. Teaching too much at once overwhelms people and they remember less.
• Make tutorials optional. If someone skips one, do not show it again on the next launch, but keep it easy to find later, for example in help or settings.
• Postpone non-essential setup, and provide reasonable defaults so most people can start straight away.

The same guidance advises letting people use the app before asking them for a rating or a purchase, because they respond better once they are engaged. Our app store optimisation guide covers when and how to ask for reviews.

Sign-in: only when it is needed

A sign-up form on the first screen asks for commitment before people have seen any value, and Apple's rules limit it. Guideline 5.1.1(v) of the App Review Guidelines says that if an app does not include significant account-based features, it should let people use it without a login. It adds that apps may not require personal information to function, except where it is directly relevant to the core functionality or required by law.

In practice, let people look around first and ask for an account when it gives them something, such as saving work, syncing devices or placing an order.

If you offer social sign-in, guideline 4.8 applies. An app that uses a third-party or social login service to set up the user's primary account must also offer an equivalent login option that limits data collection to name and email address, lets people keep their email address private, and does not collect their interactions with the app for advertising without consent. The guideline lists exceptions, for example where the app uses only the company's own account system.

Asking for permissions on iPhone and iPad

Apple's privacy guidelines list what needs permission, including location, contacts, photos, camera, microphone, Bluetooth, local network access and the advertising identifier used for tracking. The system shows a standard alert, and you supply the text that explains why. The main rules:

• Ask only for what you need. Asking for more data than a feature needs, or before a person shows interest in the feature, makes it hard for people to trust the app.
• Ask at the moment of use. Ideally wait until someone uses the feature that needs access. Avoid asking at launch unless the app cannot work without it; Apple's example is a navigation app that needs location.
• Write a clear purpose string. One brief, complete, active sentence. Apple contrasts "The app records during the night to detect snoring sounds" with vague text such as "Microphone access is needed for a better experience".

You may show your own screen before the system alert if more context is essential, but Apple sets strict rules for it. It should have only one button, titled something like "Continue" or "Next", that opens the system alert. Do not label it "Allow", and do not offer a way to close or cancel without seeing the alert. For tracking requests, a custom screen that could confuse or mislead people, for example by offering incentives or showing an image of the alert, will lead to rejection. Our guide to mobile app analytics and privacy covers App Tracking Transparency in more detail.

Asking for permissions on Android

Android's guide to requesting runtime permissions sets out the same principle as a workflow: associate each permission with a specific action in the app, wait for the user to start that action, and then request the permission. Before asking, check whether the system suggests showing a rationale, through shouldShowRequestPermissionRationale(). If it does, explain in your own interface what data the app wants and what the user gets in return.

Timing matters. The same page says that if a user taps Deny for a permission more than once during the app's lifetime on a device, the system dialog no longer appears for that permission. The user has to go to settings to change it. A request fired at a bad moment can lose that feature for good.

When a permission is denied, Android's guidance says the app must help people understand what will not work, and keep as much of the app usable as possible. If the microphone is refused, text input should still work fully.

Often you do not need the permission at all. Android's page on minimising permission requests suggests lower-fidelity options, such as approximate rather than precise location, and system pickers, such as the photo picker and contact picker, that grant access only to what the user chooses. The notification permission follows the same logic on both platforms; see our push notifications guide for when to ask.

Accounts must be deletable

If people can create an account in your app, both stores require a way to delete it, so plan it alongside sign-up. Apple's guidance on offering account deletion says people must be able to start deletion within the app, the option should be easy to find, usually in account settings, and only offering to deactivate the account is not enough. Apps outside highly regulated industries should not make people phone, email or use a support chat to delete their account.

Google Play's account deletion requirements ask for an in-app path to delete the account and associated data, and also a web link where people can request deletion, declared in the Data safety form. Our guide to publishing on the App Store and Google Play covers the store side.

Measuring the first run

Treat onboarding as a funnel: first open, each step, sign-up if you have it, each permission response and the first useful moment. Analytics events at each step show where people drop out, and permission responses show whether a prompt is landing at the right time. Remember that analytics collection may need consent and must match your privacy labels; our mobile app analytics guide explains both. Test with a fresh install, since permission dialogs appear only once.

A checklist

• The first useful moment is defined, and nothing unnecessary comes before it.
• Teaching happens through interaction and tips in context; any tutorial is short, skippable and findable later.
• People can try the app before signing in, unless it is truly account-based.
• Each permission is requested when the related feature is used, with a clear, specific explanation.
• The app still works as far as possible when a permission is denied.
• Account deletion is in the app, and on Android also on the web.
• Each onboarding step is measured, with consent where required.

Frequently asked questions

Should an app have onboarding screens?

Only if people cannot understand the app by using it. Apple advises that any onboarding be fast, fun and optional, and that teaching happen through interaction and tips in context rather than a long series of screens.

When should an app ask for permissions?

When the person first uses the feature that needs it. Apple and Android both advise against asking at launch unless the app cannot work without that access, and both ask for a clear explanation of why the access is needed.

What happens if someone denies an Android permission twice?

Android's documentation says that if a user taps Deny for the same permission more than once, the system dialog no longer appears for it. They have to change it in settings, so ask only when the related feature is in use.

Do people have to create an account to use my app?

Not unless the app has significant account-based features. Apple's guideline 5.1.1(v) says such apps should let people use them without a login, and apps may not require personal information unless it is relevant to the core functionality or required by law.

Do I need account deletion in my app?

Yes, if people can create an account in it. Apple requires a way to start deletion within the app, and Google Play requires an in-app path plus a web link where people can request deletion of their account and data.

Planning a new app or reworking the first-run experience of an existing one? See our mobile app development service and all our services, or email info@creahive.com.