When we design an app, one of our major tendencies and natural processes is to follow the native design patterns of Android and iOS. Following platform conventions is a practical approach, and definitely seems like quite a sensible one. Some job applications requires us to be familiar with the separate Android and iOS mobile patterns. And every existing content or blog that writes about this topic will only recite, as it is, what appears to be the difference between Android and iOS according to their platform guidelines. This causes many to think that it is the right way of doing things. However, it is a major problem.

I’d first like to point out some of the key UI differences between Android and iOS, but more importantly, share why it is limiting to think we need to closely follow native UI patterns when designing an app.

The truth is, you don’t always need to. I’ll explain why.

The basic differences between iOS and Android

First, we can all agree that one of the most striking differences between Android and iOS is that iOS uses navigation at the bottom of the screen, while Android uses tabs, often supplemented with swipe, to navigate. Android has its Material Design language, while iOS has its Human Interface guidelines.

Beyond that, there are other differences such as interaction patterns and visual styling of components. iOS titles tend to be centered whereas Android titles are placed on the left. Visual components such as lists, radio buttons, etc. may have their own visual styles.

The problem with the concept of the “Android” style and the “iOS” style

Unfortunately, this separation of styles is where the problem begins. It influences us to think that there is a correct “Android” or “iOS” way to design and use an app.

A simple checkbox is widely understood on a website. But in native applications, we begin to emphasize the correct way to display it according to Android or iOS guidelines. When this happens, simple decisions become quite trivial and arbitrary.

This thinking ultimately leads us to create a separation between iOS and Android users, rather than simply seeing them all as human beings.

At the extreme end of this mindset, it limits our design, our approach, and our understanding by assuming that we should and must solve the problems we encounter in a certain way; that is, by following platform conventions.

The true difference between iOS and Android

Let’s for a moment shift our thinking to eliminate concepts of “iOS” and “Android” design patterns, and simply think of our users as “smartphone users”, or simply as human beings using palm-sized touchscreen device.

To design an interface for such a device:

We should place navigation at the bottom of the screen, where it is easy for the thumb to reach. If we want to place navigation at the top, we should supplement it with swiping for better accessibility.

Buttons should be finger sized.

Back buttons should appear at the top left corner.

A checkbox (called a switch in iOS) should simply look and behave like a checkbox.

Note that while the checkbox on the left might be wrong according to the Android or iOS defined pattern, it cannot objectively be wrong because it is still a checkbox. It is universally understood and used as a control which indicates an on/off state.

So far, we are making no reference to any platform-specific convention. Rather, this approach generates a design that simply serves as a palm-sized digital interface for a human being. Regardless of whether we are an Android or iOS user, we have no more than two hands and ten fingers, and interact with the device by tapping it or swiping one way or another. We understand buttons, icons, and popups on websites, so why are there sudden distinctions when it comes to native applications?

If we understand and approach design from this perspective, we are simply designing for human interaction, rather than trying to satisfy the illusion of style, to get to the truth.

This is simply the human concept without the attachment of “styles”. If it works for a human being, then it simply cannot be wrong, even if it doesn’t follow “established” patterns. When you understand this perspective, then the truth becomes obvious — there is no difference.

There is no need to be fixated and misled by the ideology that we need to follow “established” patterns, or to frown upon those who deviate from what is established. There are hundreds of thousands of responsive websites designed for mobile use which do not distinguish between iOS and Android visitors. They simply appear as palm-sized digital interfaces.

With the platform based approach, we express the solution through a platform specific convention. With the human approach, we simply express the solution on a palm-sized touch screen device.

Proof

With hundreds of millions of users, apps like YouTube, Airbnb, and more have streamlined this approach. They have defined their own style which does not favor a particular “Android” or “iOS” style. Thousands of game apps also do not distinguish between “Android” or “iOS”- they simply have their own stylized UI wrapped in a smartphone.

In March 2016, Google added bottom navigation to their Material Design guidelines. Before this, one might have argued that bottom navigation is an iOS pattern, which does not belong on Android. However, from a human perspective, it simply works. This addition closes one of the major gaps in the differences we observed between iOS and Android. What might have been deemed “incorrect” or “unconventional” is now “correct”.

Major advantages of using one design

Using one design for both platforms has some major advantages, one of them being that it strongly favours efficiency as there is no need to maintain two separate designs. When making design choices, we also don’t get caught up believing things should be done the “Android” way or the “iOS” way for the sake of satisfying conventions.

We may even be able to use a single code base, eliminating the need for separate “Android” or “iOS” development and developers.

Creating a uniform design across all mobile devices is also a key point in maintaining a consistent experience for all users of all devices.

The simple truth

With thousands of apps in the app stores, and even the popular ones with hundreds of millions of users all doing different things, which, then, is the correct way to design an app?

The truth is that there is simply no right or wrong.

All solutions are valid if they work. The only real mistake is when we become so fixated on emphasizing and following what we think of as the “correct” and “established” way that we become narrow and limited.

So when should we use native? When should we use a uniform design?

As a simple guideline, we could follow native Android or iOS conventions only when we are creating an app for a single platform.

We should consider using one design if budget is limited, and we want to emphasize efficiency, by using one codebase to produce both Android and iOS versions of a single app.

These are guidelines, not hard rules. Factors such as technological limitations, performance, budget, resources, and the expectations of the target audience should also be considered when making design decisions.