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:
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.
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.
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.
