By Mehdi HassanWhat are the main differences between iOS and Android design?
The main differences between iOS and Android design are how people move back and between sections, which system controls they expect, the default type and icon sets, the units used for sizing, and how each platform handles color and depth. Everything else, your brand, your layout grid, your content and your copy, can and should be shared.
Apple documents its rules in the Human Interface Guidelines. Google documents Android's in Material Design, now in its third generation (Material 3, with the Material 3 Expressive update). Both are long, and most of their pages describe details a startup app never touches. This guide skips the trivia and covers the differences that actually change screens in a cross-platform product. For the full process from idea to store listing, start with our mobile app design guide.
Area | iOS (Human Interface Guidelines) | Android (Material 3) |
|---|---|---|
Going back | Back button top-left plus swipe from the left edge | System back gesture or button, available everywhere |
Top-level navigation | Bottom tab bar | Bottom navigation bar; navigation rail on larger screens |
Primary action | Usually in the navigation bar or inline | Often a floating action button |
System font | SF Pro | Roboto (or the device's system font) |
Icon set | SF Symbols | Material Symbols |
Sizing unit | Points (pt) | Density-independent pixels (dp) |
Minimum touch target | 44x44pt | 48x48dp |
Color and depth | Translucent materials (Liquid Glass since iOS 26) | Tonal surfaces and dynamic color from the wallpaper |
Transient messages | Rarely used; alerts or inline status | Snackbars at the bottom of the screen |
How does navigation differ between iOS and Android?
Navigation differs mainly in how people go back. On iOS, back is part of your interface: a back button sits in the top-left of the navigation bar, and users can swipe from the left edge to return. On Android, back belongs to the system: a gesture from either screen edge, or a button on older devices, works in every app, and Android's predictive back shows a preview of where the gesture will land.
That has two practical consequences. First, don't put a custom back arrow on Android screens that already respond to system back, and don't rely on the system to provide one on iOS. Second, test what back does on every Android screen, including modals, bottom sheets and multi-step forms, because users will trigger it anywhere. A back gesture that silently discards a half-filled form is one of the most common Android bugs in cross-platform builds.
Top-level navigation is closer than it used to be. Both platforms now favor a bottom bar with three to five destinations for phone apps. Android adds the navigation rail for tablets and foldables. We compare tab bars, drawers and gesture-led layouts in detail in our guide to mobile navigation patterns.
Which controls and components should be platform-specific?
System controls should be platform-specific: date and time pickers, alerts and dialogs, action menus, share sheets, switches and permission prompts. Users have used these thousands of times in other apps, so a native version feels instantly familiar and a custom one feels off, even if they can't say why.
- Alerts and dialogs: iOS alerts center the title and stack or split buttons; Material dialogs left-align text and put text buttons at the bottom right.
- Action menus: iOS uses action sheets and context menus that rise from the bottom or the touched element; Android uses menus anchored to the trigger and bottom sheets.
- Pickers: use the native date, time and list pickers. Rebuilding them costs time and loses accessibility features for free.
- Switches and checkboxes: iOS settings lean on switches; Material uses switches for instant on/off and checkboxes for selections that are confirmed later.
- Sheets: both platforms have bottom sheets, but iOS sheets snap to set heights and sit above a dimmed screen, while Material sheets can be standard (non-blocking) or modal.
Your own components, cards, list rows, empty states, charts and onboarding screens, can be identical on both platforms. That is where your brand lives, and it's what users remember.
How do typography, icons and sizing differ?
iOS uses San Francisco (SF Pro) as its system font and SF Symbols for icons, and it sizes everything in points. Android uses Roboto or the device's system font, Material Symbols for icons, and density-independent pixels. Both platforms support dynamic type, so text sizes follow the user's accessibility settings.
For a branded app, you can use your own typeface on both platforms. Just make sure it scales with the system text-size setting, because many people change it and fixed-size text is an accessibility failure on both stores. Keep icons in one consistent set: mixing SF Symbols on iOS with a custom set elsewhere in the same app looks unfinished.
On sizing, Apple's guidelines ask for touch targets of at least 44x44 points and Material asks for 48x48dp. Designing every tappable element to the larger figure satisfies both and removes a whole category of platform variants. Spacing scales also travel well: an 8-point grid maps cleanly to both.
How do color, depth and motion differ?
iOS expresses depth through translucent materials and blur. Since iOS 26, Apple's Liquid Glass material is used for tab bars, toolbars and controls that float over content. Material 3 expresses depth through tonal surface colors and elevation, and on recent Android versions it can generate a color scheme from the user's wallpaper, which Google calls dynamic color.
For a startup app, the honest advice is to let the system chrome follow each platform (the tab bar, navigation bar and system sheets) and keep your brand color for your own content and key actions. Opting your whole app into wallpaper-based dynamic color is a brand decision: it feels very native on Android, but it means your primary color changes per user. Most brands use it for surfaces and keep a fixed accent.
Motion follows the same logic. Use each platform's default transitions for pushing screens and presenting sheets, and save custom animation for moments that belong to your product, such as a completed task or a chart that fills in.
How should a cross-platform app handle iOS vs Android design?
A cross-platform app should use one design system with a short, explicit list of platform variants. Shared: brand, color tokens, type scale, spacing, custom components, content and copy. Platform-specific: back behavior, system controls, sheet and menu styles, icon set if you use system icons, and permission prompts.
Design one core flow on your main platform first
Pick the platform most of your early users are on and design the main flow end to end. This is where layout and content decisions happen.
List the platform variants
Go screen by screen and mark anything that is a system control or navigation chrome. That list is usually short: a dozen components, not a second app.
Build the variants as component properties
In Figma, add an iOS/Android property to those components rather than duplicating screens. Developers then see exactly what changes.
Prototype back behavior on Android
Walk every Android screen and decide what system back does: close, go up, or ask before discarding work.
Test on real devices
Check both platforms at the largest system text size and with screen readers on. That's where most platform issues show up.
Your framework affects how much of this is automatic. React Native and Flutter handle some platform conventions for you and leave others to the team, which we cover in React Native vs Flutter for startups.
For example, suppose you're designing a habit tracker for both platforms
For example, suppose a two-founder team is designing a habit tracker. Shared across both platforms: the onboarding screens, the daily check-in card, the streak chart, the brand color and type, and every line of copy. Platform variants: the tab bar (Liquid Glass on iOS, a Material navigation bar on Android), the reminder time picker (native on each), the delete-habit confirmation (iOS alert vs Material dialog), and the back behavior inside the add-habit flow.
That comes to roughly ten components with an iOS/Android property, not two parallel design files. It's a hypothetical, but it shows a sensible way to split the work.
When should you design separately for each platform?
You should design separately for each platform only when the product depends on platform features: widgets, Live Activities, watch apps, deep system integrations, or tablet and foldable layouts that change the information architecture. In those cases, the platform shapes the feature, not just its chrome.
For most startup apps, a single design with variants is cheaper, faster to change and more consistent for your brand. It also keeps the scope of design work honest: if a quote prices two full sets of screens for a simple app, ask what's actually different. Our breakdown of mobile app design cost shows how platform scope changes the budget, and how to design a mobile app walks the full process for non-designers.
