07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

Envato Elements Now with 200,000 photos. Find Your Perfect Photo

Advertisement

WEB DESIGN > UI DESIGN

A Tale of Two Platforms: Designing for Both Android and iOS

by Chris OSullivan 15 Apr 2015
Length: Long Languages: English

UI Design Mobile App Android Interface Design

Whether youre working in-house, contracting, or for an agency, companies need apps for many different reasons. Established companies in
particular need to cater for their existing customers and the devices they use. Often that means a new app for both Android and iPhones.

In an ideal world, wed spend months designing two apps. But in reality, many projects dont allow that much time. For any of the apps Ive worked
on, the deadline has been tight enough for designing one app, let alone dividing the project fully into two.

Quite often youre designing one app, with tweaks being made before handing it over to two development teams.If you are designing an app in
this way, its important to understand the difference between the two platforms early on, and the quick ways that you can make the experience
feel native to each.

Before You Begin: Choose Your Approach

1. Keep your enemy closer
Its likely that you will have a personal preference for one system. Ive always used iPhones, so I have a more natural understanding of the UI
patterns on iOS. The rst thing thing to do is get to grips with the other platform, and the best way to do this is to buy another device, an Android
in my case. It might even be a good idea to use this as your primary device for the length of the project, to really get a feel for the platform.

If youre working in-house, get them to buy you a test device. If there are any issues, communicate with management the value that understanding
the alternative platform will add to your design work (the cost is expensive for two devices out of your own pocket, but for a business its a low
expense compared to the outlay on the design and development of a new app). If youre working freelance, you should be able to write it off
against your tax bill.

2. Choose a lead
As were designing for both platforms at once, whilst dealing with the real world where time is limited, youll have to accept the reality of
prioritising one platform at the outset. Make this decision not based on your personal preference, but based on the market for your app. Do more
people in your market use Android phones? Is it a paid app? What is the target audience? Asking these questions will help you to decide on which
is preferable.

3. Know the rules

Read up on UI guidelines for Android and iOS. In the past Apple was known for being more strict with their guidelines. To get an app in the app
store, there is an approval process which takes approximately two weeks. There is no approval process for the Play store. However, due to this
lower barrier to entry on Android the quality of design has traditionally been worse off. Google are looking to change this with their Material
Design guidelines.

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 1/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

The Material Design aesthetic has become very familiar to web designers

There are a lot of good, and free, UI kits which you can use for your projects (youll nd some listed at the end of this article). Using these
components will naturally give your app a native feel. But even when you get the UI kits, it can be tricky knowing where to differ and where to stay
the same between platforms, so thats where I want to help.

Designing Your App

Follow these simple steps, and your app will be on the right track to t in on both Android and iOS devices.

1. General style
Since iOS7, Apple has shifted to a atter design style, and ditched the skeuomorphic shadows, textures and effects which dened the iPhones
early years. Android, having been more systematic in style in the beginning, has gone slightly the other way. Googles new Material Design
guidelines create more subtle references to the real world, with a layered paper approach providing more hierarchy.

2. Real buttons
Android phones have a back button, which can be used to return to previous screens in the app.

Get back

iPhones dont have this button, so there needs to be a way to travel back to the previous screen. This is usually done by a back chevron in the
top left of the screen, but needs to be considered throughout the various journeys in your app.

3. Global elements
There are global elements (like a status bar and header) which appear on all the pages of your design. You shouldnt be changing the height or
style of these bars at all if you want the app to feel native, so I would recommend dening them once in your rst page design for each platform.
Then afterwards you can use a placeholder (or the status and top bar from your primary OS) on each of your mockups, but indicate to developers
that it should be the same across the board.

There are slight differences between the navigation bars on each platform. On Android the text is left aligned, whereas for iOS its centred. On iOS,
a lot of companies replace the title of the main page with their company logo, but this is not best practice on Android.The status bar (with your
network, battery, and time information) is a native component, and you dont need to consider the design. Just make sure when presenting
mockups to use the correct one to avoid any confusion or distraction.

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 2/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

