App screens: the mobile app screens every app needs

Most mobile apps are built from the same dozen kinds of screens. Knowing them saves you from forgetting the unglamorous ones (empty states, errors, settings) that users hit every day. Here is each common app screen, what it's for and how to lay it out.

How a mobile app screen is laid out

Nearly every app screen follows the same layout from top to bottom:

1. Top bar: the screen title, a back button on detail screens and one or two actions.
2. Content: the list, form or detail the screen exists for. This is most of the screen.
3. Primary action: one clear button for the main task, often pinned near the bottom where thumbs reach.
4. Tab bar: on top-level screens only, with 3 to 5 sections.

Keep 16 to 20 points of side margin, use one spacing scale (multiples of 4 or 8) and give each screen a single focal point. Our mobile app design guide covers these basics in more depth.

Launch and onboarding screens

Launch screen

Shown for a moment while the app loads. Keep it to your logo or the first screen's background. Apple recommends a launch screen that looks like the app's first screen, so starting feels instant.

Onboarding

One to three screens that show what the app does for the user, then get out of the way. Each screen: one short headline, one line of explanation and an illustration or real product view. Always offer Skip. Ask for permissions (notifications, location) at the moment they're needed, not all at once here.

Sign up and log in

Offer the fastest options first: Sign in with Apple, Google or a one-time email code. If you need a password, show its rules before the user types, not as an error after. Keep sign-up to the fields you truly need now; the rest can come later.

Core screens

Home

The screen people see most. It should answer "what do I need to know or do right now?" A banking app leads with the balance, a to-do app with today's tasks, a delivery app with the active order. Resist turning home into a menu of everything the app can do.

List or feed

Transactions, messages, products, posts. Design the list row carefully, because users scan dozens of them: the most important text first and largest, secondary details smaller and lighter, and one trailing value or action. Add search or filters when a list grows past a screen or two.

Detail

One item in full: an order, a contact, a recipe. Lead with the item's identity (name, image, status), then the details people check most, then actions. Put the primary action in a fixed bottom bar if the page scrolls.

Create and edit

Forms. One column, labels above fields, the right keyboard for each field (number pad for amounts, email keyboard for email). Group related fields, mark the optional ones rather than the required ones and keep the save button visible.

Search

Show recent searches and suggestions before the user types. Results should update as they type when that's fast, and a search with no results should suggest what to try instead.

Supporting screens

Profile and settings

Plain lists grouped by topic: account, notifications, privacy, help, sign out. Users don't browse settings, they hunt for one switch, so clear labels matter more than looks.

Notifications

A list of what happened, newest first, with unread items marked. Each row should open the thing it's about.

Paywall or upgrade

Show what the user gets, the price and the billing period plainly, and a clear way to close it. Compare plans in a simple table if there's more than one.

State screens: the ones people forget

Empty states

What a list looks like before it has anything in it. Explain what will appear here and offer the action that fills it: "No invoices yet. Create your first invoice." An empty state is often a new user's first impression of a feature.

Loading

Skeleton rows in the shape of the real content feel faster than a spinner on a blank screen. For short waits under a second, show nothing at all.

Errors

Say what happened in plain words and what to do next: "No connection. Check your internet and try again", with a Try again button. Keep the user's input; never clear a form because a request failed.

Success

Confirm a finished task briefly (a toast, a check mark) and move people on. A full success screen is only worth it for big moments, like a completed order.

Map the screens before you design them

Before designing anything, list your app screens and draw arrows for how people move between them. It takes ten minutes and catches dead ends, like a detail screen with no way to edit, or a flow that needs a screen you forgot.

If you want a head start, describe your app to an AI app designer and ask for the core screens first, then ask for the empty, loading and error states by name. With Outclass each screen comes out in the same design system, so the set looks like one app, and you can copy every screen into Figma as editable layers.