Why We’re Building ribl for Android First

Why We’re Building ribl for Android First

Developers are engaged in an endless debate about whether mobile apps should be built for iOS or Android first, with the majority leaning toward iOS as their initial platform of choice.

In mid-2013, venture capitalist Chris Dixon predicted that developers would start building for Android first by now, but that hasn’t happened yet.

While the majority believes that startups and large companies alike should build their mobile apps for the iPhone first, the decision really comes down to your specific situation.

We decided to build ribl for Android first, and here are some of the factors we thought about when making our decision.

Key factors we considered

Testing and iterating quickly

Testing and launching an app in the Google Play Store is quick and easy, and for startups, the ability to rapidly analyze and refine your apps is critical to developing a high-quality product.

Google has designed a simple and flexible alpha and beta testing process for Android developers. Instead of emailing an APK file to testers to install the app, you can use Google Groups or Google+ right from the Google Play Developer Console to deliver the APK file to get your app into the hands of a specific set of alpha and beta testers. Then you’re able to assess crash reports, identify bugs, and automatically update your app. Management of the tester population and app versions is much more streamlined, allowing us to be both more organized and agile during the testing process.

When we do go live, publishing the app to Google Play is extremely easy. After going through the launch checklist, all you have to do is hit the “Publish” button and your app will be on the Google Play Store within a couple of hours. There isn’t any human involvement in reviewing your app, thus the process is extremely fast and simple. After our app is live, Google’s staged rollouts functionality allows us to release new app versions to only a percentage of our users, so we can further improve our app before rolling it out to the entire user base.

On the other hand, Apple’s iOS app testing and launch processes aren’t quite as streamlined. While the company has made some big improvements in app testing by purchasing TestFlight, there are still hurdles to overcome – testers have to download a separate app to test your app, you may have to deal with iTunes Connect or provisioning profiles, and distributing your app to testers requires approval.

Here’s a good overview of the differences between Android and iOS testing processes.

Going live on the App Store may be even more daunting. After submission, your app sits in a queue before anyone acknowledges its existence. The app gets reviewed by a human and her or she approves your app if it’s good to go. It takes on average about eight days to get approved, but if there are any issues with the app, it will be rejected. You’ll then have to fix the bugs and resubmit the app for approval, which of course will delay your app launch.

The ability to learn and iterate rapidly is very important for startups. Google’s testing and launch process is much better than Apple’s and was a primary reason why we decided to build for Android first.

Minimizing context switching for our developers

We built our back-end technology in Java to power our location awareness, boost tracking, feed algorithm, and all the other features of ribl. Android apps are also built using Java, so there was minimal “context switching” for our developers, which allowed us to build our Android app much more quickly.

Context switching is the process of changing focus and attention from one task to another. Imagine that you’re concentrating on writing an informative, amazing blog post on why your company decided to develop your app on the Android platform first. Then someone texts you about dinner plans tonight. Then an email notification pops up, begging you to click and open the message. You become inundated with all of these notifications, and then it takes time to get back into the groove of writing. Imagine that happening multiple times a day, and it’s clear that you can possibly lose hours to context switching.

For programmers, context switching can involve being disturbed by messaging notifications, or simply switching from one programming language to another. Joel Spolsky highlights the cost of context switching for developers:

“The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code.”

For ribl’s developers, switching from the back-end programming language of Java to the front-end language of Objective-C or Swift for iOS would have incurred a time cost and slowed down the development process. The data structures, API calls, and other programming syntax are very different from language to language, so avoiding this context switching allowed us to build ribl much faster and release the app for testing sooner.

Timing of the launch of the Swift programming language

We started developing ribl right around November 2014, just after Apple launched their new iOS programming language, Swift. While our developers were proficient in Apple’s prior language, Objective-C, Swift was new to the world. Swift and Objective-C use similar infrastructure but the syntax is definitely different, so there would certainly be a learning curve.

We wanted to develop ribl using Swift but it would have caused two issues:

  1. Learning a new programming language would take time and slow down development.
  2. If we built our app with Swift, users with older versions of iOS would be left out.

We weren’t as worried about #2 than we were about #1. For the sake of speed and agility, we decided to move ahead with Android development first.

Other factors we considered but didn’t matter too much

Larger user population for Android

Android and iOS are nearly equal in U.S. market share, but Android dominates internationally, with over 84% of the world’s smartphones running Google’s operating system.

While Android’s market share is impressive, it will likely be a while before we internationalize and build ribl communities abroad. This is certainly an important statistic for the long term, but didn’t factor too much in our decision to build on Android first for the short term.

Android fragmentation

Due to Google’s open approach of allowing third-party hardware manufacturers like Samsung, Motorola, and many others to run the operating system on their phones, there are literally hundreds of different devices that run on Android. Additionally, there are a few different versions of Android running on these devices, further perpetuating the fragmentation problem (Apple only has about a dozen device-OS combinations). Thus, accounting for all of the different Android hardware-software permutations can be a daunting task for app developers.

