Expand Your Mobile Market: How to Convert iOS to Android
In North America, the iPhone has a substantial lead over Android in terms of market share — with nearly 60% phone users owning an iPhone. Because of this, mixed with the physical location of silicon valley, many organizations have prioritized developing and designing their software products around iOS.
However, smartphone usage continues to grow in other parts of the world and in other countries the field is very much weighted in the opposite direction. In Brazil over 75% of smartphone users opt for Android, in Argentina that number is 88%, and in India — with its population of over 1B people — Android has a market share of 93%. The dominance of Android in other countries (and its gains in North America) is creating a greater need for companies to retrofit their products to Android if they are to succeed in a global market.
The reality though is that retrofitting comes with challenges and isn’t as simple as a quick change of format. The code, the design, and the experience of the product can all be ruined during the conversion process.
Having been through the process on numerous occasions for our clients, we have identified the main challenges that seem to come up time and time again:
Main Challenges
Screen size
For iOS, screen ratios are fairly consistent; however, for Android the wide range of screen sizes, dimensions, and ratios means you have to design for more possibilities.
Screen density
Screen densities change between devices, even for devices in the same category. So not only do you have to think about the difference between iOS and Android, but also between iPhones and iPads.
Toolkits
The toolkit used for each language is always different, making the process more complex. On top of this, how these languages interact in changes between devices.
Gestures
The way people navigate their way through the product will dramatically differ between devices. Androids consistently use back buttons — although they are beginning to change this approach — as a key function of navigation, whereas iOS devices do not.
Exporting
Where Android supports both SVG (Scalable Vector Graphics) and WebP files, iOS only works using PNG and JPEG files. Although WebP files are smaller and faster than other file types (e.g. JPEG and PNG), the Zeplin software that we use for handing off designs to developers don’t work with them, making exporting files between Android and iOS difficult and converting a headache. SVG (for Android) and PDF (for iOS) are still used for vector illustrations like icons and line-drawings.
Screen Size
The standard Android screen size is 360 x 640 which is considerably shorter than the iPhone’s. In many instances the viewable area will be too short for all the content to show at once without the user needing to scroll. In those instances a fade may need to be added. Most elements from iOS are too wide for Android and need to have their width made smaller.
Line-items
On Android, cells that contain information place the name of the content underneath the title of the cell. This differs from iOS where the standard placement of information is on the same line, next to the chevron.
Snackbars
Snackbars on Android slide up from the bottom of the screen whereas on iOS they come down from the top of the screen.
Toggles
The toggle elements leverage the native UI of Android like iOS leverages their native UI.
Dialogue Boxes
Dialogue boxes are native elements where their layout is determined by the operating system. Header, description, and button position don’t change.
Keyboards
Keyboards on Android are different than iOS and also have a different layout. It’s important to consider which keyboard is needed on the screen at that time. For example, filling out a phone number would require the dial pad not the regular keyboard.
Native Elements
All of the previous things mentioned are native elements on Android and are different than iOS. Another consideration is the status bar and that Android, depending on device, has a back button overlaid on the screen at all times. These elements aren’t designed by us but are important to know are different than iOS. When converting designs between OSes, it’s important to keep track of elements and make sure they make it into the conversion. For help with this, Material Design is a helpful resource for up-to-date elements and rules.
Naming Conventions
On Android, images need to be named and organized differently than on iOS.
When exporting files, make a different folder for the 5 different densities: mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi. Sketch does this automatically if you use the “export for Android” drop down while exporting. Place different versions of add_icon.png with named as “add_icon.png” in all density folders.
Rules to adhere to while naming Android Assets:
- Valid character set for naming resources is [a-z, _, 0–9] i.e. All small-case characters, numbers, and underscore.
- Android: e.g. img_background_hdpi.png
iOS: e.g. Img-Background@2x.png - First letter of your asset name can be either _ or a small-case character, it cannot be a number.
- Do not use capital letters not even in extensions like .PNG or .JPG.
- Use _ as separator wherever you want to differentiate two words because — (hyphen) and space are not allowed.
- Asset names should be unique across the screens for an app. For example, if you have two “Add” buttons with different dimensions then you cannot name both as add_icon.png. You may create two different icons like add_icon_small.png and add_icon_big.png with all their density variants.
Icons
On Android, exporting icons that are vector is used with SVGs opposed to PDF which is used for iOS. Since it’s vector, we don’t specify the size when exporting.
Android doesn’t support masks, clippings, or gradients in SVGs. To optimize scaling, outline text and strokes.
Icons, like the down circle and down arrow (left), are SVGs that will be exported as their size on the screen. Since they are vector, they don’t need different sizes set by designers.
Although the peach illustration (right) is vector, since there are complex clippings, masks, and gradients it needs to be exported as a PNG.
Images (JPEG)
JPEG file types are for are images containing gradients, multiple masks, and clippings. If they have a vibrant colour palette then it should be a JPEG, not a PNG. For JPEG file types, there need to be 5 sizes:
Exporting from Sketch:
This example is a high-saturation image that has many colours and details as well as not being transparent.
Images (PNG)
If an image needs to have transparency then it needs to be a PNG. If it’s not transparent and has low saturation it can also be a PNG rather than a JPEG. For PNG file types, there need to be 5 sizes:
Exporting from Sketch:
The plane image has a transparency (this condition is the most important and cannot be accomplished by a JPEG). It is a low-saturation image that does not have very many colours.
Tablets
Because tablets have larger screens, we have to resize images to fit in their view ports. Resize images to 125–150% of their phone size. On top of resizing images we need to also export the images with 5 different sizes.
Exporting from Sketch:
We want to use WebP since they are smaller and the same quality. As a general rule, we also want to compress images before using them. This makes the overall app smaller without loss of quality.
WebP vs. JPEG and PNG
WebP is a newer image format supported from Android 4.2.1 (API level 17). This format provides superior lossless and lossy compression for images on the web. Using WebP, developers can create smaller, richer images. WebP lossless image files are, on average, 26% smaller than PNGs. These image files also support transparency (also known as alpha channel) at a cost of just 22% more bytes.
WebP lossy images are 25–34% smaller than comparable JPEG images at equivalent SSIM quality indices. For cases when lossy RGB compression is acceptable, lossy WebP also supports transparency, typically producing file sizes 3 times smaller than PNG.
For more information about WebP, visit the WebP site.
Having lived through the challenges of exporting between iOS and Android in our attempt to help our clients reach a wider user base, we at Connected have put together a useful, downloadable guide to serve as the foundational knowledge required to convert from iOS to Android. Every suggestion is built to not only help you convert your files successfully, but to do so in a way that maintains or elevates the product experience irrespective of the device it is used on.
Thanks for reading!
Download the PDF for Converting and Exporting for Android
