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.

Left — drawer navigation menu; right — tabs (Material Design)

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.

Bottom navigation (Material Design)

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.

Top left — iOS segmented control; bottom right — iOS tab bar (HIG)  

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.

The famous Android navigation bar. The back button is an easy way to go back to a previous screen and it works in all apps. 

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:

Left-to-right swiping gesture — go back (iOS) 

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. 

Swipe to switch tabs on Android 

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. 

Left — standard iOS controls; right — standard Android controls 
Left — standard iOS pickers; right — standard Android pickers 

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. 

Left — standard Material Design buttons; right — standard HIG buttons 

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.

Twitter app’s “Tweet” buttons. Left: iOS ; Right: Android. 


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). 

Left: Gmail for Android; Right: Gmail for iOS. Both apps follow Material Design patterns.  
Left: Instagram on Android; Right: Instagram on iOS. Both apps look and behave similarly. Notice how the iconography is different in both. 

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:

  1. Material Design Guideline
  2. Video about the making of Material Design
  3. Human Interface Guideline 

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 or call us today on 01296 328 689.


You Might Also Like

Top Six Reasons to Migrate to Power Apps from InfoPath 

August 11, 2023

Top Six Reasons to Migrate to Power Apps from InfoPath 

Prepare for the Future as InfoPath Nears its End  Are...

Read More
Microsoft 2024 Release Wave 1 for Power Platform: Supercharge Your Workflows 

April 25, 2024

Microsoft 2024 Release Wave 1 for Power Platform: Supercharge Your Workflows 

Calling all citizen developers, business analysts, and automation enthusiasts! Are you...

Read More
Top 10 Ways OpenAI and GPT are Transforming Dynamics 365 Applications

May 3, 2023

Stay Updated !

Join our newsletter for exclusive blogs delivered straight to your inbox.