Differences between designing Android and iOS native apps
FIND OUT WHAT ARE THE THINGS YOU SHOULD CONSIDER WHILE DESIGNING APPS FOR IOS AND ANDROID.
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.
Image source: Google
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.
1) Human Interface Guidelines (HIG) vs. Material Design
Image source: Google
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
Image source: Google
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
Image source: Google
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.
There are many differences when it comes to naming. Here I have mentioned five of them.
а) Tab bar versus bottom navigation bar
Differences between designing Android and iOS native appsImage source: Google
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 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.
What components are missing in iOS
Many of the native Android components are absent on iOS. Let's review them.
a) Navigation drawer
In principle, iOS does not recognize hamburger menus. iOS only has top-level navigation through the tab bar.
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.
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.
Like banners, Snack bars 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.
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.
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] (https://www.valuecoders.com/hire-developers/hire-android-developers) only.
Now let's take a look at the components that are not found in the Android library.
a) Page control
Differences between designing Android and iOS native appsImage
This component shows which page the user is on. It is not a native Android component.
Toolbars are only visible on iOS.
Steppers are a standard iOS control not described in Material. We use them to enter small values like the number of copies when printing.
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.
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
(Differences between designing Android and iOS native appsImage) source: Google
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.
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.
This blog was originally posted at: [Geek Culture - Medium] (https://medium.com/geekculture/differences-between-designing-android-and-ios-native-apps-12a3a656453)