4. Navigation
Perhaps the biggest point of difference between iOS and Android platforms is navigation. The primary navigation pattern on Android is a drawer
menu. Android users naturally go to this for menu items, and it tends to be omnipresent throughout the experience. Apples guidelines are more in
favour of a tab bar, which is located at the bottom of the screen, and allows easy access to the top level areas of the app. When youre deciding
the top level architecture of your app, you can plan out two separate menus for the two platforms.

Thinking about the architecture of the app is arguably more important than the layout of the menusa point I made in another article about some
of these issues. If your structure is sound, the navigation will follow.

As you see here, there are two navigation patterns: a drawer menu for Android and a tab bar for iOS. Its sometimes easier to simply hide the
navigation layer while you work on individual views.

5. Cards, or not?
Cards are becoming the primary UI pattern in digital design. Theyre versatile and allow users to consume quick bites of content in a way that
suits mobile behaviours. Visually, cards t in very well with Androids material design (it being inspired by paper). Using drop shadows and
reasonable gutters between cards will create a native look and feel naturally.

On iOS, using cards needs more care and consideration. Even big apps like Facebook and Pinterest use cards in a way that is slightly out of tune
with iOS guidelines. iOS guidelines suggest using depth in transparencies and overlays, but the basic view is usually more at. Instagram use an
entirely at design style, although each post could be considered a card from an architectural point of view. Its worth looking at how Instagram
gain the same component feel within an iOS style. If youre going with cards on iOS be very gentle with any use of shadow, and try to keep them
as subtle as possible.

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 3/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

Cards for Android and iOS, some dimension lends a bit of affordance

6. Typography
The system font family on iOS is Helvetica Neue. On Android it is Roboto. Although the style of the typefaces are noticeably different, the metrics
of the fonts are quite similar. If youre saving time youll be safe enough to work with just one, but communicate to developers to implement the
right font for the system. When working with important layouts and extremes in type sizes its advisable to at least test out your layout with both
fonts.

If you want to go the extra mile, youll need to pay closer attention to the typographic and layout conventions on each platform, again referring to
the guidelines above. A few generalisations:

Android Material Design uses ample white space in layout

There is also more dramatic use of font sizing in material design. Striking headings with lots of space provide the hierarchy
On iOS, there is less dramatic variation in sizing. But there is slightly more variation in font weights, which still allows you to create a
hierarchy.
Typically, both platforms use lighter weights in the font family. However, in the example below, the Android design is using light and regular
weights of Roboto, while the iOS design is using bold and regular weights of Helvetica Neue.

This is a very simple example, to emphasise how even in simple ways the typography can immediately tell you if youre dealing with an Android or
an iOS app.

7. Grids and touch targets

iOS (44px @1x) and Android (48dp - 48px at 1:1 ratio) have slightly differing guidelines for touch targets. Material Design guidelines also suggest
aligning all elements to an 8dp square baseline grid.

On the latest project I worked on we found it safer to follow these Android guidelines because (a) the larger 48px touch target is safe for both
platforms, and (b) the layout for Material design is more dened and up to date. Either way, you will need a grid to work with, but with Android
being more strictly dened we found 8dp to work well. This means setting up your document with 8dp increments in both horizontal and vertical
planes to create a tiled grid layout.

8. Button styles
There are several button styles dened in Material Design:

1. Floating action buttons:the most traditionally shaped buttons. The drop shadows are quite heavy and lift them off the page. These should
only be used on backgrounds, or sparingly on cards. They shouldnt be used at all on alerts or popups, as doing so creates too many layers of
depth. The primary action takes your accent colour, while the secondary versions are usually a less prominent colour.

2. Flat buttons: essentially text in your accent colour, without any bounding elements. They use padding and all caps case to give them
structure.

