October 31, 2019

Do I Need an Android Version?

Ben Noland @bennoland

So I built my first iPhone app this year. It's a social body weight tracker.

My thinking was, I'll build the IOS version. If it's successful then I'll build an Android version as well.

But it seem like even Apple users are hesitant to join because a good portion of their friends can't use it. The social piece is what makes my app unique, there's plenty of quality solo body weight trackers already in the app store.

I'm at a crossroads. Do I:

  1. Keep going
  2. Take a few months to build an Android version
  3. Stop, start over, build a simpler app that isn't social
  1. 3

    I would wait to reach product-market fit before developing the Android version. Having only an iOS version will hurt your growth but at your stage, it doesn't matter. You want to know you are building the right thing.

    A decent portion of iOS users will have enough friends with iPhones and will be able to use the social features. You can focus on these first users in order to validate your concept.

    1. 2

      I have tried to do this. I have 118 users on the app, and I like the amount of engagement I'm seeing for the users I have, but acquiring new users is tough.

      I haven't really identified my market yet. I've been trying to stay very general purpose, but I think it's time to niche down. There are lots of body weight trackers, and people aren't really searching for "social body weight tracker". But they are looking for ways to facilitate group challenges, so that's what I want to focus on.

      If 50% of the group can't participate, that's an absolute show stopper. They will just use google sheets.

      1. 2

        That's right, people don't search for "social body weight tracker" to find AdiPosse and people don't search "social competitive saving" for cashcoach.io

        When you create a segment that the market doesn't know yet, you have no competition, but people don't know it exists.

        People will often give you the easiest reason why they don't use your product. "Oh I have one friend on Android and he cannot use it". If you have a strong product-market fit, people will tell you "oh great I can already invite 3 friends but I have other 3 friends on Android and would like to invite them".

  2. 3

    What evidence do you have that the lack of their Android friends are causing iOS users to not join? I've seen a lot of product teams and founders make assumptions like this that aren't validated, so just curious how you arrived at that perspective.

    1. 2

      I've DMed with trainers on instagram who said they couldn't use it because some of their clients use Android.

      Other than that, it's logical. I'd like to support doing office challenges, or weight loss challenges at gyms. If the app only works for half of the population that's a show stopper and they will use google sheets instead.

      1. 2

        It sounds like your leap of faith assumption rests on the social nature of your app. I feel like many of the features you'd need to test that hypothesis can be done through a web-wrapped app (such as what @SteveTaylorWitte recommended using a service like OneSignal for notifications) to make sure the social bits are going to get you the results you are looking for across all platforms.

        If the social bit doesn't capture users, does it matter if the scale integration and Apple Health integration functions?

        1. 2

          Yes, I've spent a lot of time on stuff that is not related to the social nature of the app.

          You make an excellent point, the Android version would not need all of those features to test out my hypothesis. Given that my backend is working and would be easy to integrate with Android, I may be able to do an MVP in a much shorter time than I was originally thinking.

  3. 2

    You could use Cordova (https://cordova.apache.org/) to build an app using web technologies (HTML,CSS,JS) and wrap it into iOS and Android native apps.
    There are plugins to use native features through JavaScript plugins:

    1. 1

      Cordova and React native would be an option.

      I've never been a huge fan of these types of abstraction layers. The promise of write once, run in two places is nice, but the tradeoff of the additional dependencies and leaky abstractions really turns me off.

      Since I already have a mostly finished IOS version, I'd probably just do a native Android version if I go that route.

  4. 2

    Do the Android version! ...assuming you have some success now

    I had this same debate with myself about Happyfeed (journaling app) earlier in the year. And even though it isn't social, it was affecting my growth in a couple of key ways:

    1. Word-of-mouth is my primary growth channel, so I was losing some % of referrals to Android users
    2. Some schools were posting about my app, and just being on iOS was a dealbreaker. They would often recommend a worse app just because it was on both platforms.

    The Android app didn't 10x, 4x, or even 2x my growth, but it's made a significant difference. Probably closer to 25% growth.

    Now that I have both apps, it's a LOT more work, and I think Android users are a little pickier (from my limited interactions). I'd just make sure that your app has good numbers overall on iOS first - retention, user LTV, etc. It could be a waste of effort otherwise.

    1. 2

      Thank you for the encouragement. I'm leaning in this direction.

      I'm not too concerned about the learning curve (I love learning, and already know Java). My main concern has been being slowed down by the need to develop and maintain each feature in two codebases. I'd be curious to hear more about your experience in that regard.

      If I develop a new feature on IOS, figuring out the general layout of the screens and get the database pieces in place, it seems like porting that UI over to Android shouldn't take too long. I don't feel like it will 2X the workload, but maybe add ~20% once I'm proficient.

      Is it ok if the Android version lags behind the IOS version by a month or so? I'd put out the new feature on IOS, validate that it's working as intended, tweak it as needed, and then port it to Android once I'm happy with it.

      1. 2

        I built my Android app in React Native since I'm already proficient with React, but sort of wish I had tried Java since there are annoying limitations with RN. Found myself missing the control I have with Swift.

        I think it's totally fine if the 2 versions don't match up on features. I rarely get complaints since most Android users haven't tried the iOS app, and mine is probably a year to 9 months behind on features. Just be careful on how you market features and be sure to segment your emails and everything.

        Good luck! My experience is just one data point, but hope it helps.

  5. 2
    1. Drop the native versions and do everything through the web

    Not sure what native features you are utilizing, but this may be an option.

    1. 2

      The native experience is important. Some reasons are as follows:

      • notifications when your friends weigh in, or comment/react to your weigh in
      • notifications reminding you to weigh in
      • bluetooth scale integration
      • integration with apple health

      Thanks for thinking outside the box though ;)

      1. 2

        React native could also be an option? You can probably still keep a fair bit of your swift code.