Your iOS app is in the App Store and is doing great in the charts. Doing so well in fact, that it’s time to organise a port to Android.
If you’ve never ported to Android, you may be wondering where to start. The good news is, it’s a fairly straightforward process and much easier than creating an app from scratch. Yes, there’s new code to write and UI to adapt, assets to export and QA to prepare for. But from the start, everyone on the team is clear about how the app should look and work. After all, it’s all there on iOS as a blueprint.
You probably don’t have the time or sanity to develop and test for every one of the thousands of Android devices on the market. Nobody does.
You’ve all heard about Android’s fragmentation problem. Apple devices are made by the same company, have a small range of screen sizes, and use the same operating software (iOS). Android devices are made by different companies, with thousands of different devices and many screen sizes.
Device fragmentation is a problem, but it’s not your problem. That’s because Android developers generally support just 5–10 of the most popular devices in their target market.
When choosing which Android devices to support, your intended audience is key. For example the five most popular devices in the USA are different to the most popular in North Africa. They will also run different operating systems and have different hardware components.
For European and North American clients, as of February 2021, we regularly support:
- Google Pixel 3, 4, 5
- Google Pixel XL 3, 4
- Samsung Galaxy S7/Edge, S8, S9, S10, A12
- Samsung Galaxy Note 8, 9, 10
- Huawei P10, P20, P30
- OnePlus 5, 6T
- Xiaomi Redmi 4, Redmi Note 9
For clients in North America, Europe and Australia, we usually recommend supporting the current operating system plus three back. For an Android app with an audience in a country like the USA, that currently means versions 11 10 , 9 (Pie), and 8 (Oreo).
You may have heard that new Android OS releases have a very slow uptake, especially compared to iOS. For example Android 8 (Oreo) was only on 0.5% of devices two months after release. But 0.5% of the global Android audience is a lot of people, especially when you consider that iOS has less than 15% of global share. Also keep in mind that the type of customer who pays for apps is likely to keep their devices and operating systems up to date. Take the popular Pocket Casts app as an example. Developer Russell Ivanovic explains that when Lollipop was at just 1% global uptake, 23% of their audience was using it.
Depending on your target market and the type of app you want, you may want to consider going one more OS level back. Android users don’t get OS updates as quickly as their iOS counterparts, and sometimes their device manufacturer may not decide to release an update for their device. This means that a relatively high percentage of users can be using a version that’s several years old. For example, as of Summer 2020, 25% of users were still on Android 7.0 or older. Bear in mind though that supporting more OS versions may increase costs, due to the extra QA effort involved and potentially also extra development effort.
Even a shortlist of devices has variety of different screen sizes. This is going to be a nightmare for design, right?
In fact most popular devices of the past few years use the same display aspect ratio. The aspect ratio is the proportional relationship between a screen’s width and height. Two devices may be different sizes, but proportionally they are the same. This means the same design layout will work across many screen sizes and resolutions.
Let’s look at the aspect ratios of our regularly supported phones and tablets:
As you can see, while these phones may have different screen dimensions, the majority of them have the same aspect ratio: 16:9.
Recent additions to product lines have introduced some new aspect ratios to consider. The Galaxy S8 and S8+ with an aspect ratio of 18.5:9 and the Pixel 2 Xl with an aspect ratio of 18:9 deviate from our standard 16:9 format. For these instances the iPhone X layouts in the iOS project which are 19.5:9 can be used.
As you can see, while these phones may have different screen dimensions, the majority of them have the same aspect ratio: 16:9.
More recent additions to product lines have introduced some new aspect ratios to consider. The Galaxy S8 and S8+ with an aspect ratio of 18.5:9 and the Pixel 2 Xl with an aspect ratio of 18:9 deviate from our standard 16:9 format. For these instances the iPhone X layouts in the iOS project which are 19.5:9 can be used.
For a more comprehensive list of device metrics Google has created this handy list. It covers popular phone, tablet, PC and watch screen and touch sizes for Android, iOS and Windows.
You may decide to support phones or tablets with varying aspect ratios. In this case, Android’s layout system is similar to iOS’s ‘Auto-Layout’ which allows layouts to flow in order to accommodate variances in screen sizes and ratios. Phone layouts will work on tablets, but you can elect to create separate layouts to take advantage of larger screens.
When porting your design, this all means preparing and designing with layout in mind, just as you would with iOS. If you want to understand more about Layout, a good resource is Google’s Layout guide for Material Design.
Before you begin adapting UI for Android, it’s important to talk to your engineer. While it may be perfectly doable to completely reproduce the iOS UI for Android in some circumstances, there may also be times where certain functionality, which might come out-of-the-box on iOS, could be a massive undertaking to try to reproduce on Android, and vice versa.
Google strongly recommends following their design and UI language, ‘Material Design’. Not only will an Android audience be familiar with common Android UI (and therefore feel more immediately comfortable using your app), Material Design’s common UI elements have better support for developers, reducing engineering time. Another thing to bear in mind is that if you have aspirations of getting featured in the Play Store, Google will not look favourably on your app if it doesn’t follow their UI guidelines.
You’ll need to adapt your app’s graphic assets for Android and this means resizing, exporting and naming new files. Admittedly, it can be a bit more involved than exporting assets for iOS but once you’re organised it’s a piece of cake.
If you’re exporting .png images, instead of grouping assets into four sizes like iOS (@1x, @2x, ~568h@2x, @3x), you’ll be grouping png assets in 5 sizes, or ‘density buckets’, each of which gets its own folder:
mdpi (medium ~160dpi)
hdpi (high ~240dpi)
xhdpi (extra-high ~320dpi)
xxhdpi (extra-extra-high ~480dpi)
xxxhdpi (extra-extra-extra-high ~640dpi)
Each density bucket is related to a device display’s PPI or DPI (pixels-per-inch or dots-per-inch, often used interchangeably by device manufacturers). PPI/DPI are not related to the physical screen size; they relate to how densely pixels are packed together within a particular screen size.
It would be a huge headache to create precisely sized assets for each Android device density (plus app sizes would be enormous), so Android’s solution is to scale assets to the ‘most correct’ size, or ‘bucket’, for the relevant device screen. This is why graphic images don’t always appear as beautifully crisp as they do on iOS, which scales exactly x2 or x3.
To keep it simple: the higher the density bucket, the bigger the assets need to be.
If your assets are vector (e.g. created in a program like Sketch or Illustrator), we’d recommend designing at 1x (mdpi) and scaling up from there. It just makes life (and exporting) simpler. For an Android phone app, your scalings will look like this:
If your assets are bitmap (e.g. created in a program like Photoshop), you’ll need to scale assets down from the largest supported screen size so they don’t lose quality. For example, if you’re supporting a device with ~640 dpi you’ll size your iOS assets to xxxhdpi and scale down:
File naming is more restrictive in Android than iOS and all versions of the same file must have the same filename. Filenames must always be in lowercase, with no spaces.
For example “file_name.png” is good;
“File name.png” won’t be accepted.
To separate assets, you’ll save them into different folders: mdpi, hdpi, xhdpi, xxhdpi and xxxhdpi (except if your assets are SVGs — see below).
Apart from the added labour, having multiple versions of the same graphic has the disadvantage of bloating the size of your app. Luckily Android has a trick up its sleeve here in comparison to iOS. As of version 5, Android has the ability to use a single vector graphic in place of multiple raster graphics. This has the potential to dramatically reduce the size of your app, while also reducing the workload for designers producing (and inevitably amending) graphics.
There are a couple of caveats to be aware of however. As most designers will know, not all graphics are suitable for conversion to SVG. Graphics intended for SVG export can’t contain gradients or patterns, only path data and shapes. Also, a large vector graphic is more taxing on the CPU in Android, and as a result, the recommended size limit for vector graphics is 200dp x 200dp. Finally, Android doesn’t actually support the SVG format and instead uses its own ‘VectorDrawable’, which currently only supports a subset of SVG functionality, e.g. no gradient support. We recommend that designers test their SVGs are compatible with VectorDrawable before handing them to the engineers.
What this means is that using vector graphics isn’t quite a silver bullet that will allow you to completely avoid the tedium of exporting multiple versions of your app’s graphics. However, they are ideal for things like icons, so depending on your app’s design, they could potentially save you a lot of time and effort, while keeping users happy by reducing the size of your app.
For graphics that are unsuitable for conversion to a vector format, consider using the WebP format instead of PNG. WebP can compress an image by as much as 90% before a noticeable degradation in quality, meaning that you can include a reasonable amount of raster based images without bloating the size of your app too much. Android Studio also has a handy built in converter, so all your files can be converted in a matter of minutes!
When communicating UI and layout to your developer, don’t talk in pixels. As we’ve discussed, pixels can be a moving target. Talk instead in SP (size independent pixels) for fonts that you want to be able to scale up and down with the device’s font size settings; and DP (device independent pixels) for fixed font sizes and everything else. Understanding this is simple, just follow the guideline:
For font: at mdpi, 1sp/1dp = ~1pt
For everything else: at mdpi, 1 dp = ~1px
Read more about these concepts at the Android developer portal.
Talk to your engineer early in the schedule to discuss the best workflow for saving, delivering and updating assets. We have been using Figma as a tool for creating screen layouts and is also excellent for exporting assets in all of the various density buckets. We use a Figma plugin called Android Resources Export which does all the heavy lifting for you automatically creating and organising PNG images into folders for each density bucket.
If you prefer to use SVG for icons etc. then Figma can natively export to SVG.
Since the app has been made for iOS already, shouldn’t development take no time at all?
Although porting can be straightforward, it’s not necessarily faster. Your engineering schedule will depend on the complexity of the app and the selection of devices you are supporting.
Android is a completely different software system to iOS. Device manufacturers use customised versions of the Android OS which may require different software solutions between devices. Different devices (even from the same company) can use unique hardware components. These inconsistencies can cause your app to interact with a device’s OS and hardware in unexpected ways.
For example, one of our Android ports included a bespoke camera application allowing the user to take photos and videos, edit, label and interact with them. The camera hardware and Android software is very different to those in an iOS device. Also, the Android app needed to work on devices with Android 4.0 upwards. However the camera hardware interacted very differently with the 4+ (Jelly Bean) OS than it did to OS 5+ (Lollipop). This meant days of additional and unexpected work for an engineer to address different camera scenarios and to fix the inevitable bugs that appeared in QA.
As you can see, device inconsistencies create surprises which, even if small, can mean additional time for engineering.
Distribution for Android devices is much easier than iOS. Distribution can be managed via a service like App Center or builds downloaded directly to your device from a file sharing service or email. The Google Play store also facilitates internal testing as well as Alpha and Beta releases which are handy if you want to distribute your app to larger groups of testers before the final release.
For a producer, getting ready to submit to the Play Store is similar to the iTunes process. You’ll provide your developer with things like screenshots, ratings, region, price and copy about your app. From a Producer point of view, the big advantage to iOS is time: whereas Apple can take up to 10 days to review your app, Google normally reviews and approves or rejects on the same day.
Guidelines and policies for submitting your app to the Play Store are kept current at the Android Developer Console.
As you can see, porting from iOS to Android doesn’t need to be a headache. At Marino, it’s some of our favourite work. If you discuss the project with your developer before you start and take the time to understand how to prepare assets for Android, your port can be smooth sailing. Happy porting!
We’re ready to start the conversation however best suits you - on the phone at
+353 (0)1 833 7392 or by email