Compared to Material Design, iOS apps are typically at in appearance, making no use of depth or drop shadows. The primary buttons have a ll

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 4/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS
colour, while the secondary buttons are reversed out, using a stroke of the same colour. This metaphor can become somewhat limited, especially
when compared to tabs and other elements to follow. To get this very at style right, its important to have clear and consistent metaphors for
what colours mean in your app.

iOS also has a plain text style button, but it doesnt share Androids uppercase styling, and is lighter in font weight.

9. Action Sheets
Action sheets allow users to choose from a multitude of actions from one UI item. For example, when I touch (or long press) on an image I might
want to share, upload, copy, or delete the picture.

iOS and Android deal with this in slightly different ways. Firstly, there are similar action sheets which display from the bottom of the screen, as an
overlay on the current view.

With Action sheets, overlays, and alerts, iOS and Android use different details to indicate depth in layers:

Android overlays have a solid colour with a slight drop shadow to indicate that it is a paper layer above.
iOS overlays have no drop shadow, but have a slight transparency on the background.

Dropdown buttons

Existing only on Android, these are a quick re method of making a selection. Bear in mind, however, that there isnt a native iOS equivalent. In the
example below, the user presses on prole in step 1, and is presented with a simple menu in that location to choose one of the available proles.
These menus are also used frequently from the overlay button in the action bar, indicated by three vertical dots.

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 5/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

Speci c Data Input

For particular inputs like date and time, Android now comes with built in dialogues. These look like alert popups, but with UI specically catered to
inputting this type of data. An example is shown of a calendar input. Android has an optimised overlay provided for inputting a date. iOS deals
with this quite differently, appearing as a wheel that comes up like a bottom sheet. Be careful in planning these, and communicate with
developers early on input components.

10. Segmented controls

Segmented controls are used to switch between different content within a single view. Their use is much the same, but theyre very distinctive
visually on each platform so its important to use the right style. On iOS there are three tabs, styled similarly to the line buttons discussed
previously. On Android, they are denoted by a simple underline, and given a lot more white space to signify their interaction.

11. Alerts
Its important to get the style of these right because they might control important actions like signing up, accepting terms, or even conrming
payment. We want them to feel trustworthy and native.

The Android alerts use the at button styles that were shown earlier, dimensions for which can be found in the material design guidelines. The
actions sit on the bottom right of the alert. The buttons are actually entirely text based. They use all caps to give them more structure, and they
carry the primary action colour of your app.

On iOS, the actions are separated by dividers. They are usually in sentence or title case, as they gain their structure from the separate blocks. They
are centred in the eld, and again they will inherit your active colour.

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 6/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

12. Icons
Icon design is quite the specialist area in UI design. Whether youre using free icons, commissioning an icon designer, or designing the icons
yourself, theres a distinct style native to each platform. iOS popularised line icons, with very thin strokes. The Android system icons have thicker
strokes, or areentirelysolid icons. In the past, Android icons used perspective or a three dimensional twist, but now their guidelines specify two
dimensional icons viewed straight on. Heres a quick example with several icons for comparision, or use the direct links to icon guidelines for
Androidor iOS

13. Snackbars, toasts, loading images

Unlucky 13. There are a few UI details that can slip through the cracks. Common ones like alerts and loading icons are often left to developers.
You may have experienced rogue spinners and strange alerts which have felt out of tune with the rest of the app. There tend to be native solutions
for these, but they can be tuned to the style of your app. This is denitely an area where collaboration with developers is the best way to decide on
which way yours should work.

14. Common UI Controls

Radio buttons, check boxes, elds and switches are functional components that should be given a native feel. As with alerts and dialogues, these
controls and inputs are an area of trust and familiarity for the user. Use the native components as much as possible for these, so that people (a)
know how to use them, and (b) trust your app with their sensitive data or payment details.

