Converting Your iOS Application to Android: Part 1

One of the biggest catches of building applications with native tools is they only work on one platform, and migrating an application takes time. After eight years on the iOS App Store, 250,000 downloads and many user requests for an Android version, I finally decided to migrate my most popular application, Subtitles Viewer, to Android. Here is some of what I learned on the journey.

First things first - why bother? If you have an iOS application that works fine, why put in all the work to convert your iOS application to Android?

Why convert your iOS application to Android?

Currently, iOS has just 27% of the global smartphone market, while almost all the rest are Android based (72%). That adds up to about 3 billion (that’s billion with a ‘b’!) active Android smartphone users that are not able to access your application. In the US, the story is a little different, with iPhones actually leading Android 55% to 44%. However - even if your market is focused purely on the States, you are still turning away nearly half of your potential customers at the door.

The story isn’t quite so simple though - even though Android outnumbers iOS smartphones 3 to 1, iOS users are much more likely to spend their cash on applications than Android users. In fact, your application installed on 1,000 iOS devices will earn about 4.5 times more on average than if it were installed on 1,000 Android devices. If you’re looking to maximize revenue, whether through application or in-app purchases, having an iOS application is obviously a very important part of your business strategy. However, if you’re reading this article, you most likely already have an iOS application, and are questioning whether it would be worth building an Android equivalent. And though each application installed onto a specific Android device is likely to generate significantly less revenue, Android is still an important feature of generating application related income, due to the sheer numbers of Android devices. In 2021, iOS applications earned 63% of total global mobile application revenue. This means that if you decide to not migrate your iOS application to Android you will be missing out on almost 37% of your potential income.

So far we’ve looked at revenue, but what about costs? As you probably are aware, if you would like to earn income from application sales on an Apple device, you will need to be part of the Apple Developer Program, which costs US$99 annually. Google, on the other hand, only charges you a one-off registration fee of US$25. Both companies also keep a percentage of your royalties. Apple keeps 30% of the income your application generates, unless you qualify for their small business program, which reduces Apple’s percentage of your income to 15%. Android takes a similar percentage royalty to Apple, taking 15% of your application’s income for the first million dollars. After your application has generated more than one million dollars, then Android adjusts their royalties to 30%. If that detail becomes relevant to your situation, I believe kudos is in order.

Considerations when Converting your iOS Application to Android

On the one hand developing for all of these Android devices does mean many more potential users of your application, but on the other hand you will need to take extra care in ensuring your application works on the vast array of different Android devices. Even if you consider all iPhones Apple have ever released, at the time of writing you only reach 34 different devices. Compare that with Android - Wikipedia keeps a list of all Android smartphones ever released, and at the time of writing the list numbers greater than 1,400. Of course you won’t expect your application to work on early Android devices but even just including devices since 2020 adds up to nearly 500 devices. That’s 500 devices with diverse specs, memory, speed, screen types and resolution that you’ll most likely want your application to work on.

Working in iOS, you’ll of course be accustomed to working with devices built just by Apple, with a familiar look and feel. Android, on the other hand appears on phones and tablets built by a wide range of brands - the same Wikipedia list above lists 73 unique Android brands, many which even have their own custom firmware built on top of the Android system.

While all iOS applications are distributed via the App Store, Android applications in Android are generally distributed via the Google Play Store. That said, some brands, such as Samsung or Amazon, integrate their own proprietary application store either alongside or instead of the Google Play Store. If for example, you want owners of Amazon Fire devices to be able to use your application, you will need to submit it to the Amazon Appstore.

When designing your application for iOS, you no doubt would be familiar with the App Store Review guidelines. This describes all of the guidelines that your application must comply with to be successfully accepted to the App Store. Android has an equivalent set of guidelines for submitting to Google Play, which you can access at the Google Play Policy Center. These guidelines have many similarities with Apple’s, restricting developers from publishing inappropriate content, infringing intellectual property, transparent handling of user data etc. Of course, if you are to submit your application to third party app stores such as Amazon Appstore, this introduces yet another set of guidelines that you must adhere to.

Another document which I’m sure you’re familiar with is Apple’s Human Interface Guidelines, which provides you with recommendations to follow to be consistent with Apple’s design aesthetic. Android has similar guidelines, called the Material Design Guidelines, which have actually recently been updated for Android 12 (released October 2021), called Material Design 3. This is where you’ll see more differentiation between Android and iOS. There are different naming conventions, standard fonts, and styles of navigation. In iOS, custom views such as buttons, switches, labels, sliders and pickers are called controls, while in Android these are called material components. You’ll find many Android material components have a different look and feel to their equivalent (if there is an equivalent) in iOS. In iOS applications for example, you are likely to move between tabs at the bottom of the screen - in Android, tabs appear near the top of the screen, and if you would like tabs at the bottom of the screen you will need to use what’s called a bottom navigation bar. It would be a good idea to have a look at Android’s Material Design Guidelines and devise a plan on how to convert your application’s interface from an iOS aesthetic to Android.

If you don’t have an Android device, it’s worth considering purchasing one, and familiarizing yourself with the Android approach to user experience. There are also certain features that the Android emulator (the equivalent of Xcode’s simulator) are not able to reproduce, and to test them properly you will need a device. Also, nothing beats actually experiencing how your application operates on a physical device with a touch screen - it’s here, where you’re using the touch screen and experiencing your application on a real device, where you’ll often discover issues you might not have noticed in the emulator.

After weighing up the pros and cons of making the transition to iOS and considering all of these factors, I decided (admittedly after several years of procrastination!) that it was time to migrate Subtitles Viewer from iOS to Android.

In part 2 of this series, I’ll be doing a deep dive into similarities and differences in developing an application for Android vs iOS.