Platform Conventions: iOS, Android, Web & Desktop

The full lesson

Users bring deeply ingrained habits to every screen they touch. An iOS user reaches for the tab bar without thinking. An Android user expects the system back gesture to always work. A desktop user looks for a menu bar and keyboard shortcuts. Break those habits and your app feels broken — not original. Mastering platform conventions means spending users’ attention wisely, so you save friction for the moments that actually make your product stand out.

Why Platform Conventions Exist

Every platform has built up a vocabulary of gestures and interactions over years of first-party apps, third-party convention, and published guidelines. iOS has the Human Interface Guidelines (HIG). Android has Material Design 3. The web has ARIA patterns, browser chrome, and decades of document-navigation muscle memory. macOS, Windows, and Linux each have distinct ideas about window management, keyboard focus, and menu structure.

These conventions aren’t arbitrary taste. They exist because they reduce the time users spend learning your interface — and increase the time they spend getting things done. When you break a convention, users pay a cognitive tax: they slow down, hesitate, or make mistakes. Multiply that across millions of sessions and the cost becomes enormous.

The goal isn’t blind rule-following. It’s knowing which conventions are load-bearing (users will stumble without them) and which are optional (you can safely innovate there).

iOS Conventions

Navigation and Tab Bars

The iOS tab bar is the primary persistent navigation pattern for apps with distinct top-level sections. It sits at the bottom of the screen — within thumb reach on the 6.7-inch displays now common — and shows 3–5 destinations. The selected item uses color and a label; unselected items use a muted icon. This is a load-bearing convention: users scan the tab bar before exploring anything else.

The navigation controller stack — the back chevron in the top-left — handles moving deeper into a hierarchy. A sheet (a modal card that slides up from the bottom) is for tasks that interrupt flow, like sharing, confirming, or picking an option. Sheets should always have an explicit dismiss action. Full-screen modals are rare and best reserved for immersive experiences like cameras.

Avoid the hamburger menu on iOS. Apple’s own apps don’t use it, and for good reason: hidden navigation slows task completion and cuts discoverability roughly in half compared to persistent tab bars.

Gesture Vocabulary

iOS is a gesture-first platform. The system back gesture — swiping from the right edge — is so embedded in users’ habits that blocking it with a custom navigation implementation breaks their entire mental model of the app. Pull-to-refresh, long-press context menus, pinch-to-zoom, and swipe-to-delete are all expected behaviors, not optional features.

One critical detail: the system home indicator and Dynamic Island create safe-area insets — protected zones at the top and bottom of the screen. Your UI must respect these zones. Use env(safe-area-inset-*) equivalents in native code, and never place interactive targets behind them.

Typography and Sizing

Apple’s Dynamic Type system scales text across 12 accessibility sizes. Your layouts must be flexible enough to handle all of them. The minimum touch target is 44 × 44 pt — the HIG requirement, which aligns with WCAG 2.2’s 24 × 24 CSS pixel minimum. Treat 44 pt as a floor, not a ceiling; 48–56 pt is better for primary actions.

Android Conventions

Material Design 3 and You

Material Design 3 (M3) introduced dynamic color, updated component shapes, and a revised motion system. The key navigation patterns are:

• Navigation bar (bottom, 3–5 destinations): mirrors the iOS tab bar in position and function
• Navigation drawer (left-side panel on large screens): right for apps with many top-level sections on tablets and foldables
• Navigation rail (a compact vertical icon list at medium breakpoints): a persistent pattern for screens wider than 600 dp

The floating action button (FAB) is Android’s canonical “primary action” element. Extended FABs (icon + label) are preferred when the label helps users understand the action. Do not use a FAB for navigation — it triggers an action, it doesn’t point to a destination.

Back Navigation

Android’s back model is more complex than iOS’s. Users can swipe from either edge or tap the system back button. Unlike iOS — where back always moves up the navigation stack — Android back can exit an app, dismiss a dialog, or close a bottom sheet, depending on context. Your job is to make those behaviors predictable. Don’t override the system back gesture unless you have an open overlay (a dialog, bottom sheet, or search overlay) that should close first.

Touch Targets and Density

Material guidelines specify a minimum touch target of 48 × 48 dp, with at least 8 dp of spacing between adjacent targets. Android runs on an enormous range of hardware — from 360 dp-wide budget phones to 1200 dp+ tablets and foldables. Design components to be adaptable, not fixed to specific pixel sizes.

Web Conventions

Navigation Architecture

Web navigation has deep-rooted conventions. For content-heavy sites with many sections, a persistent horizontal nav bar at the top — with mega menus for large taxonomies — is the expected pattern. Users have over two decades of muscle memory for it. For single-page apps and tools, a persistent sidebar or top nav with clear active states works well.

