Whether you’re 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, we’d spend months
designing two apps. But in reality, many projects don’t allow that
much time. For any of the apps I’ve worked on, the deadline has been
tight enough for designing one app, let alone dividing the project
fully into two.
Quite often you’re designing one
app, with tweaks being made before handing it over to two development
teams. If you are designing an app in this
way, it’s 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
It’s likely that you will have a
personal preference for one system. I’ve always used iPhones, so I have a more natural understanding of the UI
patterns on iOS. The first 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 you’re 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 it’s a low expense compared to the
outlay on the design and development of a new app). If you’re working
freelance, you should be able to write it off against your tax bill.
2. Choose a lead
As we’re designing for both platforms
at once, whilst dealing with the real world where time is limited,
you’ll 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.
There are a lot of good, and free, UI
kits which you can use for your projects (you’ll find 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 that’s where I want to help.
Designing Your App
Follow these simple steps, and your app will be on the right track to fit in on both Android and iOS devices.
1. General style
Since iOS7, Apple has shifted to a
flatter design style, and ditched the skeuomorphic shadows, textures
and effects which defined the iPhone’s early years. Android, having been more systematic in style in the beginning, has gone slightly the
other way. Google’s 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.
iPhones don’t 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 shouldn’t be changing the height or style of these bars at all if you want the app to feel native, so I would recommend defining them once in your first 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 it’s 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 don’t need to consider the design. Just make sure when presenting mockups to use the correct one to avoid any confusion or distraction.
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. Apple’s
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 you’re 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 menus–a 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. It’s 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. They’re versatile and allow users to consume quick bites of content in a way that suits mobile behaviours. Visually, cards fit in very well with Android’s 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 flat. Instagram use an entirely flat design style, although each post could be considered a card from an architectural point of view. It’s worth looking at how Instagram gain the same component feel within an iOS style. If you’re going with cards on iOS be very gentle with any use of shadow, and try to keep them as subtle as possible.
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 you’re saving time you’ll 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 it’s advisable to at least test out your layout with both fonts.
If you want to go the extra mile, you’ll 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 you’re 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 defined and up to date. Either way, you will need a grid to work with, but with Android being more strictly defined 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 defined in Material Design:
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 shouldn’t 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.
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 flat in appearance, making no use of depth or drop shadows. The primary buttons have a fill 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 flat style right, it’s important to have clear and consistent metaphors for what colours mean in your app.
iOS also has a plain text style button, but it doesn’t share Android’s 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 fire method of making a selection. Bear in mind, however, that there isn’t a native iOS equivalent. In the example below, the user presses on “profile” in step 1, and is presented with a simple menu in that location to choose one of the available profiles. These menus are also used frequently from the overlay button in the action bar, indicated by three vertical dots.
Specific Data Input
For particular inputs like date and time, Android now comes with built in dialogues. These look like alert popups, but with UI specifically 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 they’re very
distinctive visually on each platform so it’s 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
It’s important
to get the style of these right because they might control important
actions like signing up, accepting terms, or even confirming payment. We want them to feel trustworthy and native.
The Android
alerts use the flat 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 field, and again they will inherit your active colour.
12. Icons
Icon design is quite the specialist area in UI design. Whether you’re using free icons, commissioning an icon designer, or designing the icons yourself, there’s a distinct style native to each platform. iOS popularised line icons, with very thin strokes. The Android system icons have thicker strokes, or are entirely solid icons. In the past, Android icons used perspective or a three dimensional twist, but now their guidelines specify two dimensional icons viewed straight on. Here’s a quick example with several icons for comparision, or use the direct links to icon guidelines for Android or 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 definitely 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, fields 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.
Summary
It isn’t 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 you’ll 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 I’ve provided can be found in the platform guidelines. They’re quite extensive, so I’ve just pulled out the parts that are important to compare. But if you have more specific 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 you’re making your own, or commissioning icons, they’re useful to have as placeholders while you work. Icon design can be a job in itself, and you don’t 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 flaticon.com is great for more general icons.
Line icons which are great for iOS design
Flat icons that work well with material design
Mockups
It’s 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 simplified flat device to let your app shine, or a lifestyle mockup to present a use case. Here are a few resources I’ve 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 they’re Google’s own phones and won’t hint at a preference towards other manufacturers.
Official iPhone device downloads
Flat apple devices with multiple perspectives
Nexus 6 flat mockup
Lifestyle mockups from placeit