Back to Blog
ui-patternsmobilenavigationuxreference

Mobile UI Patterns 2026: 19 Patterns and When to Use Them

··12 min read·By GenDesigns Team

Mobile apps rely on a small set of established UI patterns: bottom tab bars for primary navigation, cards and lists for content, pull to refresh and swipe actions for interaction, and bottom sheets instead of centered modals. GenDesigns applies these patterns automatically when it generates app screens, so you can name a pattern in the prompt and get a standard implementation.

Every mobile app reinvents the same wheels. Tab bars, pull to refresh, swipe actions—these patterns exist because they work, and users expect them.

This is a reference for 19 of them: sixteen worth reaching for by default across navigation, input, content and interaction, and three worth using carefully. I'll skip the theoretical stuff and focus on practical implementation.

How users move through your app determines how it feels to use.

Bottom tab bar

The default for apps with 3-5 main sections. Instagram, Spotify, and most consumer apps use this.

┌─────────────────────────────────────┐
│                                     │
│                                     │
│            Content                  │
│                                     │
│                                     │
├─────────────────────────────────────┤
│  🏠    🔍    ➕    ❤️    👤       │
│ Home Search  New  Activity Profile  │
└─────────────────────────────────────┘

Rules that matter:

  • 3-5 items max (more gets cramped)
  • Icons with labels beat icons alone
  • The current tab should be visually distinct
  • Tapping the current tab should scroll to top or reset the stack

When to use it: Almost always for consumer apps. It keeps core functions one tap away.

When to skip it: Single-purpose apps (camera, calculator), games, or apps with one primary flow. For a deeper look at how these patterns differ between platforms, see our iOS vs Android design differences guide.

Top tab bar (scrollable tabs)

Good for subcategories within a section. Twitter uses this for different timeline views.

┌─────────────────────────────────────┐
│  For You  │ Following │ Lists  → → │
├───────────┴───────────┴─────────────┤
│                                     │
│            Content                  │
│                                     │
└─────────────────────────────────────┘

Rules that matter:

  • Swipe between tabs should move content
  • Visual indicator showing current tab
  • Tabs can scroll horizontally if you have many

When to use it: Content that has natural categories but doesn't need bottom nav prominence.

Hamburger menu (nav drawer)

The three-line menu icon that reveals a side panel. Controversial but still common.

┌─────────────────────────────────────┐
│ ☰  App Title                     🔔 │
├─────────────────────────────────────┤
│                                     │
│            Content                  │
│                                     │
└─────────────────────────────────────┘

Menu opens:
┌───────────┬─────────────────────────┐
│ Profile   │                         │
│ Settings  │     Dimmed content      │
│ Help      │                         │
│ Sign out  │                         │
└───────────┴─────────────────────────┘

The controversy: Items in hamburger menus get used less. If something matters, it shouldn't be hidden.

When it works:

  • Secondary navigation (settings, help, account)
  • Apps with many sections that can't fit in tabs
  • Desktop-first apps adapted for mobile

When to avoid it: Don't put primary features here. If users need it regularly, it should be visible.

Stack navigation (push/pop)

Moving deeper into content, then backing out. This is the foundation of most app navigation.

List → Detail → Action
 ←       ←        ←    (Back at each level)

Rules that matter:

  • Back button or swipe gesture to return
  • Maintain scroll position when returning to list
  • Don't go too deep (3-4 levels max before users feel lost)

When it's essential: Any app with list → detail flows. That's most apps.

Skip the guesswork: Generate app screens with these patterns built in — describe your app and GenDesigns applies the right navigation, input, and content patterns automatically.

Input patterns

How users enter information.

Text fields

Seems simple but easy to mess up.

Do:

  • Large tap targets (44pt minimum height)
  • Clear placeholder text that disappears on focus
  • Appropriate keyboard type (email, phone, number)
  • Visible error states with helpful messages
  • Auto-capitalize appropriately (names yes, emails no)

Don't:

  • Put labels only inside the field (they disappear when typing)
  • Use placeholder text as the only label
  • Make users scroll to see the submit button while typing

Two approaches: dedicated search screen or inline search.

Search bar approach:

┌─────────────────────────────────────┐
│  🔍  Search products...             │
├─────────────────────────────────────┤
│  Recent searches:                   │
│  • Running shoes                    │
│  • Blue jacket                      │
└─────────────────────────────────────┘

Inline filter approach:

┌─────────────────────────────────────┐
│  🔍  Filter                    ⚙️   │
├─────────────────────────────────────┤
│  ┌──────┐ ┌──────┐ ┌──────┐        │
│  │ All  │ │ New  │ │ Sale │        │
│  └──────┘ └──────┘ └──────┘        │
├─────────────────────────────────────┤
│            Results                  │
└─────────────────────────────────────┘

