When creating mobile applications, most application development efforts focus on the iOS and Android platforms, for fairly obvious reasons. In October and November 2011, Android and iOS accounted for 90% of all smartphone sales (47% and 43%, respectively). While the platform with the majority of users may fluctuate over the next few years as both platforms continue to evolve, it’s safe to say that organizations will need to support application development for both platforms for the foreseeable future.
A common challenge in supporting both platforms is how to best design native applications for iOS and Android that have similar functionality but are optimized for the interaction design standards and user expectations unique to each platform.
Another of the many other challenges in designing for both platforms is that the iOS platform is much more defined in terms of how various UI components should look and behave compared to the openness of the Android platform. In contrast to the iOS user interface standards defined in the Human Interface Guidelines, Android only provides recommendations for how common application UI elements should look and behave. While this openness can lead to creative design approaches, it can be difficult to design for one platform that is more standardized and another that is more open in regard to interaction design patterns. Therefore, to ground design decisions when creating applications, it’s important to identify the similarities and differences between the patterns that have emerged for Android as well as the standards that guide iOS design.
Below are some of the similarities in how to approach the design of the user experience for both platforms, as well as some of the primary user experience differences to consider when designing native iOS and Android applications.
Primary iOS and Android Native Application UX Similarities:
- Application structure: The basic flow of information can be similar in both iOS and Android platforms. It’s rarely necessary to define completely unique information architecture for each platform.
- List-based navigation: In both platforms, most task-based applications are structured in a hierarchical tree-based format in which the user navigates an application through a series of lists and tables to dive deeper into the app’s information. Each level of the application may have unique interaction patterns, but the idea of navigation via a hierarchical structure is similar in both platforms.
- Wayfinding: Wayfinding is an information architecture term for the ways in which people orient themselves and navigate from place to place. Both iOS and Android applications should have visible screen titles that indicate to the user where they are, as well as an indication of where they came from and where they can go next on each screen.
- Expected functionality of basic UI components: Many UI components, including tabs, sliders, pickers, text fields, checkboxes, switches, and buttons, are very similar across both platforms. The design treatment and placement of the UI components varies between platforms, but their expected functionality is quite similar.
- Gestures: The most basic and common touch gesture controls used in applications are similar in both iOS and Android. The tap, drag, flick, swipe, double tap, and pinch gestures are typically used for similar actions across both platforms. The only gesture that has significantly different usage across platforms is the “tap and hold” gesture, which is much more commonly used in the Android platform to reveal a contextual menu of options or to enter a data selection mode.
Primary iOS and Android Native Application UX Differences:
- Screen sizes and resolutions to consider: iOS smartphones only come in one screen size and two screen resolutions. Android smartphones have three generalized sizes and three generalized screen resolutions (or densities). This primarily impacts the layout choices that need to be considered when designing an application.
- “Back” navigation: “Back” is a UI element in iOS applications, placed in the upper-left hand corner of the navigation bar that navigates backward only within defined screens in an application, never across the entire device. In Android devices, there can be two different “back” actions: “up” and “back”. “Up” was introduced primarily for Android 3.0+ devices without hardware keys and is a UI element represented as an icon on the left-hand side of the top action bar. “Up” navigates back within an application. Android “back”, in contrast, is a button on the physical device that goes back in history across the entire device.
- Tab navigation placement: Tab navigation is typically used to navigate through primary functions in an application. iOS tab navigation is represented through a tab bar at the bottom of the application. Android recommends that tabs be placed at the top of an application. In addition, by iOS standards, only 5 tabs can be displayed at a time. In Android, however, scrollable tabs can be used to display more tabs than can fit in the viewable screen width.
- Changing data views: To switch between views of a single set of data, such as changing sort order or groupings, different components are used. iOS typically uses segmented controls for this purpose. A segmented control is a bar divided into segments, each representing a selectable option. In Android, data views are frequently changed using a UI control called a “spinner”, which is a drop-down menu of options that is often accessible via the application’s action bar at the top of the application.
- Selecting from a list of actions: iOS uses a UI control called an “action sheet” to display a list of actions upon selecting an object on a screen. In Android, a list of actions is displayed using a list of radio buttons presented in a popup dialog box.
- Contextual actions: In iOS applications, contextual actions are either accessed through the use of a toolbar that contains action buttons, through an action button in the upper-right hand side of the navigation bar, or through buttons within the main content area of the interface. In Android applications, it is recommended to display contextual actions using an action bar at the top of the screen. When more actions are required to display than can fit on the action bar, either an action overflow icon appears on the action bar for devices that don’t have a hardware “menu” button, or the user accesses additional actions by pressing a hardware “menu” button on devices where one is present. Actions do not necessarily have to be placed within the action bar and can also appear within the rest of an application’s interface where appropriate.
- Search: In iOS, the standard UI control for searching within an application is a search bar that is placed at the top of a searchable screen. In Android, several different search options are available. A “search dialog” component can be used that is similar to the iOS approach and places a search bar at the top of the screen. However, this bar is hidden until the user presses a search button within the user interface. An alternative search approach in Android 3.0+ is to use a “search widget” that allows search to be placed anywhere within the application interface, typically within the application’s action bar at the top of the screen.
The most important thing to keep in mind when designing both iOS and Android versions of an application is that the interface elements of both platforms are not the same and cannot be designed using a “one-size-fits-all” mindset. Adapting an application’s design to the unique platform design patterns and standards is critical to making an application match the expectations users have for how iOS and Android applications should look and behave, ultimately making the application more usable and successful.