Why We’re Building ribl for Android First

Image for post
Image for post

This post was originally published on ribl.co.

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.

Conclusion

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 at ribl.co. Thanks for reading!

Written by

Dad and husband! Growing @meter_io and @utu_trust. #crypto, #startup, ex-marketer @capitals, power napper

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store