Rules that matter:

  • Show recent searches (users repeat themselves)
  • Search as you type when possible
  • Clear button to reset
  • Empty states when no results

Pickers and selectors

Avoid typing when selection works better.

Date picker: Use the native picker. Users know how it works. Custom date pickers are usually worse.

Option selection:

  • 2-5 options: Segmented control or chips
  • 5-10 options: Dropdown or action sheet
  • 10+ options: Searchable list

Multi-select: Checkboxes with clear selected count. "3 selected" beats users wondering if their taps registered.

Forms

Long forms on mobile are painful. Minimize them.

Strategies:

  • Break into steps (1 of 3, 2 of 3...)
  • Save progress automatically
  • Use smart defaults
  • Only ask what's necessary

Multi-step forms are most common during sign-up, where the stakes are highest — our app onboarding design examples break down how top apps sequence those steps.

Progress indicator:

┌─────────────────────────────────────┐
│  Personal Info     1 ━━━━ 2 ─── 3  │
├─────────────────────────────────────┤
│                                     │
│  First name: [_______________]      │
│                                     │
│  Last name:  [_______________]      │
│                                     │
│           [ Continue ]              │
└─────────────────────────────────────┘

Content patterns

How information gets displayed.

Cards

The workhorse of mobile UI. Self-contained content blocks that can be stacked, gridded, or swiped.

┌─────────────────────────────────────┐
│  ┌─────────────────────────────┐   │
│  │         Image               │   │
│  ├─────────────────────────────┤   │
│  │  Title                      │   │
│  │  Subtitle or description    │   │
│  │  [Action]        [Action]   │   │
│  └─────────────────────────────┘   │
│                                     │
│  ┌─────────────────────────────┐   │
│  │         Next card           │   │
└──┴─────────────────────────────┴───┘

Rules that matter:

  • Consistent card structure throughout the app
  • Clear visual boundaries (shadow, border, or background)
  • Tap target is the whole card for detail views
  • Actions within cards should be obviously tappable

Shadows carry most of the boundary work in light themes and almost none in dark ones, where elevation has to come from surface color instead. Our dark mode design guide covers how to handle that shift.

Lists

For content without images or when density matters.

┌─────────────────────────────────────┐
│  Item title                      >  │
│  Secondary text                     │
├─────────────────────────────────────┤
│  Another item                    >  │
│  Secondary text                     │
├─────────────────────────────────────┤
│  Third item                      >  │
└─────────────────────────────────────┘

Rules that matter:

  • Clear separators between items
  • Chevron or other indicator for drilldown
  • Thumbnail on left if images are relevant
  • Action on right if there's a secondary action

Empty states

What users see when there's no content yet.

Do:

  • Explain why it's empty
  • Tell users how to add content
  • Use illustration or icon to soften the void

Don't:

  • Show literally nothing
  • Use generic "No data" messages
  • Miss the opportunity to guide users
┌─────────────────────────────────────┐
│                                     │
│           (illustration)            │
│                                     │
│        No workouts yet              │
│                                     │
│   Start tracking your first         │
│   workout to see it here.           │
│                                     │
│       [ Log Workout ]               │
│                                     │
└─────────────────────────────────────┘

Loading states

Users should always know the app is working.

Skeleton screens: Gray placeholders mimicking content layout. Better than spinners because they show progress.

┌─────────────────────────────────────┐
│  ┌─────────────────────────────┐   │
│  │  ████████████               │   │
│  │  ██████████████████████     │   │
│  │  ████████                   │   │
│  └─────────────────────────────┘   │
└─────────────────────────────────────┘

Spinners: Fine for short waits (less than 3 seconds) or when content structure isn't predictable.

Progress bars: For long operations where you can show actual progress (file uploads, downloads).

Interaction patterns

How users manipulate content.

Pull to refresh

Standard for feeds and lists with changing content.

Pull down:
┌─────────────────────────────────────┐
│           ↺ Refreshing...           │
├─────────────────────────────────────┤
│            Content                  │
└─────────────────────────────────────┘

