Differences between designing Android and iOS native apps

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

If you are planning to design native applications on Android and iOS, you must know that these two platforms have vastly different design guidelines.

Apple follows HIG that is flat design and Android is based on material design. Read this blog and find out the differences between these platforms.

android_ios_native_apps

When developing a mobile app for iOS or Android, there are a few things to consider as to what are the best practices that would optimize app performance and user experience. That’s what we call the iOS and Android UI. The smartphone market is divided into two main platforms: iOS by Apple and Android by Google, with their own design style that defines how applications should work and look. Let us guide you through the key differences between iOS and Android.

To tailor an app design properly, you need to follow the platform guidelines, that is, the Human Interface Guidelines (HIG) for iOS and Material Design for Android. You also need to communicate with developers, ideally involving them in the design process as early as possible so they can set technical constraints right away.

But what exactly differentiates the design for iOS and Android? In this article, I am going to discuss some specific design differences between iOS and Android. They are divided into four groups: basic differences, differences in navigation and patterns (UX), differences in components (UI), and miscellaneous differences.

 

Basic Differences


1) Human Interface Guidelines (HIG) vs. Material Design

android_ios_native_apps_01

At the conceptual level, we can summarize them as follows: HIG is all about a flat, light, and friendly design and comes from a gradual rejection of skeuomorphism. The material has several fundamental principles: the material as a metaphor; bold, graphic, mindful; intentional animation; flexible foundation, and cross-platform functionality. I suggest you read the guidelines before continuing with this article if you are not familiar with them.

 

2) Measurement Units, dp vs pt

android_ios_native_apps_02

IOS app layouts are developed in pt, and Android app layouts are developed in dp. As a general rule of thumb, we develop layouts in 1x (or mdpi) and upload them to Zeplin. Zeplin displays iOS layouts in pt and generates 2x and 3x icons and illustrations. For Android, layouts are displayed in dp and output graphics in hdpi, xhdpi, xxhdpi, and xxxhdpi.

 

3) Screen Size

android_ios_native_apps_03

I prefer to design iOS apps in the smallest size possible — the iPhone 5 SE screen size of 320pt x 568pt. I do this to prevent content from displaying incorrectly on small screens. Some people prefer to design for iPhone 8.

For Android applications, we have a generally accepted screen size of 360dp x 640dp.

While in iOS, I sometimes refer to iPhone X (375pt х 812 pt) to develop designs which as well many other mobile application development companies prefer to do. This is necessary for the developers to understand how to set the margins correctly on a screen of this size. When designing for iPhone X, you should also consider the safe area. This is the only area where you should place content.

 

Naming Differences


There are many differences when it comes to naming. Here I have mentioned five of them.

 

а) Tab bar versus bottom navigation bar

android_ios_native_apps_04

 

This is a top-level navigation bar within the application. It’s statically located at the bottom of the screen on both platforms. Besides naming, the bars are different in terms of their behavior.

 

b) Navigation bar in front of the upper application bar

 

This bar acts more or less the same on both platforms: it tells the user their current position within the application, allows them to return to the previous screen, and suggests one or more contextual actions.

 

c) Segmented controls versus tabs

 

Along with naming, Android tabs have a number of different features — you can swipe from one tab to another, and Material lets us use them for top-level navigation.

 

d) Alerts against dialogues

 

Interestingly, only one tool to alert the user for iOS is described. Whether on Android, we have three of them: Snackbars, Banners, and Dialogs. The snack bars are designed for low priority messages and do not require any additional action. The dialogs block interaction with the interface and require the user to perform an action. Banners halfway between these two: They don’t block interaction but require the user to take action.

 

e) Touch IDs vs. Android fingerprint

 

This is one example of the different naming conventions for the technologies used on these platforms. It is necessary to know them since, in addition to naming, they have a series of distinctions in terms of the technical characteristics of their implementation. Understanding the name distinctions is the first step to understanding technology distinctions.

 

The difference in Navigation patterns


The difference in search behavior

 

Interestingly, the HIG relegates searching to bars and calls it a Search Bar. In Material Design, we find searching in the Navigation section, not in the Components section. In other words, for Material design, search is just another navigation method. On both iOS and Android, the search can be statically present on the screen, and, as a rule, it’s fixed to the Navigation Bar/Top App Bar.

On both platforms, the search can appear in the form of an icon; however, on iOS, the search icon expands into an independent Search Bar component, and on Android, the icon expands within the Top App Bar.

