Mobile app design guidelines for iOS and Android

Mobile app design guidelines are the published rules for how apps should look and behave on a platform. There are two official sets: Apple's Human Interface Guidelines for iOS and Google's Material Design for Android. Both are long. This page covers the parts that change what you actually draw, and the handful of places where the two platforms disagree.

You don't have to obey every line, and plenty of good apps bend the rules. The guidelines do describe what a great many people already expect a phone to do, though, so each departure should buy you something.

What both platforms agree on

Most of the two documents say the same thing in different words.

Content comes first. Bars, buttons and decoration exist to serve what the person came for and should take as little space as they can.

Controls should look and behave the way they do elsewhere on the phone. A switch should look like a switch. If you invent a new control, people have to learn it, and most won't bother.

Navigation should be shallow and predictable. A few top-level sections sit in a bar at the bottom, deeper screens stack on top, and there's always an obvious way back.

Every action should get a response. Buttons react when pressed, slow operations show progress, and errors say what went wrong and what to do about it.

And the app must work for people who use larger text, a screen reader, or reduced motion. Both platforms build these settings in, and both expect apps to honor them.

Where iOS and Android differ

A few of these deserve more than a table cell.

Back navigation

On iOS, the back control lives in the app: a chevron at the top left with the previous screen's title beside it, plus a swipe from the left edge. On Android, back belongs to the system, and the same gesture works in every app. Android screens often still show an up arrow in the top bar, but you can't rely on people using it. One practical consequence is that a left-edge swipe menu fights the back gesture on both platforms.

The main action

Material Design has the floating action button, a round button that hovers above the content at the bottom right for the screen's main action: compose, add, start. iOS has no direct equivalent. Its apps tend to put "add" in the top bar or in the tab bar, or use a full-width button at the bottom of the content. A floating button on iOS won't break anything, and many cross-platform apps ship one, but it reads as slightly foreign there.

Typography

Each platform's system font is tuned for its screens and wired into the text scaling setting. Using a brand typeface is fine on both, as long as text still scales when someone raises the system text size. Design with that in mind and test your screens at one or two sizes up. Fixed-height rows that clip larger text are a common accessibility bug in shipped apps.

Look and feel

The platforms have their own visual character, and it changes over time. Apple's current design language uses translucent, glass-like bars and controls, and Material's current version leans on bold shapes and color derived from the user's wallpaper. Read the current pages before a big project. Your content area can still look like your brand on both; the system chrome around it is where apps look native or don't.

Accessibility guidelines

Platform guidance and the Web Content Accessibility Guidelines agree on the basics:

• Text contrast of at least 4.5:1 against its background, or 3:1 for large text.
• Tap targets at the platform minimum, with space between them.
• Never color alone to carry meaning. Pair it with an icon or a word.
• Every icon-only button has a label for screen readers.
• Text scales with the system setting without clipping or overlapping.
• Animations are shortened or removed when the user has asked for reduced motion.

Following these also helps people who aren't disabled. Someone reading in bright sun needs the contrast, and someone on a bus needs the larger tap targets.

One design for both platforms

Most teams design once and adjust. What usually stays the same across platforms: the brand colors, the layout of the content, the wording, your own components such as cards and list rows.

What you adapt per platform is a short list. Use the system font unless you have a brand typeface, and follow the platform's back behavior. Take your icons from the platform's set, or from one neutral set used on both. Then decide whether the main action is a floating button on Android and something else on iOS, or the same on both.

If the app is built with a cross-platform framework, the framework's defaults decide much of this for you. Check them on a real device of each kind before you sign off, since a design reviewed only on an iPhone often has small surprises on Android.

Guidelines checklist

• Tap targets at least 44 pt on iOS and 48 dp on Android.
• Body text 16 to 17, scaling with the system setting.
• Bottom navigation with 3 to 5 destinations, on top-level screens only.
• Back works the way the platform's users expect.
• Text contrast of 4.5:1 or better.
• Text and controls inside the safe area.
• Every state designed: loading, empty, error.
• Tested with large text and with a screen reader.

For how these rules turn into actual screens, see the mobile app layout guide and the wider mobile app design guide. If you'd like a starting point that already follows the conventions, Outclass designs screens with a bottom tab bar on top-level screens only and muted text held at 4.5:1 contrast, and you can adjust anything before copying the screens to Figma.