Design differences between iOS and Android

In short

When you build an app for two platforms, you work with two rulebooks. For iOS there are Apple’s Human Interface Guidelines (HIG); for Android, Google’s Material Design 3 (M3).

On basics such as legible type and comfortable touch targets, both reach the same result. The real differences lie where users’ hands are used to something. Where is back, and where does the main action go?

I opened the current pages of both sources and compared them. I give dates as they appear in the source, because both guidelines change often.

Same screen, two platforms

Below is the same screen of a made-up budgeting app. The iOS version is on the left, the Android version on the right. On a phone they stack.

Press “Show differences”. The same element gets the same number on both screens, and the explanation of each difference opens below.

Navigation: tab bar and navigation bar

On both platforms, the main sections sit at the bottom of the screen. The names and rules differ.

Apple wants you to use the tab bar for navigation, not for actions. If you want to do something with the content on the screen, the HIG recommend the toolbar. According to the HIG, the tab bar on iOS floats above the content at the bottom of the screen.

Apple gives no fixed number of tabs for the iPhone. The HIG only say that navigation is usually easier with few tabs. They also advise against a “More” tab that collects overflow tabs.

In Material 3, the counterpart is the navigation bar. M3 writes that this bar gives access to three to five destinations.

If there are fewer than three destinations, M3 recommends tabs. If there are more than five, you shouldn’t use the navigation bar at all.

Both guidelines want short labels. The HIG say one word where possible; M3 says one to two words. According to M3, the label isn’t removed, truncated or shrunk to make it fit.

English labels can get long too, think of “Notifications” or “Recent transactions”. This rule forces you to look for a shorter word. That is why the demo uses Home, Budget, Goals and Profile.

Hamburger menu and navigation drawer

In Android apps you often see the navigation drawer that opens from the left. M3’s current drawer page says that the drawer is no longer recommended with the M3 Expressive update. Instead, the expanded navigation rail is recommended.

The navigation bar page dates this update to May 2025. According to the same page, the previous navigation bar has made way for a shorter, flexible bar.

In Material 2, this bar was called “bottom navigation”. In M3 it is called the navigation bar. Keep that in mind when you look at an older Android design.

The general navigation patterns are covered in the mobile app design guide. Here I only collect the places where the two platforms part ways.

Back behaviour: system back and edge swipe

For me, this is the most important difference between the platforms. To go back, users don’t think; the hand makes the familiar movement.

On iOS, back is a button. The HIG toolbar page says to use the standard Back button and not to write “Back” on it. This button takes users one step back in the information hierarchy.

Swiping from the edge is a shortcut for it. According to the HIG gestures page, many apps offer a shortcut gesture such as swiping from the edge of the screen while keeping the Back button. So the gesture doesn’t replace the button.

On Android, back is a system gesture. According to M3’s gestures page, users swipe left or right on certain components to return to the previous destination. M3 calls this gesture predictive back.

Users can decide before they finish the swipe. They either move to the previous view or stay on the current screen. The left button in the top app bar in M3 is either a back arrow or a menu icon.

My practical conclusion: on Android I don’t put a custom horizontal swipe gesture on the screen edges. For iOS too, the HIG advise against custom gestures that conflict with system gestures.

Main action: FAB and toolbar

Android’s best-known element is the floating action button (FAB). According to M3, the FAB is meant for the most important action on a screen and sits in front of all other content.

M3 sets some clear rules for the FAB:

• A screen doesn’t have multiple FABs.
• It isn’t used for minor or destructive actions such as archiving, deleting, alerts or errors.
• On phone-sized screens it usually sits at the bottom right, above the navigation bar.
• The medium FAB is recommended for most cases. The small FAB is no longer recommended.

In the HIG pages I opened, there is no component equivalent to the FAB. According to the toolbar page, a single main action such as “Done” or “Send” goes on the trailing (right) side of the toolbar.

When an Android design moves to iOS, the round button at the bottom right often just stays put. That is a mistake I see often. To me, on an iOS screen it looks as if someone forgot it from Android. It is more natural to move the main action to the top right or into the content.