One added feature of search on iOS is that it can be “hidden” underneath the Navigation Bar and called up with a “swipe down” gesture. The same gesture is typical for a refreshing (pull to refresh), so you don’t want to activate search and refresh using the same action.

 

Component Differences


What components are missing in iOS

Many of the native Android components are absent on iOS. Let’s review them.

a) Navigation drawer

android_ios_native_apps_05

In principle, iOS does not recognize hamburger menus. iOS only has top-level navigation through the tab bar.

b) Funds

Backgrounds are, as far as I’m concerned, the most amazing component of Material. When writing, Android is still planning to deploy funds as a native component. In general, when examining the components of the Material, check whether they are already available for use or not.

The material itself loves this component. For example, look at the winners of the Material Design Award 2019.

c) Banners

Banners are not among the native iOS components. Through a banner, we can communicate important information to the user and suggest actions related to it.

d) Snackbars

Like banners, Snackbars are not among the native features of iOS. The snack bars are used to give the user short messages about the results of their actions.

e) Chips

The chips are not native iOS components either. They are used for the entry of information, descriptions, and actions.

f) Lower application bar

Here we can argue that iOS has a toolbar-like component. But they are actually different, and this is why: a Google bar is a bar for contextual actions, i.e., when editing a list of messages in Messages, a toolbar with the actions “Read all” and “Delete” appears. On the other hand, the bottom application bar is essentially a top app bar that has been moved down along with the same top-level actions, including opening the navigation drawer, calling to search, etc. The bottom bar of applications.

g) FAB

No, there is no FAB on iOS either. A FAB is a button to perform the main action on the screen. For example, in an email application, the FAB will compose a new email.

If you use a FAB for the main action on the screen on Android, on iOS, the main action should be located at the top, on the right side of the navigation bar (see iMessage, for example).

h) Lower navigation drawer

This is another version of the typical Android Navigation Drawer. It is opened by pressing the hamburger menu button on the bottom bar of the application.

i) Side sheet

Although Material also allows the use of this component in mobile applications, I recommend replacing it with a more familiar bottom sheet.

j) Lower fold-out sheet

This very good-looking Android component is not one of the native iOS components. A bottom fold-out sheet is a surface attached to the bottom of a page. If the user touches this surface, it expands to a full page.

k) Standard bottom sheet

This sheet is a variation of the bottom sheet and is not an iOS component.

These features can only be found and built in Android. Hence, if you are planning for these then prefer to hire dedicated Android apps developers only.

 

What components are missing in Android?

 

Now let’s take a look at the components that are not found in the Android library.

a) Page control

android_ios_native_apps_06

This component shows which page the user is on. It is not a native Android component.

b) Toolbars

Toolbars are only visible on iOS.

с) Steppers

Steppers are a standard iOS control not described in Material. We use them to enter small values ​​like the number of copies when printing.

d) Popovers

A Popover is a pop-up panel that is mainly used on the iPad.

There is a standard app for Popovers on iOS: adjust text settings in readers or browsers.

If you are looking for these features in your app on a budget, you must hire an iOS app development company in India.

 

Other differences

Different requirements for the size of the tap area

According to the guidelines, the minimum size of the touch zone is 44x44pt on iOS and 48x48dp on Android.

1. App Store vs. Google Play

android_ios_native_apps_07

Your iOS app will be downloaded from the App Store. Your Android application will be downloaded from Google Play. To ensure that your application is published correctly in these stores, you must meet their requirements. The requirements for the App Store can be found here, and those for Google Play can be found here. There are a lot of requirements there, so I recommend studying them before they launch.

2. The special pattern in iOS: undo and redo

There is a special pattern in iOS: if the user shakes their smartphone, the app gives them the option to cancel or redo their last action. As a general rule, this gesture is used to undo the writing.

 

Bottom Line


Knowing these guidelines increases our awareness. This helps us to understand established user patterns and build applications that are organically adapted to user habits.

The guidelines motivate us to respect the native solutions of the platforms. When adopting a design to another platform, there is always the temptation to duplicate the design without making any changes. This hurts the user experience and makes development difficult. But if we are aware of the differences between the native solutions, we can adapt our design correctly.

And if we want to implement a new customized solution, knowing the guidelines helps us defend innovation.

In the end, knowing the guidelines and their differences is an important skill that a mobile app designer must have.

Source

Search

Articles - Category