Google has made great progress in dealing with the fragmentation problem by launching Google Play Services. Play Services is essentially a portfolio of back-end libraries that allow developers to access core Google-powered features and easily implement them into apps. Automatic platform updates are distributed through the Google Play Store, making it faster and easier for end users to receive app updates.

By moving these core Android features away from the operating system, which takes longer for older phones to update, into the more easily updatable Play Services, developers can ensure that their apps run smoothly across all devices.

While we certainly considered the fragmentation issue, having Google Play Services minimized our concerns about developing for Android first.

iOS users spend more on apps

Studies have shown that iPhone users spend four to five times more on apps and also lead in mobile commerce spend when compared to Android users. Whether this is because of demographics or the fact that Apple has millions of credit card numbers entered by consumers to purchase songs from iTunes, this is an alarming statistic, especially since there are so many more Android users in the world.

This didn’t matter much to us, though. Ribl will be a free app and will likely always be. And by the time we monetize with in-app purchases and advertising, we believe that the mobile spend of both platforms will converge a bit. Android may never totally catch up with iPhone in this regard, but the we believe the gap will certainly shrink.


We are certainly going to develop ribl for iOS; actually, we’ve started working on it already. But during our early days, when agility and the ability to iterate quickly is so important, we believed that Google’s testing processes, the minimization of context switching, and the timing of the launch of the Swift programming language made Android the right platform on which to build ribl first.

What do you think?

We’re still looking for beta testers for both Android and iOS, so if you haven’t already, please sign up below or email me at Thanks for reading!


  1. jpv

    Noted this from hacker news awhile back and it has served me well:
    pro tip: before you release anything Android, send it over to the Samsung App Store first. They will compatibility QA check your app on all Samsung devices for all countries for almost all carriers up to the last two years, for free. I know cuz that was exactly the work I did.

    1. Mike Chan

      Thanks for reading and great advice! We’ll be sure to check that out. Thanks again.

  2. Dave Feldman

    Our startup, Emu, began on Android but switched to iOS in early 2014 for a variety of reasons, many of which are described in a post I wrote at the time (

    It’s been over a year since we made that decision, which can be an eternity in mobile-development land, so it’s interesting to evaluate this post in light of both our experience and the time that’s passed:

    One thing that hasn’t changed: it’s a hell of a lot easier to get a build onto your device for testing, or into the Play Store, than the iOS equivalent. It’s not merely that Apple’s approval process is lengthy; it’s also that it’s unpredictable.

    Android’s alpha/beta process was appealing to us when it launched, but after running through the sign-up process (through both Google Groups and Google+), we were concerned it might be too complex for a non-technical user; too much opportunity to get lost, given many of these folks would be doing us a favor (and therefore not motivated). As I said, though, it had *just* launched, so I’d be interested to hear whether it’s been streamlined since then.

    (And even if it hasn’t, that’s not a checkmark in the iOS column. TestFlight was a boon to iOS developers, but could only do so much to mitigate the problem; I’m interested to hear whether its integration into Apple’s own systems represents an improvement. We ended up building a code into our app and just posting it in the Play Store, which worked pretty well—and is also an approach Apple may or may not let through.)

    I’d love to hear more about how much your developers benefited from this. My instinct is that a lot of the context-switching wouldn’t depend on language: it’s a different codebase built with different APIs and even different ways of thinking about fundamental concepts like memory management.

    This seems odd to me—there’s an old, supported way of doing things as well as a new, interesting way, and that served as a reason to do neither?

    Sounds like this wasn’t a huge factor for you; one thing we failed to look at when making our original decision was how the numbers mapped onto our particular product. As you say, Android and iOS are neck and neck in the US, but that shifts depending on who you’re going after. Different geographical reasons and demographics have different balances. And, because Android version adoption is so much slower than iOS, you get a smaller actual percentage of users if you’re not willing to invest in backward compatibility. (

    One other thing: we felt like we should have placed greater emphasis on what was prevalent in our own immediate communities (which of course will vary from team to team). Our friends, families, and professional networks were almost exclusively iPhone-based at the time, which meant some of our most powerful potential evangelists couldn’t use our product.

    This was perhaps the most critical reason we switched to iOS in early 2014 — though as an SMS app we were hit harder than many apps would be. I’m glad to hear Google Play Services has helped with the situation.

    That said, many of our fragmentation-related difficulties stemmed from OEM modifications to the OS. For instance, Samsung’s “Multi-Window” feature on the Galaxy S4 appeared to modify the top of the View hierarchy in such a way that it threw off all our dialog-sizing calculations. This strikes me as the sort of thing Google Play Services might not help with—can you comment?

    We also found that the developer tools, SDK, and documentation were harder to work with than the Apple equivalents. Again, time has passed — and for instance, I just fired up the latest Android emulator and was pleased to see that app launches are much faster than they used to be — but my sense is there’s still a gap in terms of ease of use, reliability, speed, and polish (for the tools) and comprehensiveness and consistency (for the docs).

    The opinions above are just that – opinions. They are, as already indicated, based on somewhat out-of-date information. And they are *not* in any way meant to represent Google, which is now my employer.

    1. Mike Chan

      Thanks for your insight, Dave! And thanks for the conversation on Quibb!

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>