Porting iOS to Android (Part 1)

Introduction

It has become common practice in today’s market to launch a mobile app exclusively on iOS and then later port that iOS app over to Android. As an Android user this bothers me because I want all the apps right now, but as an Android developer and member of a product team, I actually have come to like this trend.

This market-by-market user adoption strategy may annoy any Android fanboy, but I am going to try to explain how this makes for a better and more streamlined process for your product team. I will talk about some advantages, things to watch out for. Our next post will jump into some tips and tricks for what you are bound to run into on a port job. And Finally I will end the series with an essential checklist that your team should go through for any port project.

Advantages

When you start a port project, the main advantage is that all facets of the team have already been involved. Your management, design and even development teams have already worked on the product and run into and solved their own challenges. Usually in the software product lifecycle, a developer is the last one to contribute to the project and that can create some problems when some unexpected things occur.

With porting, you get to work on a project that has been through at least one phase of development. Your Android developers will most likely be able to reach out to the iOS developer for help. In my experience, my iOS counterpart has always been ready to help and eager to tell war stories. They will tell you about all the API bugs they found at 2am the day before a demo, or how they found it was easier to structure the data model a certain way. These little tidbits of information can really save your new Android developer time and headache.

Having an existing app to reference also means that the product vision has likely solidified. The development team isn’t working on a wireframe that has never been used by a real user. The back end will usually be much more well rounded and mature than when iOS development started. You have some security knowing that the features your team is committing time to will stay and bring value to the product.

Things To Watch Out For

While you get all those advantages of an app that been through the development fire, your team is now expected to do it faster and just as well as the iOS equivalent. You won’t be allotted the extra development time meant for anything strange that your team may run into and may feel extra pressure to finish early. Android and iOS are both mobile operating systems, and while they share many similar UI features, your team will need to make sure you are focused on building a great Android app, and not just copying your iOS app.

You may run into the “just make it look the same” attitude. A great way to avoid this attitude is to get the team to look at the app from the perspective of an Android user. Remember that using standard Android UI will be faster and more reliable than forcing your Android team to create custom UI to mimic iOS. It may seem obvious, but reminding everyone that iOS users and Android users interact with apps differently will really help you create a great Android app.

Lastly, you will need to make sure that whoever is testing or approving the app has some Android experience. They don’t need to be experienced Android users who could tell you how steep the learning curve to Tasker is (seeing if there are any Android readers out there…), but they do need to read up on the most up to date Android guidelines. The best thing someone could do to get a good feel for Android is to read up on Material Design and get familiar with the top 5-10 Android apps. Most people I have run into have enjoyed this assignment. It’s fun to get to play around on a different OS and see things from a different perspective. Stay tuned for part 2/3 next week! 🙂