Resist the urge to develop on iOS (first)
Most people won’t heed this advice, hell, we basically didn’t, but I’m an optimist, so I’ll give it anyways.
Smaller startups, those with limited bandwidth and money, that are creating a consumer mobile product should start on Android, every time.
Full disclosure is that I am not a developer, just a growth guy who works very closely with developers, so my opinion is coming from my experience as well as our dev team’s. Most companies will start with iOS. It’s sexy, it’s what most people talk about and it’s what they own. Granted, there are very good reason to start with iOS (the fact that most startups are iOS users is a big one, I’m an iOS user and would be at a loss with initial Android design), but the thrust of my opinion comes from one big reason: Iteration
As a lot of people know, startups thrive off speed and iteration. There is already a lot of quality writing about running lean, so I won’t bore you, lets just agree that lean is good.
It is VERY difficult to iterate with iOS. A lot of startups are still trying to perfect their product market fit and need to be able to make changes quickly as they optimize, other startups have their product but need to increase their conversions and want to be able to test on a rapid schedule. Developing for iOS limits your flexibility and speed, a tradeoff I don’t believe is worth it. Now when you’re still in development and are testing internally or bringing in a few testers, you can make changes just as quickly as Android, but the problems start to arise when you need fast, quality data.
First off, let’s say you want to get 30 beta testers to bang on your app so you can get some baseline stats. You could go on Taskrabbit and hire people to come in, but it’d probably be a lot easier to use a mailing list or some other means of finding people online. Now how do you distribute the dev version? Testflight is great, but have you ever tried to get the average user to get through the onboarding sequence? It’s a nightmare and a large time sink. Between guiding users through the multiple steps, sending out new builds and constant updates, it easily becomes a full time job. On Android? Post a link to an APK, done.
Ok, so you ground through the testing process, got some killer feedback (but spent some precious $ and time) and you’re ready to push to the app store. You did some decent launch marketing and you’re getting some installs and user data, but now you’ve found some areas that need improving. Lets say you want to improve a signup form but you have two different designs. The next step would be to split test them and see if you can optimize. Unfortunately with Apple’s approval process you need to re-submit the app and wait roughly 5 days for approval and can only have one update in the queue. This means that you will have to wait the time, test one form, then resubmit with the second form and wait longer. On Android? A few hours to push your new version. Sure you could get beta testers to go over the forms, but beta users are inherently tainted because their motivations are changed the second they know they are testers. You want the pure data that comes from real users.
There are a few services that offer A/B testing for native apps such as Pathmapp and Apptimize. These services are great and allow you to change content without having to resubmit the app. These can get pricey quick and may not be the best for a bootstrapped startup, also they require some extra work for simple tests.
If a company has the tools and ability to develop both, great, you can test on Android and then update to iOS. If your app functionally makes more sense on iOS then this isn’t the best idea. There are plenty of reasons not to start on Android. Look, I’m an avid Apple user and I prefer their products over Android and other operating systems. I’m just saying you should think about it.
So that’s where I stand. I may not be right, but from personal experience and in regards to iteration and mobility, we’ve been kicking ourselves for constraining our testing to Apple’s approval schedule. If we were to do it again we would start with Android and I think you should consider it too.