Why the bottom right corner is close to the thumb is explained on the thumb zone page.

Alert and dialog

Both guidelines want you to use dialogs sparingly. They differ in the number and order of buttons.

According to the HIG, an alert has a title, an optional message and at most three buttons. The title shouldn’t run over two lines, and the button label should be one or two words.

When the buttons sit side by side, Cancel is usually first (on the left). When they are stacked, Cancel usually moves to the bottom.

Apple also says not to show an alert for common actions that can be undone. An alert when the app starts isn’t recommended either.

In M3, a dialog has at most two actions. The buttons gather at the right edge of the dialog, with the confirming button closest to the edge. A dismissive action such as Cancel goes to its left.

M3 also advises against vague questions such as “Are you sure?” in the title. The title “Delete expense?” in the demo therefore says clearly what will happen.

For low- or medium-priority information, M3 recommends a snackbar instead of a dialog. When a dialog is needed is covered on the modal and pop-up pattern page.

Typography: SF Pro and Roboto

According to the HIG, SF Pro is the system font of iOS and iPadOS. Apple gives 17 pt as the default font size and 11 pt as the minimum size on these platforms.

On iOS, text size is in users’ hands. With the system feature Dynamic Type, people can make text on the device larger or smaller. The HIG write that you get this support when you use the system font with text styles.

According to M3, Roboto is the default font of Android and of the M3 type scale. Roboto contains more than 3,300 glyphs. For languages Roboto doesn’t cover, the Noto Sans family covers all modern and historical languages.

You can also use a single brand font on both platforms. With such a choice, I first test the largest text sizes. Then I check whether long labels such as “Notification settings” break the screen.

Touch targets: 44 pt and 48 dp

Here the difference is small. The HIG give 44 × 44 pt as the default size for controls on iOS and 28 × 28 pt as the minimum. M3 recommends touch targets of at least 48 × 48 dp and writes that this is about 9 mm.

The same M3 page notes that iOS recommends 44. The units differ, but both guidelines are talking about the same finger.

The sizes in detail and the WCAG side are explained on the touch target page; I don’t repeat them here.

Permission requests

On iOS, a system window asks for a permission such as location or microphone. What is in your hands is when and with which sentence the permission is requested.

The HIG privacy page is clear. Ask for the permission when people actually use the feature that needs it. Don’t ask at launch unless the app doesn’t work at all without this permission.

Apple also gives an example of the explanatory sentence in the permission window. A short, complete sentence in the active voice is wanted. Apple shows a vague reason such as “Microphone access is needed for a better experience” as a bad example.

If you show a screen of your own before the system window, the HIG want a single button there. It should say something like “Continue” and open the system window.

Don’t write “Allow” on this screen. Apple counts that as a form of manipulation, because people might then tap the Allow button in the system window without meaning to.

In the Material 3 pages I opened, I found no section on permission requests. On Android I apply the same timing rule: the permission is requested at the moment it is needed, with a sentence that says why. More on this on the permission and notification screens page.

One design or two?

Even if you build both apps from one codebase, I advise against using a single design unchanged on both platforms.

I split the elements on the screen into two groups. Where the brand is visible, things can stay shared: colours, cards, illustrations, content. Where the hand acts out of habit, things are split by platform: back, main navigation, dialog buttons and main action.

The reason is simple: users expect in your app what they have learned in other apps. This idea is called Jakob’s law. iPhone users have learned the back gesture in other iOS apps and try it in yours too.

I also test accessibility settings such as screen readers and larger text separately on both devices. I cover that in the guide to mobile app accessibility.

My note

What I often see: the team draws the design with the habits of their own phone, and the other platform is “adapted” later. Usually only colours and icons are adapted, while back and the dialog buttons stay where they were.

That is why, for an app on two platforms, I first look at a recording of the same flow on both devices side by side. The five points in the demo above are the first lines of my checklist.

If you want to design both platforms together and bring them into code, the Design & Ship Sprint is made for exactly that. It takes 2 weeks, and design and code go into your repository together.