Choosing to develop Android first

I was going to write this post shortly after our new native Android app hit the store at the end of May but decided to hold fire and let the dust settle so I could hopefully add some insight as to whether it was a good idea or not. While I covered the reasons for choosing Android first briefly in this article, I felt it warranted a bigger discussion.

The backdrop to this post was that at Money Dashboard we wanted to deliver a brand new native app on both the Android and iOS platform to replace a native wrapper around our responsive web application. Although the exact feature set was not clear from the start, there were some core functionality that we knew had to be included and so we set about developing this. Initially, we started to develop on both platforms at the same time splitting our resources evenly with Android only ever slightly ahead.

As the product began to take shape and decisions around what we wanted to include, so began the debate as to which platform to deliver on first. Initially, there was an understandable desire to release both apps at the same time but after careful consideration we desired against this. We wanted to gauge feedback from users and refine a single platform before taking those lessons and applying them to the second platform. There were real concerns that if we just developed the same app on 2 platforms, not only would it be longer before we would be able to get feedback, bugs would most likely appear on both and could result in poor reviews and a mad dash to get fixes out on both.

iOS or Android?

With agreement reached to focus on a single platform, the decision was simply which one first? There has been quite a bit of airtime given to this topic and much of it seems to favour delivering an iOS app first as highlighted in the following articles.


iOS first and Android much much later

The fallacy of Android first

Why Android first is a myth


For us however, we took the opposite approach and decided to push forward with Android based upon the following key reasons:

• We had more resources available to us for developing an Android app. We didn't require any new hardware (Android Studio on Windows) and almost all of the project team had Android devices. Furnishing the entire team with a Mac Mini each would have been a significant up front cost as would obtaining a set of test devices. 
• We run our continuous integration in the cloud and configuring a build agent for Android development was very straight forward. Our cloud environment did not have support for OSX and a local build agent for iOS would be required. 
• The development team were comfortable working in Java with many having used it at university or in previous employment. Objective C & Swift were brand new and with a steep learning curve for the team. 
• The Google Play submission process is significantly faster than that of Apple with the ability to submit a new version of an app into the store within hours as against a process which can sometimes take 7 days or more.
• Google Play has a nicely integrated beta facility which is easy to distribute your app to a defined group for early adopters (those who expressed an interest in our beta release were mainly Android users). 

Obviously there are also downsides to developing on Android, most notably the testing difficulties associated with the considerable fragmentation of the Android market. This article has a nice graphic illustrating the extent of the fragmentation and although we were under no illusions that we wouldn't be able to test every device/OS combination, we drew some comfort from our analytics which suggested our userbase was concentrated around a much smaller set of devices than we might have feared. As it stands, we are still a bit blind to how our Android app performs on many devices and although there are solutions out there such as Xamarin's Test Cloud which allow you to test on real devices, the cost can be a prohibitive factor. 

Conclusions

So, with the Android in the Play store and iOS nearly complete, the question is was it the right call? Well, after a soft launch of our Android app, inevitably we began to get some feedback from users and also became aware of some crashes. As a result, we were able to release a new version within 5 days of launch and another some 14 days after that - the key being that we were able to turn around those fixes in a matter of hours. This was a big win for Android as far as I was concerned and validation of our approach. We also managed to take some learnings from the Android app and roll them into our iOS app, notably an enhanced transactions screen which, although not specific to developing a particular platform first, was a clear benefit from not releasing both together.