Editor’s note: Dave Feldman is the co-founder of Emu. Previously he was Entrepreneur in Residence for CrunchFund, led the 2011 redesign of TechCrunch, and managed the design team for Yahoo! Messenger. Emu for iPhone is available now.

In late 2012, we decided to launch Emu on Android first. It went against the conventional wisdom at the time, but we saw a real advantage. Sixteen months later, we’re back on iOS: Emu for iPhone launched on April 2. Here’s why Android didn’t work out for us and why you should think carefully before going Android-first.

To build a messaging app on iPhone, you have to create your own communication channel — essentially an IM service. But on Android, you can simply replace the built-in Messages app, while still using the underlying SMS/MMS medium. You save yourself the effort of building a communication service. And, your users needn’t invite their friends: they’ll receive messages in the same place they always have. That lowers the barrier to trying your app, easing adoption. (This difference isn’t based on any technical limitation; it’s purely a choice by Apple and Google, one that either company could reverse in the future.)

But what of the conventional wisdom that Android users won’t download apps? We looked at the data and didn’t see it. Android users were less likely to pay for apps, to download games, and to pay for in-app content. But they were certainly downloading. Android had more users globally, and was on track to surpass the iOS installed base in the U.S. (It has since done so.) Android’s UX was improving, and a few high-profile influencers were switching to it from iPhone.

We heard other hopeful rumors: Android apps were easier to build. Adoption of recent Android versions was high enough that we could limit our backward compatibility, avoid serious fragmentation, and still have a large potential user base. And, while many Android apps were still clunky compared to their iPhone counterparts, companies like Flipboard and Press were starting to show that you could build a polished, delightful experience on Android.

So we jumped in. We discarded the iPhone prototype we had been working on for a few weeks, polished our rusty Java skills and had an Android alpha out by February 2013. We posted a public beta in July. And in October, we launched with terrific press coverage, including from a few folks who sang our praises specifically because we went Android-first. Android users are sick of watching new apps launch on iPhone, with Android as an often-underwhelming afterthought.

We launched Emu for iPhone on April 2, and we’ve pulled Emu for Android out of the Play Store. We hope we’ll return to Android someday, but our team is too small to innovate and iterate on multiple platforms simultaneously. We’ve concluded iPhone is a better place to be:

Our decision to build on top of SMS/MMS involved huge, unanticipated technical hurdles.

Even when you don’t support older Android versions, fragmentation is a huge drain on resources.

Google’s tools and documentation are less advanced, and less stable, than Apple’s.

Android’s larger install base doesn’t translate into a larger addressable market.

SMS & MMS Hurdles

Android attracted us because it provided access to SMS and MMS — the traditional, ubiqutious text messaging channels built into every phone. By developing on top of them, we thought we’d reduce the barrier to adoption. We were right — but didn’t anticipate the costs:

Android’s SMS APIs are not well-documented, and Google has changed them over time.

Prior to Android 4.4, individual apps can block each other from receiving SMSes; other apps on a given device will affect whether yours works properly.

MMS (group and picture messaging) is an old protocol, and implemented in different ways by different carriers. It also requires that we know a carrier’s specific MMS settings. We can read these automatically on older versions of Android, but after Android 4.1, we’re blocked from doing so. So, when we encounter a mobile carrier we haven’t seen before, we need to ask the user to go into Settings and send us the details. Since manufacturers and carriers often modify Android’s Settings app, we can’t always tell the user where (or whether) she might find them.

Fragmentation worsens the MMS problem. Carriers modify the OS to support their particular MMS idiosyncrasies. This results in bugs that are intermittent and difficult to pin down. The challenge isn’t simply fixing them; it’s that we have no way of knowing what they are, what’s causing them, or if they’re actually bugs in our app (vs. problems with the device or service).

All of this means significantly more time spent developing, debugging, and testing a portion of our product that doesn’t distinguish us from what the user already had. A stable SMS/MMS app, in itself, isn’t interesting.

Meanwhile, 2013’s explosion of messaging services suggested that we’d overvalued the low barrier to adoption: it seemed many people were happy to try new services, under the right conditions.

As long as we wanted to build on SMS and MMS, we had to be on Android. Abandoning them didn’t require we abandon Android, but it did allow us to reconsider iPhone.

Fragmentation

Android’s fragmentation is a contentious topic. When I blogged about it a few months back, I encountered both hostility and denial. So here are two examples from our experience:

On a Galaxy S4 with Samsung’s Multi-Window feature enabled, Emu’s popup windows are squished by the keyboard. This doesn’t happen on the Galaxy S4 sold by Google, without Samsung’s software modifications; or with the Multi-Window feature on the Galaxy S3. We’ve investigated, but because it relates to Samsung-specific functionality, we probably can’t fix it without direct cooperation from them.

On some Galaxy Nexus phones, when you’re listening to Pandora and get a notification sound from Emu, Pandora’s volume drops. This doesn’t happen with other apps’ notifications, nor does it happen with streaming apps other than Pandora, nor does it happen on any other device.

Our backward compatibility isn’t broad, by Android standards. Initially, we supported Android 4.0 (released fall 2011) and later. We’ve since dropped 4.0 support to try and reduce fragmentation further.

And yet, according to Google Analytics, our app has been installed on over 300 different devices since October. In some cases, those “devices” might be different variants of the same device, but bear in mind that, for instance, the Verizon Galaxy S4, the AT&T Galaxy S4, and the direct-from-Google Galaxy S4 are running at least somewhat different operating systems.