In the example below we see switch and radio button equivalents for Android and iOS. Again, the differences are small enough for you to progress
with one design, and tweak for the other later, but the subtle differences are essential for a native look. Use your UI kit as much as possible for
these components, and again communicate with developers early on in the process.

Android (left) and iOS (right)

Advertisement

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 7/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

Summary
It isnt an impossible task to create a native feel for your app on both iOS and Android with one design. Try to keep on top of these tweaks from
the beginning, keep an eye out for components that feel out of sync on one platform, and always work as closely as you can with developers.

Resources
This article will hopefully give you quick answers on where to diverge designing for two apps, but youll also need some tools and templates to
properly execute your design. There are lots of commonly available resources that you can use as a starting point, here are some of the best:

Guidelines

If you want to know more, a lot of the information Ive provided can be found in the platform guidelines. Theyre quite extensive, so Ive just pulled
out the parts that are important to compare. But if you have more specic questions this is the best place to start:

iOS Human interface guidelines

Android material design guidelines

UI Kits

These UI Kits will save you recreating basic native controls and matching sizes. You can pluck out the pieces you need and then switch between
them for the Android and iPhone output of your designs.

An excellent PSD template for iOS from Teehan + Lax

Android Material Design PSD Template

Icons

Even if youre making your own, or commissioning icons, theyre useful to have as placeholders while you work. Icon design can be a job in itself,
and you dont want icons to slow you down while you get an overall feel for your app. I recently found the links below on icons8 look pretty good,
or aticon.com is great for more general icons.

Line icons which are great for iOS design

Flat icons that work well with material design

Mockups

Its always useful to have device mockups for presenting your app. These come in many categories. You might want a basic device mockup for
context, a simplied at device to let your app shine, or a lifestyle mockup to present a use case. Here are a few resources Ive found useful, there
are many more out there. When it comes to Android devices, be careful which you choose. I would lean towards the Nexus range, as theyre
Googles own phones and wont hint at a preference towards other manufacturers.

Ofcial iPhone device downloads

Flat apple devices with multiple perspectives
Nexus 6 at mockup
Lifestyle mockups from placeit

Advertisement

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 8/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS
Advertisement

Chris OSullivan
Product Designer. Stockholm, Sweden.

I'm an Irish designer now working for Spotify. Prior to that I worked for Ryanair and Soundwave in Dublin, along with other startup companies. I love
using design to tackle problems; from research to prototypes and everything in between.

villainschorus

Weekly email summary

Subscribe below and well send you a weekly email summary of all new Web Design tutorials. Never miss out on learning about the next big thing.

Email Address

Update me weekly

Advertisement

Translations

Envato Tuts+ tutorials are translated into other languages by our community membersyou can be involved too!

Translate this post

Powered by

27 Comments Tuts+ Hub

1 Login

Sort by Best
Recommend 37 Share

Join the discussion

LOG IN WITH

OR SIGN UP WITH DISQUS ?

Name

Ian Armstrong a year ago

As of late February (2016), the Material Design specification includes bottom navigation: https://www.google.com/desi...

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 9/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS
2 Reply Share

Gabriel Cartier 2 years ago

Great article, just a few notes, iOS now uses San Francisco font family as part of iOS9.

Also, I think that the Android top bar is a more common replacement for the iOS tab bar. Drawer, although pushed a lot by Google, are not so widespread.

Again, great read!

2 Reply Share

Chris O'Sullivan > Gabriel Cartier 2 years ago

Thanks for the feedback. You're right, the top bar is another solution to navigation. Google seem to suggest it only for small number of menu items. But it
mirrors an iOS tab bar more closely than a drawer https://www.google.com/desi...
Reply Share

Don Droga > Chris O'Sullivan a year ago

Top bar can get trick for larger phones. Horizontal scroll menu I love in Material. Both platforms are very similar.
Reply Share

Jeff Lopes 2 years ago

