How to port your iOS app to Android
A guide for app producers, choosing devices, OS versions, screen ratios, asset density buckets, UI conventions, distribution and submission.
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.
How do I know which devices to support?
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, 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
Which OS should you support?
For clients in North America, Europe and Australia, we usually recommend supporting the current operating system plus three back.
You may have heard that new Android OS releases have a very slow uptake, especially compared to iOS. But the type of customer who pays for apps is likely to keep their devices and operating systems up to date.
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 counterpart, and sometimes their device manufacturer may not decide to release an update for their device. 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.
What about screen size differences?
Even a shortlist of devices has a 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.
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 the standard 16:9 format. For these instances the iPhone X layouts in the iOS project which are 19.5:9 can be used.
Will different screen sizes and ratios affect layout?
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.
Should we adapt the UI for Android?
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.
How do I export graphic assets for Android?
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.
Understanding density buckets (for bitmap images)
If you’re exporting .png images, instead of grouping assets into four sizes like iOS, 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)
Android scales assets to the ‘most correct’ size, or ‘bucket’, for the relevant device screen.
Scalable Vector Graphics (SVG)
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 however. Graphics intended for SVG export can’t contain gradients or patterns, only path data and shapes. 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.
WebP
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.
Talking about assets and positions
When communicating UI and layout to your developer, don’t talk in pixels. 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.
How long will the port take?
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.
How do we distribute builds for testing?
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.
How does submission to the Play Store work?
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.
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.
Keep reading
More insights.
It's never just a patch: the human side of a critical security fix
When critical PHP vulnerabilities were announced on 21 October, we checked every system we support and contacted every client, affected or not. This is how we kept clients informed, which decisions we left to them, and why no fix skipped our usual checks.
Gwen Vaughan ·
Between the Wild West and the walled garden: how to build a trusted, secure agentic layer
AI agents will soon book appointments, switch energy, broadband and insurance for people. What CSOs, CTOs and CIOs need to settle first is identity, authority and trust. Marino Software has a track record in partnership with enterprise and organisations in regulated sectors. In this post, we look at a near future where people hand everyday admin to AI agents… and the security and trust decisions service providers need to make before they open the door.
Ed Melvin ·
The board wants AI governance evidence by Friday. Can you produce it?
Marino Software has a track record in partnership with enterprise and organisations in regulated sectors. This is the second post in our AI governance scenarios series - where we look at the pressure points AI is creating inside organisations, and what real and workable answers look like.
Ed Melvin ·