In contrast, our iPhone app supports only iOS 7 (released fall 2013). That means five devices–iPhone 4, 4S, 5, 5s, and 5c. Each runs the same operating system. It’s rare to encounter a bug that affects, say, an iPhone 5 but not a 5s. If the app works on one device it will usually work on all five.

The problem with fragmentation isn’t merely the quantity of bugs. It’s also the difficulty of finding them, and of understanding them well enough to fix them. We can’t test on every Android device we support, so we get bug reports in the field that we couldn’t anticipate and can’t reproduce. And, plenty of bugs go unreported and, therefore, unnoticed.

In, “Why Android First is a Myth,” Steve Cheney writes (emphasis mine):

All of my conversations over the past year…confirm a simple hard reality: building and releasing on Android costs 2-3x more than iOS. This is due to a multitude of reasons: less sophisticated tools, generally more cumbersome APIs, fewer exposed advanced features, enormous QA issues brought on by fragmentation, etc. The rough rule of thumb is for every iOS engineer you actually need two Android engineers—or twice the development time. This isn’t an issue of platform preference or capabilities; it’s a question of how we make the most of limited time, energy, and capital – especially in an early-stage startup, where significant iteration is inevitable.

Tools & Technologies

Steve Cheney’s post mentions, “less sophisticated tools” and “more cumbersome APIs.” That matched our experience as well. Eclipse is slow, over-featured, and hard on CPU and RAM. Google’s replacement, Android Studio (based on IntelliJ), is far better – but still suffers from all of those problems. Xcode isn’t perfect, but by and large it’s fast, clean, and straightforward. And Xcode 5 fixes most of the major issues I had with earlier versions.

Google’s APIs can be buggy compared with Apple’s. For instance:

We encountered performance issues with Android’s built-in JSON library. (Oddly, Google has two JSON libraries; the one that doesn’t ship with Android performed much better.)

Several text-layout and view-layout bugs created situations where a seemingly harmless visual change would create significant UI bugs.

If you want to add a drop-shadow to a view, you may need to rearrange its parent view first.

Until recently, putting a Google Map in a scrolling view created serious screen-redraw problems.

Google’s documentation is far easier to search than Apple’s, but can be confusing and inconsistent. Several times, I read through an article about how to implement something, only to discover a note at the bottom telling me it actually wasn’t possible. Sometimes there are conflicting docs for the same thing in different places. Sample apps don’t compile. And Stack Overflow, that miracle of community documentation for developers on any platform, often dries up when it comes to detailed UI/UX issues on Android.

Android apps also take much longer to compile than iOS, so you’ll find yourself waiting around a bit. And, while iOS developers often use the built-in simulator for quick testing, Android’s equivalent is slow, with a startup time measured in minutes.

The iOS world is far from perfect. Apple’s provisioning and certificate system is a nightmare, and its manual app-review system is painful and seemingly arbitrary, especially for quick fixes and experiments. I would love to see some of Android Studio’s code-completion and code-navigation features make their way into Xcode. Android’s XML-based approach to non-code resources — simple graphics, strings, dimensions, colors, etc. — does a nice job of separating design-related things from the rest of the code. But it’s not enough.

Target Audience

According to ComScore, Android has 52 percent of the U.S. smartphone install base, while iOS has 41 percent – a hefty number in either case, but Android is larger and growing. However, new versions of Android are adopted more slowly. That’s not because Android users are reluctant to upgrade; it’s an outgrowth of Android’s open-source nature, which allows carriers and device manufacturers to customize it.

When Samsung or HTC releases a new phone, they choose a recent version of Android, then modify it — sometimes slightly, sometimes significantly. When Google releases a newer Android, the manufacturer doesn’t necessarily re-modify it to support existing phones, presumably because there’s no incentive to do so. The result: it’s possible to buy a new, relatively high-end Android phone running an outdated version of Android.

Apple, on the other hand, only ships phones with its latest OS, and maintains several years’ backward compatibility.

In concrete terms:

By building for two years’ worth of Android (as we did originally with 4.0+), you’ll support about 40 percent of the U.S. smartphone install base. Removing 4.0-4.1 support leaves you with one year’s worth of OS compatibility, and that number drops to 12.5 percent.

By building for iOS 7 only, you’ll support 32 percent of the U.S. smartphone install base.

If nothing else, this suggests that size of install base alone shouldn’t be a factor in choosing a platform.

That doesn’t mean Emu will get more users on iPhone; it merely describes the total number of people who can install our app if they want to. We have more specific hypotheses about how switching platforms might affect our ability to reach target users, but they’re still hypotheses. We’ll write more once we see whether our iPhone launch confirms or refutes them.

In the year since we moved to Android, it’s become more popular to launch Android-first. And for some products it may very well be the right answer. But consider the trade-offs carefully. We’ll never know how things would have gone had we stuck with iPhone from the beginning. But here’s my guess: we would have launched our beta in April (not July) and our 1.0 in August (not October). We’d be building more functionality in less time. Our UX would be more polished, we’d have fewer bugs, and our addressable market would actually be larger.

Running a startup is all about learning. This has been a huge lesson for us, one I wish we’d learned faster…but perhaps our experience will help others to make a more informed decision. Android’s flexibility, and its greater strength in certain markets, still make it a far better platform for certain types of product. But it’s a difficult road, and best to travel with your eyes open.