Let’s suppose you have your own startup – a mobile app for iOS. It would only be logical to make an identical version of it for Android to get more recognition and profit. The thing is, in order to adapt code written in Swift or Objective-C to Android, you’ll need to translate it into Java or C. But it doesn’t stop at translation – you’ll have to create an absolutely new app based on existing iOS code foundation. In today’s article, we will discuss in details how to port an iOS app to Android.
Reasons to Port from iOS to Android
You might still believe that porting apps from iOS to Android is a risky affair for businesses, or, you may think it’s a marketers’ smart plan to get more money out of their services. In this case, take a look at the statistics presented in the Android Authority blog. As you can see, Google Play has far more downloads than those on the App Store, which means that, without the Android version of an app, you’ll lose a colossal number of potential users.
That’s not all. It’d be fair to note that free apps are far more popular than paid options (especially, if we’re talking about Google Play), so keep in mind that you may have to rethink the pricing politics of your software for both platforms and even transform the paid version into a freemium one.
Have we managed to assure you that you need porting yet? Let’s go on then…
Porting iOS to Android
How much does it cost?
When we’re asked how much it costs to port readymade solutions from one platform to another, we always answer that such a procedure implies practically the same steps as building an app from scratch. The already-created functionality must be adapted to all the unique design and UI features of the app on both platforms. All that work might significantly complicate the migration process and, as a result, it can take much more time and money than initially planned. On average, it takes 15-18 weeks, though only developers can give you more detailed predictions.
Don’t be disappointed by the time frame, though. In most cases, you will be compensated by all required costs, eventually. In order to keep from filling your head with empty worries about upcoming expenses, think about the statistics we’ve mentioned as frequently as possible and imagine how much profit you can make having properly adapted an iPhone-based app to a new platform.
Now, let’s get down to business. Let’s define the main stages of porting to Android and find out on what aspects developers will have to spend most of their time and strength on.
Adapting software to user devices of various formats
Building an app for iOS, one doesn’t have to put too much effort into adapting it for loads of user device screen sizes. Thankfully, there are not many screen sizes for Apple, and they’re all available in the Xcode 9 simulator. What can we say about Android-based devices in this regard? Well, significant effort is required.
One must be ready to duplicate all the assets related to frontend implementation numerous times to describe various formats, due to the complete absence of screen dimension standardization. As a result, you may get five folders with files of mdpi, hdpi, xhdpi, xxhdpi, and xxxhdpi formats (this issues can be fixed, however, by employing svg images). Android terminology refers to such folders as “density buckets”, thus, in most cases, most of the time dedicated to port iPhone apps to Android is spent testing the created Android version on many typical Android devices.
Conduct marketing research in the area your target audience is located in order to understand which devices must be tested in particular. Why do the research? It will help to point out the top ten or twenty most popular Android device models that require full compatibility. Based on practice, people tend to prefer Samsung Galaxy smartphones in most countries around the world, though, considering the growth in popularity for Chinese Huawei and Xiaomi, such a tendency might have a short lifespan.
iOS to Android app conversion is almost always a huge headache for a developer, especially when it comes to design, in particular. If this aspect isn’t changed properly, your app won’t be approved by Google Play and all the costs will be in vain.
How can you avoid this? It’s simple: your team of designers will have to take some time and effort and find a compromise between the iOS Flat Design and Android Material Design. Each type of design has plenty of specifications, and we will point out some (but not all) of them here.
When you convert an app from iOS to Android, the following user interface elements (which can seem hardly noticeable at first) must be paid the most attention to:
- back button (vertical check mark in iOS; arrow in Android’s Material Design)
- location and format of menu items (in iOS they’re closely grouped and separated by a thin horizontal line; in Android they’re not separated in any way and have more distance between one another)
- control panel location (at the bottom of the screen in iOS; at the top of the screen in Android)
- switch buttons (the switch is plain and the same size as its socket in iOS; it’s larger than the socket and seems as though it’s dimensional in Android)
- options (unlike Android, iOS provides leading arrows for each option)
- fonts (San Francisco for iOS, Roboto for Android)
- icons (iOS icons are minimalistic and feature thin lines)
- sidebar menu (icons for each menu item in iOS are quite large as opposed to their interpretation for Android)
In order to avoid errors, we’d recommend not using the UI graphic creation tools developed at all, especially when it comes to iOS. What can you use, alternatively? There are plenty of options like Photoshop, Visio, Balsamiq, and many other pieces of software. Also, don’t forget about the Material Design Kit. Try some of these and remember to adhere to Material Design politics and not try to recreate an identical copy of existing design for iOS.
Various OS support
Similar to iOS-based app development, you must make your Android software compatible with older versions of the OS. You’ll also have to start adapting it to Android-based tablets when you’re done with at least Android 4.4 compatibility. And that’s just the beginning. Starting from the fifth version, Android started introducing its own app design standards under the collective name Material Design (mentioned above), and your app must meet absolutely all of its requirements. Fortunately, Google developers have provided us with a very useful tool – the Support Library, which can make support of the older OS painless. It provides support of old versions of Android, up to version 1.6.
Support of the oldest versions of this OS can result in a huge price tag without bringing in too much profit, though. We strongly recommend familiarizing oneself with the current geography of user devices (you can do this via DeviceAtlas service). Here’s an example. Support of the versions starting from KitKat would be enough for economically advanced countries. In turn, if we’re talking about India, for example, you’d better also take care of the older version – Jelly Bean. Last but not least, don’t forget that some Android-based devices don’t support updates to the latest OS versions. Make sure to provide compatibility with not only the latest versions of Android.
Surely, one can’t just go and move the app from Swift/Objective-C to Java or C. To do that, one would need the help of an experienced team of developers that have had the opportunity to work on similar projects for both platforms. We provide certain tips below, which would help avoid a bunch of mistakes and focus your general activity on transferring the UI functionality.
Work on performance
We won’t say that Java compiles slowly, because it doesn’t. It’s just that the complex logics defined by Java don’t work as fast as Swift/Objective-C logics. This can be pretty noticeable on devices with low technical specs. Thus, try to keep UI simple.
That’s not all. An insufficient level of performance can negatively affect Java-based apps with an unrationalized process of class object creation. To prevent these problems, think about writing part of the code in C.
Define capabilities available to Android
Unlike iOS, Android supports widgets – home screen features that strip user of the necessity to open an app? In iOS, those are applicable only in Notification Center. Think this over – perhaps, some functionality that was pretty difficult to implement on the previous platform could be effortlessly transferred to Android. It may also be the other way around, however.
Know your processors
Do you know which processor most modern Android devices are based on? Such knowledge can directly influence your app’s speed of performance. As a rule, the latest Android devices use processors with ARM microarchitecture which don’t support floating-point operations. Smartphones based on iOS, on the other hand, support such a procedure.
If your solution constantly processes numerous user requests and is not of the multithreading nature, keep it that way so your users don’t face low speeds. Particularly, pay attention to the following recommendations that tell you how to provide a multithread nature for an app.
To convert an iPhone app to Android means to make a huge step towards its increased popularity (for business too). You’ll witness yourself that a proper, systematized approach can help you create a solution almost identical to its previous version and no less inferior in functionality, accessibility, and performance.
So, how do you make the converting process simple and fast? Hire experts. We, at Ego-cms are well equipped to become your converting team. The result of our collaboration will be an app as similar to its original version as possible that would be supported by all the popular Android-based devices.
If you need to get information on your project development our managers will be more than happy to answer any questions!