Unraveling Generic Contrasts: iOS vs. Android Design Guidelines
Designing a mobile app requires us to pay close attention to every detail. After all, this is the user’s first impression of the product, and it should be both intuitive and user-friendly. Thankfully, both iOS and Android offer extensive and helpful design guidelines to create a smoother, more efficient design process. In this post, we’ll explore the essential guidelines of each system and compare the differences between them.
For a better understanding of each element and more details, explore Human Interface Guidelines and Material Design.
General Guidelines
Apple and Google offer comprehensive guidelines with clear instructions for designers and developers. These guidelines are available for free consultation and serve as valuable resources for design and research purposes. This post is derived from a thorough analysis of these documents.
Measurements and margins
When it comes to designing an application, both for mobile and desktop, it’s important to pay attention to the balanced distribution of elements on the screen. Therefore, we always follow a scale to maintain consistency and logical organization of various components. This includes taking measurements and margins into consideration.
On iOS, the measurements used are in points (pt) instead of pixels because it’s the most appropriate unit of measure for screens. Points ensure consistent layout and size of elements across different resolutions and devices.
The concept of the safe area holds significant importance in iOS design guidelines. It ensures that all elements of the page appear properly visible and usable, regardless of the device or resolution. This way, we can ensure that the design won’t be compromised by the device’s hardware, offering a consistent and immersive experience across a wide range of iOS devices.
Don’t forget to place your interactive elements inside the safe area to assure that they won’t be compromised.
In contrast, the measurements used on Android are in density-independent pixels (dp). This means it allows us to design for different screen densities, much like iOS, to guarantee that everything is in place across multiple devices. To achieve optimal results and precise space distribution, it is highly recommended to follow the Design System grid, based on 8dp. Following this grid system enhances visual harmony and alignment, resulting in a cohesive user interface on Android devices.
Typography
If we want to achieve the native look of an iOS or Android app, there’s a font family recommendation for both of them. These are not mandatory rules and they can be easily adapted and changed according to our app identity.
iOS
Apple provides two main font families: San Francisco and New York. These fonts are designed to match a clear and simple UI while keeping a neutral look. Since they are compatible and complement each other, you can always incorporate both of them and create some diversity and highlights across the platform.
Android
When it comes to picking a font family for Android apps, Roboto is the default option. It’s a simple and clear typeface that provides a fresh and minimalistic look. However, feel free to pick any other font that suits you better. If you need any help, Google Fonts provides you with a large Open Source collection that can be directly downloaded and used on any project.
Now that you’re more familiar with font families, here are a few tips on how to take the best advantage of your font choice:
- don’t be afraid of using different font weights, sizes, or colors to highlight important information;
- less is more, don’t overuse different font families — up to two typefaces is usually the best approach;
- if you use any custom typeface, make sure it is supported by the system and is easily readable in all sizes.
Navigation
iOS
The navigation bar is one of the main components when it comes to creating an app. It is composed of a back button (with a navigation title in some cases), a page title, and an action text button, respectively. You probably already noticed that iOS places its CTA buttons in the upper right corner, in the nav bar, while on Android we can display one or multiple icon buttons for secondary actions.
When it comes to the bottom navigation, tab bars are the ideal approach since it provides us access to different sections of an app. The main point is to flatten the information hierarchy, so we should only display a maximum of 5 tabs. If we come to the conclusion that 5 is not enough, it would be a good idea to reevaluate and consider only the main and most essential options. The order of our tabs shouldn’t be randomly assigned either and there are specific rules for each one of them as well as where they should be placed.
Here are some tips to achieve the desired structure:
- any tab that represents the primary action of the app (e.g.: upload/take a photo) is centered;
- any profile or settings-related tabs appear last;
- search appears second;
Note that these are just overall suggestions and might vary depending on different apps and purposes.
Android
Just like on iOS, the top navigation provides content related to the current screen and displays elements such as the title, navigation/back button, and action buttons. This type of navigation is always present on the screen but can be hidden if there’s any scroll on the page. It should always remain consistent throughout the app.
Unlike iOS, the title of the current page is aligned to the left, and action buttons are icons instead of text labels. It can also contain an overflow menu, on the right side.
Bottom navigation is very similar to iOS and follows the same rule of keeping it simple and don’t overcrowd it with more than 5 tabs. Each tab can be represented by an icon and an optional label.
This type of navigation should be used for destinations that are important to be accessible through the entire app. If there are fewer than 3 tabs, consider using upper tabs instead.
Also keep in mind that:
- the tab bar shouldn’t be used for specific actions within the app — such as editing or deleting content — use the toolbar for that instead;
- don’t hide or change tabs across the platform because the tab bar enables global navigation and it should be always visible and easy to access;
- don't disable tabs when a specific user doesn’t have access to it or there's no content to show — simply provide feedback and explain why there’s no content to show and keep the overall look consistent through the app;
Primary action
As mentioned previously, the primary action button on iOS is placed on the navigation bar, in the upper right corner, and usually is a text or icon button. There’s no particular highlight as we see on Android, where usually we use a floating action button (FAB) to enhance the primary action — such as adding a new file, creating a new message, taking a picture, and so on… It is important to notice that these buttons must always be visible and displayed within the safe usable area of our screen and they shouldn’t be overlapped or hidden by any other element.
It’s also important to mention that these are not strict rules and the placement might vary if needed, according to design or context.
Action menu
Activity View vs. Modal Bottom Sheet
These components, as the name designates, display a list of actions within the app or specific screen. While both share similarities and differences, their main purpose is the same.
Both components are designed to be displayed as a floating area over the main content and slide from the bottom of the screen. This positioning ensures that the actions are easily accessible while allowing the user to maintain context with the page content.
The main difference here is that in Android this menu was recently updated and it’s anchored to the bottom of the screen, whereas iOS shows up as a result of an action and doesn’t have a specific button for it.
Alerts
Alerts show important information and usually request some sort of action or feedback from the user. The elements should be only used in important situations to avoid disrupting the user’s flow more than necessary.
On iOS we have a default alert type that can’t be customized and it works pretty much for all cases. What we get is basically a simple component with a clear short title, a short explanatory message, and buttons (two buttons to provide choice — one button to provide feedback without any control). Sometimes it can contain text fields to gather input, depending on the scenario.
On Android, it can have multiple aspects and each one is used for different purposes. The main feedback providers are Dialogs and Snackbars.
Dialog: Works exactly like on iOS. The only difference might be the visual aspect since it’s adapted to the Android UI.
Snackbar: Snackbars usually provide non-urgent feedbacks or warnings that don’t need to interrupt the user’s flow. They appear at the bottom of the screen and might contain an action button or not.
In the previous version of Material Design (2) it was common to use Banners that have the same purpose as Dialogs and were used for medium-priority alerts. They appear on the top of the screen without obstructing the user’s flow and are displayed until dismissed or solved.
Now that we learned different types of alerts, here are a few tips to design them better:
- generally use two buttons with simple verbs that clearly describe the outcome;
- use OK for feedback-only buttons;
- avoid the use of “Yes” and “No” because that’s not a clear reflection of what the outcome will be;
- keep in mind that people tend to tap on buttons that are on their right so make sure the desired action is placed there;
- cancel button should be placed on the left and always be labeled as “Cancel”;
It is also important to mention that these are the main alerts but both systems evolved over time and new options and versions may be available.
Pickers
Default pickers used for miscellaneous options are pretty similar between both systems. These components can assume different aspects on iOS, depending on the main subject. For example, a date picker can be displayed in a calendar view or a wheel picker.
On Android, we have two separate components: one for date and another for time.
Other pickers, such as language, are very identical in the overall design but on iOS the selection is marked with a check icon and Android uses radio buttons to show our picks. These are some behaviors that have been embraced over time but they can always be modified and adjusted as needed.
In conclusion, understanding the differences between iOS and Android design guidelines is crucial for creating a successful mobile app. Adapting your design to these differences will result in a visually appealing and user-friendly app on both platforms. If you're aiming to know more about each element, consider visiting the official documentation and exploring what interests you the most.
Check the iOS 16 UI Kit and Material 3 Design Kit on Figma Community. There you can find all the components you’ll need to start, and the best part: it’s totally free!
Enjoy and keep designing! ✏️
Deemaze Software is a digital agency developing products for web and mobile. Catch up with us on Twitter, Facebook, Instagram or Linkedin. Let us know if there’s something you want us to write about! 🎈
