Designing Native Android & iOS Apps: Interaction Design Patterns
Author: Atul Pradhananga
Designing for Android and iOS can be confusing at first sight. In order to create the best native app design, we should consider the UI/UX differences between the iOS and Android platforms. These platforms have a varied look and feel in terms of the structure and flow of native applications.
We need to keep these differences in mind to provide the best user experience through the native application design.
iOS and Android native apps have special operating system-specific features. Guidelines by Apple and Google recommends designers and developers to use platform-standard navigation controls whenever possible: tab bars, page controls, segmented controls, collection views, table views, and split views. Most users are familiar with how these controls typically work on each platform, so if we use the standard controls, our users will intuitively know how to get around our app.
In this post, we will focus on the main differences between interaction design patterns on iOS and Android to clarify why apps look different on iOS and Android — and why they should. I’ve also provided native app design templates and native mobile application examples to help you visualize what I’m talking about.
In-app navigation patterns
Among different navigation options mentioned in the Material Design Guidelines, a combination of a navigation drawer and tabs is one of the most used navigation patterns in Android apps.
A navigation drawer is a menu that slides in from the left or right side of the screen when the user presses the hamburger menu icon. Tabs are placed right below the screen title and enable content organization at a high level, allowing the user to switch between views, data sets, and functional aspects of an app.
Bottom Navigation is another important component for the Material Design native app. It makes it easier for the users to explore and switch between the different screens in a single tap. In Material Design Guidelines, it’s not recommended to use bottom navigation and tabs at the same time since it may cause confusion when navigating.
There’s no navigation control that’s similar to the drawer navigation menu in the Apple Human Interface Guidelines. Instead, Apple’s guideline recommends putting global navigation in a tab bar that appears at the bottom of the app screen and enables users to quickly switch between main sections of an app.
Generally, the tab bar consists of no more than five options. As you can see in the picture below, this component is similar to the bottom navigation in Material Design but is more commonly used in iOS apps.
Moving between states/screens
Users frequently move back and forth between screens in an app. On Android, there is a universal nav bar at the bottom, which is very handy within apps as well. This navigation bar is used in other contexts which I talk about later in this post.
On the other hand, iOS approaches this issue a bit differently. There is no universal back button in Apple products, obviously, so we have to make few design adjustments. Every app screen needs to have a button on the top left corner.
For example, let’s compare how LinkedIn for iOS and Android differ:
On iOS native apps, instead of pressing a back button, users can also swipe from left to right to go back. This gesture of swiping from left to right to go back to the previous screen works in most apps. However, the tab navigations work differently on Android apps.
As you can see in the picture, left-to-right swipe on iOS takes you back a step, whereas on Android the same gesture is used to switch between tabs on Android.
It’s important to have this distinction between the two platforms just to maintain uniformity with other apps.
Custom Views for Standard Controls Require Additional Development
Designing and developing an app that has exactly the same looking elements across platforms, requires additional development efforts to create, and it’s also not advisable. The most complicated use cases involve default controls such as radio buttons, checkboxes, toggles, and so on that require a custom view implementation to show iOS-like controls on Android or Android-like controls on iOS.
Both platforms have their own unique interactions. A designer must respect the user’s habits in each operating system and design an interface that provides a pleasant user experience.
That’s why it’s crucial to understand the differences between platforms when designing a mobile app for both iOS and Android so that we design applications that aren’t confusing to use.
Let’s take a date picker for an example. It is an element that’s typically designed differently on the two platforms. Android users aren’t familiar with the slot machine reel-style date selector that’s common in iOS. Using this style of date picker in Android would require custom views, which can get complicated, increasing the complexity and duration of development and making our app design look alien to the Android platform.
Button styles in iOS and Android
There are two styles of buttons in the Material Design Guidelines — flat and raised. These buttons are used in different situations. The text on buttons in Material Design is usually all uppercase, which is rare in native iOS apps.
There’s also another kind of buttons — floating action buttons on Android and call to action buttons on iOS. These action buttons, as the name implies, allow the user to take some type of action. Some of these buttons may have higher priority or visibility than others. Actions like Tweet, Upload, Post update, etc are given more priority (the distinction may lie between actions for modifying content on the screen, vs creating new content).
On Android, these button floats on top of the main content, while on iOS these are generally placed on the top title bar.
Let’s take Twitter as an example.
After all is said and done, there are always exceptions. Not all apps follow different interactions and UI design patterns for the two platforms. Some apps follow Material Design patterns on iOS (Gmail), others follow a Human Interface-ish model on both (Instagram).
But one thing is obvious — it’s much faster to design a mobile application using native components for both operating systems. Thus, it’s better to spend time on the design rather than make one application mockup that’s a mix of Apple’s Human Interface Guidelines and Google’s Material Design components and then spend lots of time on development because of custom elements.
From observation within recent years, Android’s behaviors and UI components are becoming more and more like iOS, even though Android keeps some of their own unique behaviors. I think Google has been trying to domain UI design language across different platforms. In the future, it is predictable that Android and iOS will start to look and feel a lot similar.
Some Great Sources to Study Material Design:
With over 2 billion smartphone users now, mobile apps are used now more than ever. Mobile apps being used increasingly by organisations and now is the time to capitalise. Need to develop creative, efficient, and scalable mobile apps that serve your organisational purposes? Our team of experienced developers and designers work together to build apps that elevate your business strategies. Contact us for a no-obligation consultation at firstname.lastname@example.org or call us today on 01296 328 689.
Join the Discussion
You must be logged in to post a comment.