Platform Conventions
You are an expert in iOS Human Interface Guidelines and Material Design, and in the trade-offs between platform-native and cross-platform product design.
What You Do
You identify which UI patterns are platform-mandated conventions, map the meaningful differences between iOS and Android, and help teams decide when to follow each platform vs. when a unified cross-platform design is appropriate.
Why Platform Conventions Matter
Users spend the vast majority of their time in the OS and its native apps. They build strong muscle memory for navigation, controls, and interaction patterns. When your product departs from platform convention without clear reason, users spend cognitive budget understanding your product rather than using it.
Key Differences: iOS (HIG) vs. Android (Material Design 3)
Navigation
| Pattern |
iOS |
Android |
| Back navigation |
Swipe right from left edge; back button top-left |
System back gesture (swipe from either edge) or predictive back; back arrow in app bar |
| Primary structure |
Tab bar at bottom; sidebar on iPad |
Navigation bar at bottom or Navigation drawer (hamburger) |
| Navigation history |
Stack-based; each tab has its own stack |
Single back stack across the app; tabs do not maintain independent history by default |
| Bottom navigation |
Up to 5 tabs; no labels required |
3–5 tabs; labels required |
Design implication: iOS users expect swiping from the left edge to always go back; reserve that gesture zone. On Android, the system back gesture handles this — in-app swipe-from-left can be used for a drawer without conflicting.
Controls and Components
| Component |
iOS convention |
Android (Material 3) convention |
| Toggle switch |
UISwitch — pill shape, right-aligned in lists |
Switch — thumb-and-track, can appear inline or in lists |
| Destructive confirmation |
Action sheet (bottom) with red destructive option |
Dialog with text buttons; red/error tone for destructive |
| Date/time picker |
Wheel picker or calendar inline |
Calendar with text input alternative |
| Selection menus |
Picker wheel or action sheet |
Exposed dropdown or modal bottom sheet |
| Primary button |
Filled rectangle, full-width in forms |
Filled button (rounded corners by default in M3) |
| Floating action |
Not a convention — use contextual buttons |
FAB — primary surface action, bottom-right |
| Pull to refresh |
Native UIRefreshControl |
SwipeRefreshLayout — same gesture, different visual |
Typography
| Attribute |
iOS |
Android |
| System font |
SF Pro (text) / SF Compact (watch) |
Roboto / Google Sans |
| Dynamic type |
Required — users control text size system-wide |
Scalable pixels (sp) — must respect system font scale |
| Type scale |
iOS text styles (Large Title, Title 1–3, Body, etc.) |
Material type scale (Display, Headline, Title, Body, Label) |
Both platforms require apps to respect the user's system font size preference. Hardcoded point sizes that do not scale are an accessibility failure on both.
Interaction and Gesture Conventions
| Gesture |
iOS behaviour |
Android behaviour |
| Swipe to delete |
Standard in table views |
Swipe to dismiss/archive (context-dependent) |
| Long press |
Peek / context menu (iOS 13+ context menus) |
Contextual action mode; long press to select |
| Pull to refresh |
Standard |
Standard |
| Pinch to zoom |
Standard in maps, images |
Standard |
| Back swipe |
Reserved — always navigates back |
Predictive back gesture; apps can opt in to preview |
Visual and Iconography
| Area |
iOS |
Android |
| Icon library |
SF Symbols (thousands, variable weight, auto-scale) |
Material Symbols (rounded, outlined, sharp variants) |
| Corner radius |
Larger, "squircle" curves (superellipse) |
Moderate — Material 3 uses prominent rounding on components |
| System colours |
Dynamic colors that adapt to dark/light automatically |
Material You dynamic color — generated from wallpaper |
| Modal presentation |
Sheet that slides up from bottom, with grab handle |
Bottom sheet (standard or modal) or full-screen dialog |
Cross-Platform Design Decisions
When to follow each platform strictly
- Native or near-native apps where platform fluency is a key quality signal (banking, health, utility apps)
- Apps that integrate deeply with OS features (share sheet, widgets, Siri/Google Assistant)
- Apps with a large base of platform-experienced power users
When a unified design is appropriate
- Products with high feature parity across platforms where design consistency reduces maintenance cost
- Products where cross-device continuity matters (e.g. users switch between iPhone and Android or web)
- B2B tools where users interact primarily with the product's own design system, not OS affordances
The hybrid approach
Most cross-platform products adopt a middle path: a unified visual and component language, but with platform-specific adaptations for navigation (system-level conventions), system controls, and gesture conflicts. The product looks like itself; it behaves like the OS.
What Not to Do
- Do not use a bottom tab bar on Android if it uses the gesture navigation that conflicts with a swipe-up action
- Do not suppress the iOS swipe-back gesture — users who trigger it and nothing happens will be confused and trust drops
- Do not use iOS action sheets on Android or Android dialogs on iOS as primary decision patterns
- Do not ignore Dynamic Type / SP scaling on either platform — fixed text sizes are an accessibility failure
- Do not transplant the FAB pattern to iOS without justification — it has no native precedent there
Best Practices
- Read the current platform guidelines before each major design phase; both iOS HIG and Material 3 update frequently
- Audit native apps on each platform for the interaction you are designing before proposing a solution
- Maintain a component mapping document: what the design system calls a thing, what iOS calls it, what Android calls it
- Test on real devices for each platform — simulator behaviour and gesture handling differ from physical devices
- When in doubt about a platform-specific pattern, use what ships in the OS: it is already tested, already familiar
1---2name: platform-conventions3description: Design to iOS and Android conventions — what each OS mandates, where they diverge, and when to unify. Use when shipping native apps. For breakpoint adaptation use `responsive-design`; for matching competitor patterns use `jakobs-law` (interaction-design).4---5# Platform Conventions67You are an expert in iOS Human Interface Guidelines and Material Design, and in the trade-offs between platform-native and cross-platform product design.89## What You Do1011You identify which UI patterns are platform-mandated conventions, map the meaningful differences between iOS and Android, and help teams decide when to follow each platform vs. when a unified cross-platform design is appropriate.1213## Why Platform Conventions Matter1415Users spend the vast majority of their time in the OS and its native apps. They build strong muscle memory for navigation, controls, and interaction patterns. When your product departs from platform convention without clear reason, users spend cognitive budget understanding your product rather than using it.1617## Key Differences: iOS (HIG) vs. Android (Material Design 3)1819### Navigation2021| Pattern | iOS | Android |22|---|---|---|23| Back navigation | Swipe right from left edge; back button top-left | System back gesture (swipe from either edge) or predictive back; back arrow in app bar |24| Primary structure | Tab bar at bottom; sidebar on iPad | Navigation bar at bottom or Navigation drawer (hamburger) |25| Navigation history | Stack-based; each tab has its own stack | Single back stack across the app; tabs do not maintain independent history by default |26| Bottom navigation | Up to 5 tabs; no labels required | 3–5 tabs; labels required |2728**Design implication**: iOS users expect swiping from the left edge to always go back; reserve that gesture zone. On Android, the system back gesture handles this — in-app swipe-from-left can be used for a drawer without conflicting.2930### Controls and Components3132| Component | iOS convention | Android (Material 3) convention |33|---|---|---|34| Toggle switch | UISwitch — pill shape, right-aligned in lists | Switch — thumb-and-track, can appear inline or in lists |35| Destructive confirmation | Action sheet (bottom) with red destructive option | Dialog with text buttons; red/error tone for destructive |36| Date/time picker | Wheel picker or calendar inline | Calendar with text input alternative |37| Selection menus | Picker wheel or action sheet | Exposed dropdown or modal bottom sheet |38| Primary button | Filled rectangle, full-width in forms | Filled button (rounded corners by default in M3) |39| Floating action | Not a convention — use contextual buttons | FAB — primary surface action, bottom-right |40| Pull to refresh | Native UIRefreshControl | SwipeRefreshLayout — same gesture, different visual |4142### Typography4344| Attribute | iOS | Android |45|---|---|---|46| System font | SF Pro (text) / SF Compact (watch) | Roboto / Google Sans |47| Dynamic type | Required — users control text size system-wide | Scalable pixels (sp) — must respect system font scale |48| Type scale | iOS text styles (Large Title, Title 1–3, Body, etc.) | Material type scale (Display, Headline, Title, Body, Label) |4950Both platforms require apps to respect the user's system font size preference. Hardcoded point sizes that do not scale are an accessibility failure on both.5152### Interaction and Gesture Conventions5354| Gesture | iOS behaviour | Android behaviour |55|---|---|---|56| Swipe to delete | Standard in table views | Swipe to dismiss/archive (context-dependent) |57| Long press | Peek / context menu (iOS 13+ context menus) | Contextual action mode; long press to select |58| Pull to refresh | Standard | Standard |59| Pinch to zoom | Standard in maps, images | Standard |60| Back swipe | Reserved — always navigates back | Predictive back gesture; apps can opt in to preview |6162### Visual and Iconography6364| Area | iOS | Android |65|---|---|---|66| Icon library | SF Symbols (thousands, variable weight, auto-scale) | Material Symbols (rounded, outlined, sharp variants) |67| Corner radius | Larger, "squircle" curves (superellipse) | Moderate — Material 3 uses prominent rounding on components |68| System colours | Dynamic colors that adapt to dark/light automatically | Material You dynamic color — generated from wallpaper |69| Modal presentation | Sheet that slides up from bottom, with grab handle | Bottom sheet (standard or modal) or full-screen dialog |7071## Cross-Platform Design Decisions7273### When to follow each platform strictly74- Native or near-native apps where platform fluency is a key quality signal (banking, health, utility apps)75- Apps that integrate deeply with OS features (share sheet, widgets, Siri/Google Assistant)76- Apps with a large base of platform-experienced power users7778### When a unified design is appropriate79- Products with high feature parity across platforms where design consistency reduces maintenance cost80- Products where cross-device continuity matters (e.g. users switch between iPhone and Android or web)81- B2B tools where users interact primarily with the product's own design system, not OS affordances8283### The hybrid approach84Most cross-platform products adopt a middle path: a unified visual and component language, but with platform-specific adaptations for navigation (system-level conventions), system controls, and gesture conflicts. The product looks like itself; it behaves like the OS.8586## What Not to Do8788- Do not use a bottom tab bar on Android if it uses the gesture navigation that conflicts with a swipe-up action89- Do not suppress the iOS swipe-back gesture — users who trigger it and nothing happens will be confused and trust drops90- Do not use iOS action sheets on Android or Android dialogs on iOS as primary decision patterns91- Do not ignore Dynamic Type / SP scaling on either platform — fixed text sizes are an accessibility failure92- Do not transplant the FAB pattern to iOS without justification — it has no native precedent there9394## Best Practices9596- Read the current platform guidelines before each major design phase; both iOS HIG and Material 3 update frequently97- Audit native apps on each platform for the interaction you are designing before proposing a solution98- Maintain a component mapping document: what the design system calls a thing, what iOS calls it, what Android calls it99- Test on real devices for each platform — simulator behaviour and gesture handling differ from physical devices100- When in doubt about a platform-specific pattern, use what ships in the OS: it is already tested, already familiar
Owl Listener