Those expectations come from years of using one platform. Respect them, and your app feels natural from the first tap. Ignore them, and it feels slightly wrong in a way users can’t explain, but definitely notice.
We design and build iOS apps at OSAM, and we think about platform conventions on every project. Here’s what every UX/UI designer should know about designing for iOS and Android: the current design languages, the differences that matter most, and how to keep one brand across both.
Two design languages, two personalities
Both platforms went through major redesigns in 2025, and both now feel more different from each other than they have in years.
- iOS: Liquid Glass. With iOS 26, Apple replaced the flat style it had used since iOS 7 with Liquid Glass, a translucent, layered material inspired by visionOS. Controls, tab bars and toolbars float above content and catch light as you move. The philosophy: content first, controls quietly in the background, one consistent look across iPhone, iPad, Mac and Watch.
- Android: Material 3 Expressive. Google’s update to Material 3 arrived with Android 16 on Pixel phones and is spreading through Google’s own apps. It goes the other way: bolder shapes, emphasized typography, richer dynamic color, springy motion and haptics. Google says it’s backed by extensive user research. The philosophy: personality, emotion and strong hierarchy, with plenty of room for customization.
In short: iOS gets calmer and more transparent, Android gets bolder and more playful. One more thing to remember about Android: phone makers like Samsung can apply their own interface on top, so Android apps may meet more visual variety than iOS apps do.
The differences that matter most
A few of these deserve extra attention:
- Back navigation. This is the number one source of "something feels off." Android users rely on the system back gesture everywhere, so every screen must respond to it predictably. iOS users expect the edge swipe and a visible back button in the top left. Never block the gesture users rely on.
- Navigation patterns. A hamburger menu that’s acceptable in some Android contexts can hide key features on iOS, where users expect the main sections in a bottom tab bar.
- Primary actions. A floating action button feels at home on Android. On iOS it can look like an Android port. Place the main action where iOS users look for it.
- Sizing. Design at 1x in pt or dp and let the platform handle screen density. Mixing units between platforms is one of the fastest ways to get blurry icons and wrong spacing in development.
Here is how the two platforms compare at a glance:
| iOS | Android | |
|---|---|---|
| Units | Points (pt) | Density-independent pixels (dp), text in sp |
| Minimum touch target | 44 × 44 pt | 48 × 48 dp |
| System font | San Francisco (SF Pro) | Roboto by default |
| Main navigation | Tab bar at the bottom | Navigation bar at the bottom, rail or drawer on larger screens |
| Going back | Back button top left, swipe from the left edge | System back gesture or button, handled by the OS |
| Primary action | In the navigation bar or inline | Often a floating action button |
| Screen titles | Large titles that collapse on scroll | Top app bar, title aligned left |
| Choices and confirmations | Alerts and action sheets | Dialogs, bottom sheets, snackbars |
One design or two?
The classic question: do you design one interface for both platforms or two separate ones? The honest answer is somewhere in between. Keep shared:
- brand: colors, typography for headings, illustrations, tone of voice
- information architecture: what’s in the app and where it lives
- core flows: the steps to sign up, buy, book or scan
- custom content screens that are unique to your product
Adapt per platform:
- navigation and back behavior
- system components: switches, pickers, alerts, sheets, share flows
- placement of primary actions
- platform features like widgets, Live Activities on iOS or dynamic color on Android
Think of it as one product speaking two dialects. Users should recognize your brand instantly, while the app still behaves the way their phone has taught them to expect.
A practical workflow: design the main platform first, build a shared component library, then create platform-specific variants only where behavior really differs. It saves time and keeps both versions consistent.
Common mistakes
- Designing only on an iPhone mockup. Many designers work on Macs and iPhones, then ship the same screens to Android. Android users notice immediately.
- Copying one platform’s components onto the other. iOS-style switches and alerts on Android, or Material buttons and FABs on iOS, make an app feel like a cheap port.
- Ignoring the back gesture. Custom back buttons that fight the system behavior frustrate users on both platforms.
- Forgetting the screen variety. Android runs on a huge range of sizes, aspect ratios and foldables. Test layouts at the extremes, not just one standard device.
- Fighting the new design languages. Custom controls that ignore Liquid Glass or Material 3 Expressive can look dated next to system apps. Start with native components and customize carefully.
- Tiny touch targets. Small icons with tiny tap areas break the minimum sizes on both platforms and hurt accessibility.
- No dark mode. Both platforms support it system-wide. An app that ignores it stands out for the wrong reasons.
- Skipping the guidelines. Apple’s Human Interface Guidelines and Google’s Material guidelines are free. Reading them is the fastest way to stop guessing.