Rules that matter:

  • Visual feedback during pull
  • Threshold before refresh triggers (don't refresh on every small scroll)
  • Haptic feedback on iOS when threshold is crossed

Swipe actions

Revealing actions by swiping list items. Email apps made this famous.

Swipe left to reveal:
┌─────────────────────────────────────┐
│  Item content         │ 🗑️  │ ⭐  │
└─────────────────────────────────────┘

Rules that matter:

  • Swipe should reveal, not immediately execute
  • Destructive actions (delete) need confirmation or undo
  • Keep actions to 2-3 max per direction
  • Partial swipe reveals; full swipe can execute primary action

Long press

Secondary actions without cluttering the UI.

Common uses:

  • Context menus
  • Reordering items
  • Quick actions (iOS home screen style)

Rules that matter:

  • Visual feedback that press registered
  • Haptic feedback improves discoverability
  • Don't hide essential actions behind long press

Bottom sheets

Modal content that slides up from the bottom. More thumb-friendly than centered modals.

┌─────────────────────────────────────┐
│                                     │
│         Dimmed background           │
│                                     │
├─────────────────────────────────────┤
│  ───  (drag handle)                 │
│                                     │
│  Sheet content                      │
│  Options, forms, details            │
│                                     │
│  [ Primary Action ]                 │
└─────────────────────────────────────┘

Rules that matter:

  • Drag handle to indicate dismissability
  • Can be dismissed by swipe down or tapping background
  • Don't put critical actions only accessible via sheet

Patterns to use carefully

Carousels

Swiping through a series of items.

Problems:

  • Users often miss content past the first card
  • No indication of how many items exist
  • Easy to accidentally swipe past what you wanted

When they work:

  • When all items are roughly equal in importance (featured stories)
  • When there's clear visual indication of more content
  • When users can tap to see all items

Infinite scroll

Loading more content as users scroll.

Problems:

  • Hard to reach footer content
  • Users lose their place if they accidentally navigate away
  • Can feel endless without a sense of completion

When it works:

  • Social feeds where there's genuinely no "end"
  • Search results (but show count if possible)

Always provide:

  • Loading indicator when fetching more
  • Way to jump to top
  • Saved scroll position if navigating away

Modals and popups

Interrupting content with overlay.

Use sparingly. Every modal is a user interruption. Ask: does this need to block the rest of the app?

Better alternatives:

  • Inline expansion
  • Bottom sheets (less intrusive)
  • New screen (if complex)

What's dated in 2026

Heavy skeuomorphism. The fake leather and wood textures from iOS 6 era. Nobody misses these.

Hamburger menus for primary nav. Bottom tabs won. Accept it.

Tiny tap targets. We know better now. 44pt minimum.

Full-screen interstitials. Users close them immediately. Don't even try.

Tutorial overlays. Those "coach marks" pointing at every button. Make the UI self-explanatory instead.

Aggressive permission requests on first launch. Ask when the feature is actually needed.

Using AI to implement patterns

GenDesigns knows these patterns. Mention them in your prompts:

Design a recipe app with:
- Bottom tab navigation (Home, Search, Saved, Profile)
- Card-based recipe list with pull to refresh
- Swipe to save recipes
- Bottom sheet for ingredient lists
- Skeleton loading states

The AI will apply standard implementations. You can then iterate on specifics.

When it comes time to build these in code, most of the patterns above already exist as components — our best React UI components for mobile comparison covers the libraries that ship them.

Use our mobile app design checklist to make sure you haven't missed any essential elements. Patterns aren't creative challenges. They're conventions that let you focus creative energy on what makes your app different.


Frequently Asked Questions

What are the most important mobile UI patterns in 2026?

A bottom tab bar for primary navigation, stack navigation for list-to-detail flows, cards and lists for content, pull to refresh for anything that updates, swipe actions on list items, and bottom sheets for modal content. These six cover the structure of almost every consumer app. The remaining patterns handle input, loading, and empty states.

How many items should a bottom tab bar have?

Three to five items. Beyond five, the targets get cramped. Pair every icon with a label, make the current tab visually distinct, and make tapping the current tab scroll to top or reset the navigation stack.

Are hamburger menus still acceptable in mobile apps?

For secondary navigation, yes. For primary navigation, no. Items hidden inside a hamburger menu get used less, so settings, help and account links are fine there while core features are not. Bottom tabs won that argument.

What is the minimum touch target size on mobile?

44pt. That is the minimum height for a text field and the minimum size for any other interactive element: buttons, list rows, icons. Anything smaller belongs on the list of patterns that are dated in 2026.

Should I use a bottom sheet or a centered modal?

A bottom sheet, in most cases. It sits closer to the thumb, it can be dismissed by swiping down or tapping the background, and a drag handle makes that dismissal discoverable. Reserve full modals for moments that genuinely need to block the rest of the app, and consider inline expansion or a new screen before either.

Which mobile UI patterns are outdated in 2026?

Heavy skeuomorphism, hamburger menus used for primary navigation, tap targets below 44pt, full-screen interstitials, tutorial overlays with coach marks pointing at every button, and permission requests fired on first launch instead of at the moment the feature needs them.


Related reading: