I've watched designers spend weeks agonizing over iOS vs Android differences that users never notice. I've also seen apps tank because they ignored differences that actually matter.

Here's what I've learned: about 20% of platform differences are worth your attention. The rest is noise. This guide focuses on the 20%.

The stuff that actually matters

Navigation patterns

This is the big one. Get it wrong and your app feels broken on one platform.

iOS uses edge swipes. Users swipe from the left edge to go back. It's muscle memory at this point. If your iOS app doesn't support this, it feels cheap.

Android has a back button (or gesture, depending on the phone). It's system-level, so you don't build it into your UI. But you do need to think about where "back" should take users—Android's back can exit your app entirely if you're not careful.

The practical difference: iOS apps need a back button in the UI (usually top-left) AND edge swipe support. Android apps rely on the system back button, so you skip the UI button but need to handle the back stack properly.

iOS Navigation Structure:
┌─────────────────────────┐
│ ← Back    Title    Edit │  ← Back button in UI
├─────────────────────────┤
│                         │
│       Content           │
│                         │
├─────────────────────────┤
│  Tab  Tab  Tab  Tab     │  ← Bottom tabs common
└─────────────────────────┘

Android Navigation Structure:
┌─────────────────────────┐
│ ☰  Title              ⋮ │  ← Hamburger or drawer
├─────────────────────────┤
│                         │
│       Content           │
│                         │
├─────────────────────────┤
│  Tab  Tab  Tab  [FAB]   │  ← FAB for primary action
└─────────────────────────┘

Primary actions

iOS: Primary actions go in the navigation bar (top-right) or as prominent buttons in the content area. There's no equivalent to Android's FAB.

Android: The Floating Action Button (FAB) is the standard way to highlight one primary action per screen. It sits bottom-right, floats above content, and screams "tap me."

I'd argue Android's approach is cleaner here. The FAB makes the primary action obvious. iOS apps sometimes bury important actions in nav bars where they're easy to miss.

Typography

iOS default: SF Pro. It's a good font. Clean, readable, works at small sizes.

Android default: Roboto. Also good. Slightly rounder than SF Pro.

Here's the thing — most users won't notice if you use the "wrong" system font (we go deep on this in our app typography guide for iOS and Android). What they will notice:

Text that's too small (under 14px for body copy)
Poor contrast (light gray on white backgrounds)
Inconsistent sizing (random font sizes throughout the app)

The typography differences that matter are about sizing conventions, not the fonts themselves.

iOS text sizes (points):

Large title: 34pt
Title: 28pt
Body: 17pt
Caption: 12pt

Android text sizes (sp):

Headline: 24sp
Title: 20sp
Body: 16sp
Caption: 12sp

Notice iOS body text is slightly larger. Apple's guidelines assume users hold phones a bit further away. I'm not sure if that's true, but the sizes work.

Buttons and touch targets

Both platforms agree: touch targets should be at least 44x44 points (iOS) or 48x48 dp (Android). Anything smaller and users will mis-tap, especially on smaller phones.

Where they differ:

iOS buttons tend to be text-only or lightly styled. The "system button" is just blue text. Filled buttons exist but they're not as common outside of CTAs.

Android buttons follow Material Design, which has distinct filled, outlined, and text button variants. They're more visually prominent.

My take: Android's approach is more accessible. It's clearer what's tappable. iOS sometimes relies too heavily on users knowing that blue text means "button."

Bottom sheets vs action sheets

Both platforms love sliding panels from the bottom. They just call them different things and style them differently.

iOS Action Sheets have a specific look: grouped options with rounded corners, a cancel button at the bottom, and that frosted glass effect.

Android Bottom Sheets are more flexible. They can contain anything—forms, lists, images. They often have a drag handle at the top.

The difference matters for complex interactions. Android's bottom sheets can replace entire screens. iOS action sheets are meant for simple choices.

Status bar and safe areas

iOS: The notch and Dynamic Island. Your UI needs to avoid these areas. Use safe area insets. Apple has clear guidelines here and will reject apps that ignore them.

