We recently launched an iOS app called Color Dating (you can check it out here) which is a racially segmented dating app. You can read about our initial server and iOS build strategy here.

Due to the network effects of dating apps in general, we knew that we had to quickly expand into the Android marketplace if we wanted to remain competitive in the space. As a caveat, I think a lot of startups make the mistake of prematurely porting into Android when they may be better off just focusing on one primary market. What we’re quickly learning is that once you release an Android app, it becomes a war on two fronts and there are striking differences in how one needs to manage a growth strategy for both of these marketplaces. However, that’s a topic for another time.

I’m a seasoned iOS developer who has only programmed rudimentary projects for Android. Porting our iOS app into Android was going to be my first big Android project and I wanted to share a bit about of what I learned.

Biggest Obstacles to Overcome

Programming for iOS and Android has many similarities but there are also BIG differences that are quite intimidating to first overcome. These can be frustrating for iOS developers and may discourage many people.

I think one of most effective strategies when learning something new is to compare to something you already know. It’s especially important to understand the parts that can trip you up, so when you encounter these inevitable issues, you can continue forward and not give up. Hence in the part 1 of this blog, I’ll only address the major differences first.

1. Storyboard vs XML layouts

Us iOS developers like to give Apple a lot of shit for Xcode particularly when it’s slow, buggy and always crashes on us, but I think one of the reasons why apps on iOS look as good as they do is the simplicity and usability of Xcode’s interface builder when constructing layouts.

At the end of the day, it’s a essentially a drag and drop interface builder and allows to do remarkably crafty things in a very short amount of time. Even though there are frustrating concepts like Auto Layout which is notorious for always breaking, it’s still relatively straightforward to implement and debug once you’ve gotten the hang of it.

Screen capture of a typical Xcode storyboard layout

On the contrary, when you’re developing for Android, the first thing you have to accept is you’re going to have to throw pretty much all of this out the window. This not that much crossover here.

In Android, you’re going to be working almost purely in XML, that is, no more drag and drop interfaces, no more nudging elements, no more Auto Layouts. When you’re developing for Android, essentially 95%+ of all of your UI work will come from you typing it manually into an XML sheet.

Standard XML layout for an Android project

The sooner you accept this, the faster you can learn it and move on. Because of the lack of an easy right panel interface and a drag and drop UI, you’re going to have to learn and memorize a new set of Android layout properties such as the difference between “match_parent” and “wrap_parent” or the differences between a RelativeLayout and a LinearLayout collection.

The good news is that the new Android Studio has an amazing autocomplete and autosuggestion so it’s really not as bad as you think. Also, as you advance and get more familiar with XML, you can using ConstraintLayout which works for OS’s 2.3 and up and is very similar to Auto Layout.

2. View Controllers vs Activities and Fragments

iOS developers are used to View Controllers. They exist as the logical backbone for a view container. On the the hand, with Android, we have something called “Activities”. They are similar to View Controllers but have VERY BIG limitations that iOS developers aren’t used to and can cause a lot of frustrations.

Most resources that try to explain Android development to iOS developers state that an Android Activity is basically analogous to a View Controller. For the most part, this may be true, but I’m sure most of us iOS developers know that we’ve done a lot of View Controller hacking before, predominately things like nesting View Controllers side by side or in partial modals, or something like hot swapping out View Controllers in the case of menu navigation.

When porting an iOS app into Android, it makes sense that we want to incorporate these similar UI flows into the Android app, but this is when using Activities WILL BREAK DOWN.

Key things to note about Android Activities is that you cannot have two activities running at once. When you try to nest two Android activities or two side by side, your app will crash.

My advice is to keep Android Activity usage at a minimum and use it to port View Controllers with basically zero overlapping logic. Unlike with View Controllers, passing logic between Android Activities is a HUGE pain. Saving and restoring states of Activities once you’ve dismissed it also a HUGE pain. If you’re looking to implement a modular container type View Controller, you’re almost better off implementing something called a Fragment.

