If you aren’t familiar with the term above, that’s totally okay. I am here to explain it to you ( If you know the term, I am gonna explain it anyway 😉 ).
There might be Other implications of the term “Platform Mechanics”, but here I meant using OS’s (Operating System)/Platform provided conventions in design, i.e using material design & android provided conventions and Android Apps, Apple human interface guidelines & iOS provided conventions in iOS Apps and so forth.
Using conventions in your app will decrease the user’s learning curve, increase the user’s engagement and ensure overall usability to the app with minimal development and design effort. Most of the designers who are inspired by the latest trendy dribbble designs forget about this Superpower (Yes I call this superpower because the OS developers have done the research for you & made the output open and also all of the users used the OS/Platform).
By the end of the article, you will learn how to make use of the platform components & mechanics that are provided by the OS developer. We will also discuss minimal development effort and how to make use of the same platform techniques on hybrid- apps and frameworks ( i.e – Flutter, React Native) since they are so popular and I worked with both of them (Well, technically I just designed for them, Development work has been done by the developers).
Material Design
Google‘s own amazing Material Design has a whole system for all of the platforms and they are adaptive to app, web & much more. They also have detailed platform guidelines. However, most of the things are done with Android in mind since android is google’s very own platform and uses material design systemwide. Though some cross-platform adaptation guidelines are provided to adopt material design in other platforms. They are very limited & makes your app look like google apps on other platforms ( Google use this technique to adapt their apps in iOS). Still, It could be your first step if you are already done with your android app based on material design. It’s so small & simple, yet effective.
You got my back
The first thing that is different in both platforms is the back button & how it behaves. On the Android side, we got a dedicated back button in the bottom (Which differs manufacturer-wise but they all have a back button)
We also got a soft arrow-like back button on the top bar of apps (Sometimes developers forgets to put it though). But in most of there are no swipe-right gestures for the back ( Might be used for another purpose).
Update: Google changed the back button to gesture-based navigation on android 10.
However, on the iOS side of things, we got a single soft-back button on top. The appearance of this back button is different than the android. Mainly an arrow icon followed by context-aware where the indicator ( What page will be displayed when the back button pressed. Mostly parent page). Sometimes the where indicator text isn’t there, which is okay since the users are accustomed & familiar with the back icon. In most apps on iOS swipe-right from the left edge of the screen will trigger back action, This is done for better accessibility when using bigger phones(iPhone X, XS, Plus & Max models) with one hand.
Burger, Kebab, Tab & What Not
Even though both platforms use or support a tabbed navigation menu, there are still many cases in android that mostly uses the Burger menu. It’s been a long debate about burger menus on the app bar is usable or not. However, I prefer to use tabbed navigation in normal cases (There are some special cases as well where tabbed navigation seemed inappropriate). Still, Let’s discuss these things quickly.
Burger Menu
- Less recommended. Has some usability confusion
- Used in Android mostly from the early ages of android. Less frequent in iOS
- Used in Google apps ( Gmail, maps, analytics etc) for accessing less needed options. Recently a lot of google apps had a makeover and opted for tabbed navigation all-together ( Youtube, News ) or got a mix of both ( Drive, Photos, Tasks).
- It can be used in some map apps for less frequent options (Uber, Google Maps). Also, in some special cases.
Tabbed Menu
- Less adopted in early ages but now it’s everywhere.
- Mainly most important stuff is kept in front with/without labels(Not recommended to use without labels). And less important options reside in the profile/menu/more tab.
- Recently added in material design guideline but visually different than the iOS one. iOS had tabbed menu from long ago and improved ever since.
- Sometimes associated by a big fab(Or a big add) button ( i.e – Instagram)
- Costs precious screen real-estate.
Kebab/Meatballs Menu
- The kebab/Meatballs menu is mostly cross-platform. but less frequent in iOS. They don’t use it in apple apps. Apple guidelines call it more menu
- Used on a page for accessing less frequent more options specific to that page (Filter, Sort, Sign out, Help Etc). The options appear on a pop-out menu or a bottom sheet.iOS apps almost always use a bottom sheet (More on that later in this article), android ones use the pop-out menu. Material guidelines have a reference for this type of small menu.
- Apple prefers to use a textual button or putting the options directly on the app bar instead of the kebab menu.
- Since most of the options here are advanced and not needed most of the time, using it correctly doesn’t have an adverse effect on the users normally.
Keep on Tab
A common approach to group together the same type of things and view them when needed. Using the tab view will save screen real-estate and increase interactions. However, iOS has a different view which does the same thing – segment view. It’s recommended to use a segmented view instead of tabs in iOS.
Fabs
Originally designed by Google for material design to ensure main CTA’s( Call to Action) reachability. At first, it was used in a circled icon version. But now a lot of variants came including extended fab. There are some do’s and don’t involve with implementing fab, which can be found here
Mainly seen in android, But still google apps use it in Both platforms. However, the usage of FAB ( Floating Action Button) is not recommended in most cases on iOS.
Turn it on, Turn it off, I Don’t Know
Switches are one of the interesting things in the mobile App UI. We got two different switches look in iOS and Android. Or you can make a custom one like the ones on the web (Or if you have anything the design system of yours). My personal preference is the iOS one.
However, Be careful about the use case of switches, use where toggles are necessary, not somewhere else. You can check Android/iOS’s system settings to find out samples and example. Also, they can be used as an alternative to a radio button/checkboxes in some cases, but when there are many choices you should use a cleaner approach.
Radio-Inactive
One of the things that we don’t have in the iOS system, but have it in material design for android is those radio buttons and checkboxes.
While designing an iOS app ( or a cross-platform app), avoid radio buttons & checkboxes if you can. Use the other alternatives like switches or ticks in list view. Your users will understand those easily and those offer better accessibility in mobile devices.
Pickers
The time-date or option pickers are totally different on both platforms. The iOS one offers a better UX with haptic feedback and spinner like selector.
The android one is good enough, but as per some of the usability tests I conducted, the default clock picker on android is bit tough to understand for some elderly users. However, android also offers a spinner-like layout.
Bottom Sheets
Both platforms offer two types of bottom sheets for different use cases.
The grid-style bottom sheet(Both iOS & Android) mainly used for sharing in other apps ( Generally, Social media). The android one offers a flat list of sharable apps, the iOS share sheet offers recent apps first.
The list-style bottom sheet (iOS guidelines call it action sheet ) mainly used for showing various types of actions and options the user can take.
Search
This one is optional. Android and iOS have their own styles of doing search bar, But you can get creative with it and use your own search bar for better brand visibility and accessibility. However, in case of iOS, Its recommended having a cancel button and clear field option ( see image below)
Ensuring X-Platform
In my experience, I have found iOS guidelines are more strict than android (Your mileage may vary). If you start your design keeping iOS in mind you’ll need to change only a few platform things to get the app to follow Android guidelines. ( i.e – the android back button, bottom sheet, pickers etc).
However, after the new material design guidelines, there is a dedicated cross-platform adaptation Guideline so that you can adapt your material design app to the iOS platform.
Nowadays, Cross-platform application development frameworks (i.e – Flutter, React native. ) got popular because of their rapid development capabilities. So if you design to keep cross-platform in mind, and need only minimal changes to adapt a platform without hindering the user experience. That will save both design and development efforts. Big companies & startups like Airbnb, Facebook, Uber, Alibaba did their app on this cross-platform frameworks. You can inspect those apps on both platforms and find the differences & their style of platform adaptation. (Psst. If you don’t own an iOS device, check Mobbin. A pretty amazing site my co-worker found).
Just My Type
If you have your brand’s own typography guideline, try to follow that. However, Android got Roboto typeface & iOS got San Francisco font, both are good as well( Medium uses system fonts currently ). Using system fonts is not necessary in this case, just keep the look and feel of your brand so that people can easily recognize the brand.
E.O.B ( End of Blabbering). Let me know in the comments if you have any queries/opinions/thoughts. Till the next article take care, bye. ?
Leave a comment