Android: More variety in screen shapes. Hole-punch cameras, pill-shaped cutouts, traditional notches. Test on multiple devices or you'll have content hiding behind camera holes.

Stuff that matters less than designers think

Exact component styling

I've seen designers spend hours matching iOS's exact blur values or Android's precise elevation shadows. Users don't care. A bottom sheet that's functional beats a pixel-perfect one that shipped late.

Platform-specific iconography

Yes, iOS uses SF Symbols and Android has Material Icons. Yes, there are slight style differences. But unless you're designing a system app, users adapt quickly to whatever icon style you use.

The exception: navigation icons. Use the platform's standard back arrow, share icon, and settings gear. Those should feel native.

Animation curves

Apple has specific easing curves. Material Design has its own. In practice, any smooth animation that takes 200-400ms feels fine on both platforms.

Exact color values

Material Design has that whole color system with primary, secondary, tertiary colors and tonal palettes. It's well thought out but not mandatory.

Use colors that work for your brand. Make sure contrast ratios pass accessibility standards. That's what matters.

When to ignore the guidelines entirely

Sometimes the "wrong" approach is better.

Cross-platform apps: If you're building with React Native or Flutter and targeting both platforms, some consistency makes sense. A unified design is easier to maintain than two divergent ones. Just handle navigation properly for each platform.

Apps with strong brand identity: Instagram, Spotify, and Airbnb look essentially the same on iOS and Android. Their brand is more important than platform conventions. If you're building a consumer app with a strong visual identity, this might be your path too.

B2B and enterprise apps: Your users care about functionality, not platform purity. A consistent experience across devices makes training easier.

MVPs and early-stage products: Ship something. Learn what users actually need. Polish platform-specific details later when you have traction.

The practical approach

Here's how I'd prioritize platform differences for a new app:

Get right from day one:

Navigation (back gestures, system integration)
Safe areas and screen shape handling
Minimum touch target sizes
Text legibility at all sizes

Address when you have resources:

Platform-specific primary action patterns (FAB vs nav bar)
System fonts instead of custom fonts
Native-feeling component styling

Ignore unless you're building a system app:

Exact animation curves
Precise color matching to guidelines
Every nuance of the HIG and Material specs

Testing reality

Your designs will look different on real devices than in Figma. Always test on:

A recent iPhone (for iOS safe areas and gestures)
A recent Android phone (for navigation and Material behaviors)
An older/cheaper Android phone (for performance and various screen shapes)

That third one catches problems designers miss. Half the Android market uses mid-range devices with slower processors and weird screen ratios.

For a practical reference of patterns that work well on both platforms, see our mobile UI patterns guide.

Tools that help

GenDesigns can generate designs following iOS or Android conventions. You can describe your app and specify the target platform to get convention-appropriate screens. Specify the platform in your prompt:

Design a fitness app following iOS Human Interface Guidelines.
Include: dashboard, workout detail, and settings screens.
Use SF Pro typography and standard iOS navigation patterns.

or:

Design a fitness app following Material Design 3.
Include: dashboard, workout detail, and settings screens.
Use a FAB for starting new workouts.

You'll get platform-appropriate designs without manually checking every guideline.

Design for both platforms: Generate iOS or Android screens from a text description — just specify the platform and GenDesigns applies the right conventions.

The bottom line

iOS and Android are more similar than different. Both have rectangular screens, touch input, and similar capabilities. The meaningful differences are mostly about navigation and primary action patterns.

Design for your users first, platform conventions second. A usable app that bends some guidelines beats a guideline-perfect app that users struggle with.

When in doubt, watch someone use your app. Platform violations that cause confusion are worth fixing. Ones that nobody notices aren't.

Related reading:

App Typography Guide: iOS vs Android - Platform-specific font practices
Mobile UI Patterns 2026 - Cross-platform pattern reference
How to Design a Mobile App with AI - Design for both platforms faster