中文版 Original Chinese version published on Dec 10, 2016
There are more and more apps launched for both Android and iOS. But we can find those app design may not tackle or notice the differences between Android and iOS on UI components or behavior patterns. Sometimes we could find the iOS components are used on Android apps or Android patterns are applied on iOS apps. The misused components/patterns may cause users confused.
In order to let the developers or designers understand the basic difference between Android and iOS easier. I would like to introduce and compare the UI patterns/components, which sometime have different names on the two platforms, with some screenshots as examples:
1. Navigation Drawer, Tabs & Bottom navigation VS. Tab Bars
We would like to talk about navigation design first because it is an essential issue about information structure that designers need to tackle when designing apps at beginning.
Navigation drawer was the most representative of Android design on 2013. The category items in the top level of information structure are put into a drawer which can be hidden to make the UIs look simple and clean. But later, with lots of researches revealing the usability issues of navigation drawer appeared, Google was starting to move important features/category items from Navigation drawers to tabs in their apps; Youtube was an example of that. In 2016, bottom navigation appeared in Material Design Guidelines and that shows some UI components in Android is getting closer to iOS ones.
Please note that, there are still some differences between Android tabs and bottom navigation：
- Tabs can be used in higher or lower levels in the hierarchy of information, but Bottom Navigation is only used in the top level.
- Tabs support not only tapping but swiping gesture to switch views, but Bottom Navigation supports tapping only.
- The item amount in Tabs is flexible. You can put 2-5 items in fixed tabs or more items in scrollable tabs. But only 3-5 items can be put into bottom navigation. 2 or above 5 items are forbidden。
In some apps with deep and complicated navigation structures, we may find navigation drawer, bottom navigation and tabs appear at the same time. I do not recommend that navigation drawer and bottom navigation are used in the same time in apps because it is hard to tell the hierarchical structures between them. The level of navigation drawer is higher or lower than bottom navigation? Or they are in the parallel level? The ambiguous structures would confuse users. Google Plus is a negative example for me. I really feel confused after updating Google Plus and then seeing navigation drawer and bottom navigation in the same time at beginning.
By analyzing current Google apps, we could find navigation drawer and bottom navigation are in the parallel level. Take Google Photos and Google Plus as examples, after revealing navigation drawer in the main screen, there is no highlight on any category item. Android seems to put categories like account, settings and other secondary features into a drawer and locate frequently-used/main features into bottom navigation.
iOS has used bottom “tab bars” as a default navigation for a long time and never changed. Tab Bars, just like Android bottom navigation, have 3 to 5 category items and you can switch category views by tapping items.
It is worth noting that tab bars usually exist even you enter the next or deeper levels from the top one. Tapping the highlighted item on the tab bar will bring you back to the top level. Tab bars disappear when you are in modal view or enter detail views with bottom toolbars. However, in Android apps, both tabs and bottom navigation will disappear when you enter the next page in deeper levels.
2. App Bars (Action Bars) VS. Navigation Bars
The bars on the top area of Android app screens are called app bars, a.k.a. action bars and toolbars, which are mainly used to put current screen name or app names and action buttons. The names are put in the left side of action bars and action buttons, which are usually not more than 3, put in the right side. If the actions are more than 3, we would use overflow icon and put the less important actions into the overflow menu.
Both Android and iOS have their own back icon styles. But iOS usually puts a string, back or the name of the previous page beside the back icon, which let users know where they will go back more precisely.
Action buttons can be put on not only action bars/ navigation bars but bottom “toolbars” on both Android and iOS.
Even though the bottom toolbars are not mentioned in Material Design Guidelines (They talk toolbars as app bars only), we still can find the bottom toolbars are used in Google Keep and Google Photos.
Bottom toolbars are one of the common iOS UI components and can be found in many apps. Both icons and text as action buttons and status descriptions can be put in toolbars.
4. Tabs VS. Segmented Controls
Pages in the secondary or lower level of hierarchy can utilize “tabs” on Android and “segmented controls” on iOS apps.
Both Android tabs and iOS segmented controls can be placed in the position of action bar/ navigation bar.
Android tabs can be with text only, with icons only or with both icons and text, which are rarely found in current apps. Both icons and text can be put into iOS segmented controls. Mixing text and icons in a segmented control should be avoided.
All tappable text in Android are UPPERCASE, and therefore text on tabs are uppercase. iOS segmented controls use Title Case.
About the amount of items on Android tabs, it will be 2–5 in a fixed tab bar. A scrollable tab bar can be used when there are long strings or more than 5 items. A segmented control should have five or fewer segments on iPhone to ensure enough space for easily-tapping.
Basically, the only difference between Android and iOS buttons is string capitalization and appearance style.
Android buttons mainly have 2 styles, “flat” and “raised” buttons, which are used in different situation. For example, it is not good to use raised buttons on card-style UIs because the raised buttons appear too prominently in cards and redundant shadows also make UIs not simple and clean. Flat buttons are recommended to use on not only cards but also dialogs and footers. Android also has floating action buttons, which will be introduced in the next section.
Although Material Design Guidelines only define the visual styles of flat and raised buttons, ghost buttons, which are flat shapes with no fill and a simple outline, and raised-buttons-like ones without shadows can be also found in Google Play. The ghost buttons can be compared to iOS normal Button; raised-buttons-like buttons to pressed button.
The text in Android buttons are UPPERCASE; iOS buttons mainly use Title Case. Sometimes ghost buttons use UPPERCASE, like OPEN and UPDATE button in App Store, but sometime they use Title Case, like “Book a Table” and “Directions” in Map iOS 10. The capitalization rule in iOS seems to be inconsistent.
6. Floating Action Buttons VS. Call to Action Buttons
Floating action buttons, FAB first appeared with Material Design in Android 5.0. FABs, located in the bottom-right corner of screens, are used to fix the usability issue of single hand operation. It is difficult to reach buttons on action bars while using phones with a single hand. FABs sometimes also located at the junction of two areas and that makes FABs more eye-catching.
A floating action button represents the primary action in an application. For examples, the compose button in mail app and new post button in social network app are suitable to use FABs.
The similar design for the primary action in iOS apps is call to action button which located in the center of tab bars. CTA buttons, in earlier time, used different color or design to distinguish them from other tabs. But now, as users are more and more familiar with the pattern, CTA button’s style is the same as tabs’ in many apps. The buttons for new post in Medium and publish a new photo in Instagram are the examples.
7. Bottom Sheets VS. Action Sheets & Activity Views
Android bottom sheets appear from 2015, but iOS has this similar design for a long time. Android has this kind of design because it wants to solve the single hand operation issue.
Android bottom sheet has 2 forms: modal bottom sheets and persistent bottom sheets.
Android modal bottom sheets has two content: 1) Modal bottom sheets with different actions and 2) App list which appears after users tap “Share” icon. The former one is just like iOS Action Sheets; the latter one is like iOS activity views after tapping “Actions” icon. The content layout of Android modal bottom sheets can be list or grid.
Persistent bottom sheets are used when bottom sheets have the same importance as the main content above and users may need to view the both of information in the same time. Taking Map app as an example, the upper area shows a map and the bottom sheet shows the details of the location. In a music app, the upper area would show album cover, and the bottom area may have controls for playing music.
Even though I cannot find the components like Android Persistent Bottom Sheets defined in iOS Human Interface Guidelines, you still can see the similar design in iOS native built-in apps, Map and Music.
8. Dialogs VS. Alerts
Android dialogs mainly have 3 functions: 1) Alters: interrupt what users are trying to do and inform the user about a situation. 2) Menus: provide users to select an option or change simple settings. 3) Confirmation: as a poka-yoke, confirm users’ choice before it is committed to prevent from mistakes.
Android dialogs consist of titles, contents and buttons. Titles sometimes can be omitted. The contents can not only have pure text but also other components like option list or textfields. iOS alert also have titles, contents and buttons, similar to Android dialog. The only difference is content can be omitted but a title should be kept.
Android dialogs have 3 forms: 1) Simple Dialogs, just like a menu: There are no OK and Cancel button on the dialog. You can tap an option on the dialog to select and then the dialog disappear. You can tap outside of dialog or Back key to close the dialogs. 2) Confirmation Dialogs, the most common ones: There are buttons for users to tap to confirm their action. 3) Full-Screen Dialogs, only used on phones: full-screen dialogs do not be full screen on tablets. Android full-screen dialogs are just like iOS modal view, which will be introduced later.
The title and content text in Android dialogs align left; The title and description text in iOS alert align center. Android uses “Sentence case” for the titles; iOS uses “Title Case”. Both Android and iOS use “Sentence case” for the content text.
The title of Android dialog and iOS alert should be short and clear. Avoid questions with some indications, like ”Are you sure you want to delete the file?” The sentence should be simple, neutral and direct, like “Delete the file?”.
About number of buttons, Android and iOS can have 1–2 buttons. iOS guidelines suggest to avoid 3 or more buttons in general because more buttons create complexity and can require scrolling. If you need more than two choices, consider using an action sheet instead. But when iOS ask users if they want to update their iOS version, it shows three buttons, Install Now, Later, and Details in the alert.
When there are two buttons, cancel and main action button, Android and iOS put the cancel button on the left side and main action button on the right side.(You can check this article to know the reason why they have this rule). When the copy on the buttons is longer, two button can be put vertically. Main action button will be on the top of cancel button.
The copy on the buttons should avoid using Yes and No, write action on the buttons would be more clear and direct, like Cancel and Save, Cancel and Remove.
iOS use red on button text for warning if the action is unrecoverable, like delete. Android do not use specific color on button text. About button text, Android uses UPPERCASE but iOS uses Title Case. Button text aligns right in Android, but it aligns center in iOS.
When the context is a lot, Android dialogs can fix the title and footer of dialog but the content is scrollable. The scrollable content dialogs often appear when lots of options are put into the dialogs. iOS guidelines suggest content should be short to avoid scrolling in alerts.
9. Full-Screen Dialogs VS. Modal Views & Popovers
Android full-screen dialogs, only can be found in small mobile devices like smart phones, which can be compared with iOS modal views. iOS modal views have 4 styles, full-screen, page sheet, form sheet and others like split view and popover. About the transition of modal views on phones, a modal view will slide up in when you enter and it will slide down out when you leave.
10. Snackbars & Toasts VS. Alerts
In addition to dialogs, Android also use snackbars or toasts as hint messages with low-level interference. snackbars or toasts as feedback usually show up for about 3 seconds after users take an action and then slide or fade out automatically.
Snackbars can have an action button letting user to redo or take other action. Toasts are mainly used for showing system messages. You can not put icons on snackbars or toasts.
iOS Guidelines do not have that kind of components. Sometimes we can find some apps use alerts as feedback, but alerts would interrupt users and may have higher interference. The similar components in iOS would be the a small pop-up which shows up when you adjust sound volume and disappear after few seconds. Some apps customize the pop-up which show up for seconds only like Android toasts as feedback.
11. Lists VS. Tables
Lists, the most common and basic component, can be found in every app (you can find it in Settings of apps at least). In Android, lists are made up of a continuous column of rows. In iOS, we call Lists as Tablets, consisting of many cells, aka rows.
Android list style have single-line list, two-line list (consist of a primary text and a secondary text) and multiple-line list (consist of a primary text and 2 or more secondary text). Icons, thumbnails and list controls, like checkboxes, radio buttons and switch buttons, can be added into lists. Normally, main actions are put in the left side of list and secondary actions are put in the right side of list.
iOS tables are similar to Android lists, but there are still some points you should notice:
1) On the phone, when Android row has a primary title and a secondary text, they are placed vertically. The secondary text can be description or value. In iOS, in addition to two-line style, it has single-line style as well. The primary text, label, is put on the left side of cell and the value is put on the right side of cell. On the tablet, because of wider space, Android row sometimes is just like iOS, putting a primary title and a secondary text horizontally as a single line.
2) iOS row has better usability than Android. If there is a children screen, iOS would show an arrow indicator on a cell in the parent screen, so users can know the cell is tappable and will lead to another screen. But in Android, we cannot know if the lists are only for displaying information or the entrance for another screen as well. They all have the same look.
3) iOS tables have 2 forms: Plain and Grouped. A plain table has an entire white screen with dividers. Even though only few cells have content, the rest area still have dividers. Grouped tables have a gray background. The first grouped table has some space with a navigation bar and the second grouped table below. Android has one style only and only use a divider to separate two different lists.
12. Subheaders VS. Grouped Table Headers & Section Headers
Android subheaders and iOS headers are used for separating and grouping lists or grid lists with different contents. iOS have 2 different styles to separate lists: 1) Grouped Tables, used for grouping totally different information; 2) Section Headers, can be seen in Plain Tables, used for sorting the similar data format, like photos with different taken dates or contacts with different names.
Android subheaders use sentence case. iOS grouped table headers use “UPPERCASE” and plain table headers use “Title Case”.
Upon scrolling, Android subheaders remain pinned to the top of the screen until pushed off screen by the next subheaders, whose behavior is just like iOS section headers. Grouped table headers do not have this kind of behavior.
13. List Controls
List controls are also essential components for apps. List controls, like multiple section, single selection, switches, reorder grippers, leave-behinds and expand/collapse toggles, will be introduced in this chapter.
13–1.Multiple Selection: Checkboxes VS. Checkmark with Circle
Android uses checkboxes for multiple selection. A box with a tick represents status of selected item; a box without a tick means the item is unselected. Checkboxes, which can be found in website or desktop OS, are generally used components for multiple selection, but iOS does not have this component. In iOS, A circle with a tick is used for multiple selection, but its shape may make users confuse it with a radio button.
Android checkboxes can be put on left or right side, but iOS usually puts multiple selection controls on the right side.
It is worthy of note that Android sometimes uses checkboxes as switches for enabling/disabling functions, but iOS uses switch buttons to do so rather than its circle controls
13–2.Single Selection: Radio Buttons/ Checkmarks VS. Checkmarks
Android has radio buttons, which also can be found on web pages or desktop OS, as a single selection control. A radio button has a circle with a dot inside if the item is selected. Radio buttons are used for lists of two or more mutually exclusive items.
iOS has no radio buttons, but it has checkmarks instead as selection selection controls.
Android used to putting radio buttons on the right side of lists, but now you can find radio buttons are put on the left side gradually. iOS puts checkmarks on the right side, but checkmarks may be put on the left side if right side has other items, like a next page indicator for example.
Even though Material Design Guidelines do not introduce checkmarks, which appear from 2016 gradually, but you can find the example in the menu of Google Calendar.
A switch is a toggle between two mutually exclusive status, on and off. In the past, Android did not have switches and used checkboxes for enabling/disabling some functions, but now Android use switches more and more. iOS always use switches to enable/disable functions. Switches are put on the right side of lists both in Android and iOS.
Android uses an icon which consists of 4 parallel horizontal lines as a reorder control, to avoid confusing people it with hamburger icon which consists of 3 lines, used for expanding and collapsing navigation drawer. Recorder icon usually appears in edit mode.
iOS gripper icon appeared earlier than Android. You also can see it in edit mode. But iOS gripper consists of 3 lines only because iOS does not use a drawer as default navigation like Android.
13–5. Leave-behinds (Swipe Actions)
After swiping left or right, you can find some hidden actions behind a list. It is very common to find in iOS. Normally in the past, you could find a delete action when swiping, now there are more actions in addition to delete. In a mail app, you can find archive, flag and more after swiping left; mark read or unread by swiping right.
After Android 5.0, swipe actions, so-called Leave-Behinds, are shown in the guidelines. It is worthy to note that Leave-Behinds should not be used in a screen has tabs because of gesture conflict and that is why Android did not have this component before.
After swiping a list for a distance and then stopping, you can see 1–3 actions behind, and then you tap one of it to take action. But if you swipe for longer distance, default action will be taken. Android has one action behind only and take the action by swiping straightly.
Expand/Collapse controls can help the hierarchy flatter because users do not need to enter the next screen to see the information, the information will be shown in the same screen. This control can be often found in FAQ lists. After a question is tapped, the answer will show up. Fewer steps are required if you try to browse those QAs.
In addiction to putting expand/collapse in lists, you also can put this control in headers enabling users to collapse the group they do not use frequently.
Expand/collapse can not be found in iOS Human Interface Guidelines and it is rarely found in iOS apps. The similar controls might be something appeared in Explore screen of App Store, in iOS 8. But it is more like a path rather than expand/collapse control because you cannot see other items grouped in different headers in the same screen.
Please give 10 claps👏if you have read this article.
Please give 20 claps👏if you think it is helpful.
Please give 50 claps👏if you think it is amazing!
Thank you :)