As an iOS developer, you’re going to have different tendencies and think about MVC logic and encapsulation differently than an Android developer. In summary, you’re not going to use Activities as often as you would use a View Controller. An Android Activity exists as more of a “pure” controller in the traditional MVC paradigm. Only create new Activities when feel like the logic in it is going to be well encapsulated, otherwise, you’re thinking of a Fragment.

3. Swift / Objective -C vs Java

I won’t get too deep into it, but another large difference between Android and iOS is obviously the language difference. There are certain things you’ll have to be hyper aware of, Null Pointer Exceptions being one them. Or things like not having easy access to synthesizer methods or IBOutlets for fetching objects from the view.

Alternatively, you may try Kotlin which is a statically typed programming language for the JVM. As someone coming over from Swift, this may feel a lot more familiar.

4. Device and OS Fragmentation

If you thought testing and maintaining an iOS app across 4 different phone resolutions was bad, oh my god just wait until you get to Android.

As I mentioned before, one of the reasons why many iOS apps are visually superior to their Android counterpart is because of ease of use of the interface builder. Well, another huge factor in why iOS apps look better is because of the compatibility a developer has to deal with when developing for the Android platform.

An iOS developer may have to consider several different form factors and a device families when developing an iOS app. An Android developer may have to consider hundreds if not thousands of devices. (There were 18,796 unique Android devices as of 2014). Pair that with users still on legacy Android OS versions and you have hundreds of thousands of combinations of things that can go wrong.

The end result is that when you’re developing for Android, you will have to really narrow down your scope more so than in iOS. If you have a project manager or a designer that really wants something done a certain way for Android, you’re going to get into the habit of always pushing back.

Really fancy custom animations? Push back. A visual style that deviates from the standard Android style? Push back. Unique UX flows and organization elements? Push back.

The smaller your scope, the more robust your core elements can be. Once you launch your project, you will inevitably see bugs in different OS versions and device screen sizes, even if you were using well established Github libraries with thousands of stars. Using established conventions and not going overboard on custom elements can make the difference between spending hours on fixing bugs and spending weeks.

5. Developing on Android Will Be Slower

With Xcode, we use simulators. On Android, you’ll be using emulators. When you have to replicate the entire OS on an emulator, it’s going to be more slow. When it’s slower to launch your app between writing code, your whole process is going to be more slow.

Also, Java is a lot more of a verbose language than Swift. There are lot of things that the language doesn’t automatically take care of for you such as getters and settings, null pointer checks or callback blocks. By ways of characters typed, you’ll probably be spending more time typing while developing an Android app than on iOS.

(As mentioned before, this is just evaluating Java. You may want to check out Kotlin if you’re in the mood for something faster.)

Positive Differences

I’ve listed quite a few negative differences between the iOS and Android platform, but there are certainly positive differences to look forward to as well. I’ll address these below.

1. Prepackaged CocoaPods with Gradle

Gradle is the prepackaged CocoaPods equivalent for Android Studio. Some people hate Gradle, some people love it but the fact that it’s already packaged within the IDE means I’ve found it to be less hacky and less buggy in general. It’s not often that I would have clashing dependencies as I might have to resolve with CocoaPods.

2. It’s Way Easier to Ship to Android Play Store

Apple’s App Review time has gotten better in recent months, but older iOS developers may have remembered the experience of painstakingly waiting 5–10 day until your app update was approved and in the App Store. Meanwhile, all of your users are complaining, your reviews are tanking and your boss keeps on asking you over and over when the hell the version will be live.

Android is a lot simpler. You basically upload your APK and then click submit and your binary online will be updated within an hour or two.

This change in review times means it’s significantly easier to roll out experiments and to optimize user funnels. It takes the frustration out of waiting and allows you more peace of mind as a developer.

3. Android Studio Doesn’t Crash All the Time

Summary

I’m sitting here trying to think of additional positives when developing for Android but I really can’t think of many. Perhaps it’s because I’m so used to the iOS platform that I’ve become biased, but in my personal opinion, there are a lot more downsides when making the switch to Android than there are the other way around.

If these differences don’t detract you, definitely buckle up, get a book and start learning. I’ll go more in detail about the actual process of development in part 2.