Tab bars belong on mobile web, positioned at the bottom to mirror native apps. On desktop breakpoints, those same destinations should appear in a top nav or sidebar rail. Avoid the hamburger menu on desktop: it performs about 39% slower on task completion than visible navigation, and most users simply won’t discover options they can’t see.

Breadcrumbs are still useful for deep hierarchies like e-commerce categories or documentation. They orient users within a structure and provide shortcut navigation — especially important for users who arrive via search engine on an interior page.

Link and Focus Behavior

Web users expect links to be visually distinguishable (not just by color — WCAG 2.2 requires a non-color differentiator for inline text links), the browser back button to work correctly, and URLs to be shareable and bookmarkable. Single-page apps that break the URL model — no deep-linking, broken browser history — violate one of the web’s most fundamental conventions.

Focus management matters just as much. WCAG 2.2 introduced “Focus Not Obscured” (criteria 2.4.11 and 2.4.12): a focused element cannot be completely hidden by a sticky header, cookie banner, or overlapping UI. Use scroll-padding-top to account for sticky headers. In SPAs, manage focus on route transitions by moving it to the new page heading when the user navigates.

Form and Input Patterns

Web forms have a well-established set of conventions: top-aligned persistent labels (never use placeholder text as a label — it disappears when the user starts typing and fails users with cognitive disabilities), inline validation triggered on blur (not on submit), and specific error messages that tell users exactly what to fix and how. Link errors to their inputs using aria-describedby so screen-reader users hear the error.

Password fields should always have a show/hide toggle. Set autocomplete attributes (name, email, current-password, new-password) on every relevant field — they enable browser and password manager autofill, which meaningfully reduces the burden on users.

Desktop Conventions (macOS and Windows)

Menu Bar and Keyboard-First Expectations

Desktop users expect a persistent application menu (File, Edit, View, and so on on macOS; a ribbon or menu bar on Windows). They expect keyboard shortcuts for every common action — and they expect those shortcuts to follow platform norms: Cmd+Z for undo on macOS, Ctrl+Z on Windows. Right-click context menus should expose contextual actions that would otherwise be buried.

Desktop screen real estate makes higher information density appropriate and expected. Where mobile hides secondary content behind modals and sheets, desktop surfaces it in sidebars, inspector panels, and split views. Multi-column layouts, resizable panes, and drag-and-drop between areas are first-class desktop behaviors.

Window Management and Focus

macOS and Windows have different ideas about window management. macOS uses traffic-light controls (close, minimize, full-screen) and has no maximize button in the Windows sense — full-screen mode opens a separate space. Windows apps typically fill the screen or follow the standard maximize/restore pattern.

Both platforms require robust keyboard navigation. Every interactive element must be reachable with Tab, and every action must be triggerable with Enter or Space. The inert HTML attribute — now broadly supported — is the modern way to trap focus inside a modal. It removes all descendants from the tab order and accessibility tree, replacing the hacky tabindex loops that break screen readers.

Cross-Platform Design Tokens and Consistency

A shared design token system makes cross-platform consistency manageable. Design tokens are named variables for visual values like color, spacing, and typography. The W3C Design Token Community Group (DTCG) stable JSON format — using $value and $type keys — provides a single source of truth that can be transformed into iOS Swift constants, Android resource XML, web CSS custom properties, and desktop platform values from one file.

The three-tier model works like this: primitive tokens hold raw values, semantic tokens give those values purpose-based names like color.surface.primary, and component tokens are the most specific — like button.background.rest. Each platform inherits shared semantics and renders them appropriately. A semantic token for “elevated surface” maps to a distinct value on iOS (system groupedBackground), Android (M3 surface container), web (a CSS custom property), and dark mode on each — all from one token definition.

This replaces the old approach of maintaining separate hardcoded token files per platform, which drift apart within weeks and create visual inconsistencies that users notice even if they can’t name them.

Testing Across Platforms

Designing for platform conventions means testing on real devices, not just browser emulation. Browser DevTools and emulators are useful for checking layouts, but they don’t replicate:

• iOS Dynamic Type at maximum accessibility size
• Android back gesture behavior
• System-level dark mode switching
• Platform keyboard navigation (especially critical on desktop)
• Safe-area insets on notched and punch-hole devices

A minimal device test matrix for a typical cross-platform product: one recent iPhone (notched or Dynamic Island), one recent Android mid-range device, a tablet (iPad or Android), and a 1080p desktop browser on both macOS and Windows. Add screen-reader testing — VoiceOver on iOS and macOS, TalkBack on Android, NVDA or JAWS on Windows — for any accessibility work.