Great information, thoughtfully presented. Thanks!
1 Reply Share

Mervin Johnsingh 2 years ago

Fantastic article, would love to have a cheat sheet made out of this.
1 Reply Share

Chris O'Sullivan > Mervin Johnsingh 2 years ago

maybe some time :)
1 Reply Share

Vlad 2 years ago

Great article, Chris!
1 Reply Share

Vincent Lim 9 days ago

thanks for the sharing, great article with lots of useful information (Y)
Reply Share

leo a month ago

Great work, much more clear to read the two guideline separately
Reply Share

Qwrt 7 months ago

Very good article. Really neat insight. Thanks
Reply Share

Pankaj H 9 months ago

Fantastic article Sir..
Reply Share

Amit Bassi a year ago

Great article! Have jotted every single point. Thanks Chris..
Reply Share

Simple Mishra a year ago

Great article.. I liked it very much..
Reply Share

valzyb a year ago

I agree with the comment about using a framework, such as Twitter bootstrap. Then the focus is on getting the app to work on any device. I have done this the other
way, building two sets of straight code (one for mobile, one for desktop). I agree that could take too long, depending on the builder. This is why we have frameworks.
Reply Share

Lisa kerrigan a year ago

fabulous article - thanks Chris
Reply Share

Dheeraj Messon a year ago

Awesome! read, well articulated
Reply Share

Eric S a year ago

it is crazy to me that there is not a free app to easily make apps with a common widget kit that work in both. :/
Reply Share

Teodora Vasileva a year ago

Great article! Thank you for explaining all differences in depth!
Reply Share
https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 10/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS

Mike T a year ago

all the images of the article appear broken !
Reply Share

Don Droga a year ago

In android you still need an app back button. The system back button isn't specifically to go back in an app. It's to go back in the system.

Any thoughts?
Reply Share

Chris Raymond a year ago

Thank you for a really useful article. It pulls together stuff I was trying to find as I am making my first forays into app UI design.
Reply Share

Martino Liu a year ago

Good one!
Reply Share

Pat 2 years ago

I think that HTML5/CSS3/JS web-app is the future. Because of too many platforms, too many screen resolutions, too many updates, etc.
Reply Share

kulkarninikhil 2 years ago

One of the best and most comprehensive articles on the subject of Android vs. iOS. However, I have a specific query in relation to designing an HTML5 mobile web-
app i.e. if I am not developing an installable app but am simply designing the mobile version of my web-app which will be primarily used by people on their respective
browsers, then what are the specific considerations? Which of the above styles, UI elements or patterns are more suitable to use in that case?
Reply Share

bcm > kulkarninikhil 2 years ago

I think the solution to that would be to use something more generic than either Android or iOS. Something closer to Bootstrap default design for example. After
all, some things such as alerts would still use the native os/browser style.
1 Reply Share

Chris O'Sullivan > bcm 2 years ago

Wow I didn't see these comments so long ago. Maybe you'll get pinged when I reply. That's a tricky question. If its mobile web you could see which
device is more popular and lean towards that platform. I see some websites adopting material design styles but I'm not sure it always works.
Particularly because some of the functionality won't work so well when its not native. I'd suggest leaning on these conventions in terms of the
architecture of the app, but coming up with your own visual styles that are platform neutral so they won't look too out of place
Reply Share

Subscribe d Add Disqus to your siteAdd DisqusAdd Privacy

Advertisement

ENVATO TUTS+

JOIN OUR COMMUNITY

HELP

24,139 1,030 14,183

Tutorials Courses Translations

Envato.com Our products Careers

2017 Envato Pty Ltd. Trademarks and brands are the property of their respective owners.

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 11/12
07/07/2017 A Tale of Two Platforms: Designing for Both Android and iOS
Follow Envato Tuts+

https://webdesign.tutsplus.com/articles/a-tale-of-two-platforms-designing-for-both-android-and-ios--cms-23616 12/12