
It's 2017 and I have a great mobile app idea. Start with Android or iOS? - beacham
It&#x27;s 2017 and I have a great (new) mobile app idea. I need to make a prototype quickly and would like to get to market quickly. Android and iOS make up 99% of the market share - 86% Android, 13% iOS. Is it a given that I have to support both right out of the box, or should I start with one or the other? Android has a higher market share, but are their other factors I should include in my decision like marketing effectiveness, entry to market, etc?
======
marcus_holmes
I'm going to be that guy. Sorry.

Are you sure it's a new idea? Have you really searched the 2million+ apps out
there to be sure? Truly new and original ideas are rare, most things you can
do on a mobile have been tried at some point in the last 10 years. Check
again, and learn from what others have done.

Have you validated the idea? I don't mean asked your mates if they like it. I
mean have you got someone to give you money as a pre-order?

Do you know exactly who your market is and how you'll reach them? Putting
something on the app store is not enough, it'll vanish without trace. You need
a marketing channel outside the app store that can get to your target market
and tell them about the app.

Have you tested that marketing channel? Personally I would do this _before_
writing any code. If the marketing channel doesn't work then you need to find
that out first and find one that does work. Don't worry about advertising
vapourware, if people really want your app they'll wait a bit (see Kickstarter
for evidence).

Unless, of course, this is a side project that is never intended to make
serious money. If so, then pick whatever technology and platform you want to
learn (I'd second React Native as a tech to learn). Market sizes don't matter
if you've got no customers and no channel.

~~~
beacham
First, thanks for your opinions and suggestions. That is all great advice.
Sorry I did not specify- I had planned on this just being a side project, but
I am excited about the possibilities just as any person should be. You're
right, I only did minimal research so it's very possible that this is not a
"new" idea in the most common sense of the word.

~~~
marcus_holmes
Lots of really good businesses start as side projects :)

If you're solving a problem that you have, then it's likely that other people
have the same problem.

What phone do you have? I'd develop for that first, so you're solving the
problem you have. Get it to the point where you're happy using it, and use it
every day (or every time the problem occurs). Only look at publishing it to
others once you've reached that point where it's really solving your problem
and you really do use it.

------
al2o3cr
The report summarized here (for Q2-2016):

[http://bgr.com/2016/07/20/ios-vs-android-developers-
profits-...](http://bgr.com/2016/07/20/ios-vs-android-developers-profits-app-
store-google-play/)

shows the Android store with twice as many downloads but half as much revenue.
The importance of this is going to vary depending on specifics about your
application - does it need a strong network effect to deliver value, or is it
valuable for a solo user?

~~~
wapz
I also agree with this idea. If you are going to be charging for your app and
want to make a revenue stream off the start before expanding, I think iOS is
the better choice. If it's going to be free and you are looking for a big user
base then Android will be a better start. The other factor is Android is quite
a bit easier for most to get into (but with fragmentation it is a pain to make
quality apps) -- Java and any OS compared to obj-c/swift and a Mac.

~~~
m_mueller
I have to disagree on Android being easier to get into. The standard libraries
and tooling (especially emulators and profilers) are dumpster fires compared
to Apple's offering. Just some examples: Non-Web Javascript integration is a
third party library. HTTP requests are a third party library. Everything that
needs native resources in the JVM goes through an interface called JNI that
has a _512 entries limit in the reference table, often requiring you to do
manual reference cleanup in your hot loops_.

~~~
wapz
I think it really depends on what the op is looking to make. I made the
generalization mostly based on the OS and languages (most universities
starting from at least 15 years ago taught Java in at least a few classes
whereas objective-c and swift are only iOS specific). I haven't had to deal
with your specific examples but I suppose in your case iOS might be easier. I
still believe overall Android is easier to get into for the "average" person.

~~~
m_mueller
IMO, for the average person, doing iOS with Swift will be easier, except, and
only for some simple usecases, if that person is already experienced with
Java.

------
GeneralMaximus
I build for the web so I'm obviously biased, but have you considered building
a web application?

If your app doesn't use device features that are not exposed to the browser,
building a progressive web app
([https://developers.google.com/web/progressive-web-
apps/](https://developers.google.com/web/progressive-web-apps/)) will save you
a lot of effort, help you get to market faster, and spend far less money on
user acquisition than a native app. On iOS, PWAs look and feel no different
from regular websites. On Android, you get access to native-like features,
including support for loading the app offline, push notifications, the ability
to install the app to the homescreen, a separate entry in the task switcher,
etc.

I wouldn't build something like Snapchat or Instagram as a webapp, simply
because building those experiences in the browser and getting them _just
right_ is still kinda hard. However, most applications aren't Snapchat or
Instagram, and a prototype certainly doesn't need that level of spit and
polish.

You might still choose to build a native app somewhere down the line, but
starting with a webapp gives you a chance to evaluate your idea and get
something working in the hands of your users very quickly.

------
shams93
How much do you want to spend to get started? It only costs a simple one time
$25 developer fee for android, for ios its $100/year. If you are just getting
your feet wet going android is much cheaper, then if you make money on android
you have a budget to get a mac with xcode, an ios device and the $100/year fee
to write for ios.

------
tom5
How about starting with a web site? It is much easy to iterate and validate
the idea. Once you get enough usage and feedback, then start to build app.

------
misha67
I'm in the same boat. Planning to go iOS first, since I'm an iOS developer and
don't know Android. Go with what you are most comfortable developing.

React Native might also be a good choice. I was pretty impressed with what it
could do on iOS, but I had challenges getting it to work on Android.

------
przeor
Use React Native which will help you to make for both platforms faster, here
is a good tutorial to start with: [https://reactjs.co/react-native-
convention/](https://reactjs.co/react-native-convention/)

------
pattrn
As a sole developer who recently released my first mobile app, I can't comment
on your specific use case or generalize about the market as a whole, since I
don't have significant experience. That said, I chose to use React Native and
release to both iOS and Android. After three months without doing any serious
spending on marketing, my iOS version had an order of magnitude higher
installs than my Android version. I suspect this may derive from differences
between Apple and Google's search ranking algorithms. It's a moot point for
me, since React Native supports both platforms, but the single data point may
help you.

------
webmaven
So, I don't have direct experience, but folks talk to me, so I have anectdata.
;-)

If your revenue model is app sales, go IOS.

If your revenue model is mobile advertising, you probably want to go Android.

Beyond that, it gets complicated, but I think the following are valid (though
your specific user segment might flip the other way on each of these):

Freemium models (ie. a free app that you can upgrade to a paid version) should
_probably_ go Android first.

Free with in-app purchases (eg. F2P games) should also probably go Android
first, but it is not as clear-cut.

If your revenue model is transactional (eg. flash sales), go iOS first.

No matter what, list your assumptions (that users _have the problem_ your app
will solve, that you know the language _they use_ to think about and describe
their problem, that they are actively _looking_ for a solution, that they will
be willing to _pay_ to solve their problem, that they will be interested in
_your_ solution, that they will be _willing to pay_ for your solution, any
assumptions about their price sensitivity, your assumptions about reaching
potential customers to make them aware of your solution, your effectiveness at
turning "lookers" into "buyers"), and aggressively validate and de-risk all
those assumptions.

Good luck!

------
jklein11
Why not hybrid mobile?

~~~
beacham
I've always been a believer that if writing a new, innovative application,
that using native code seems to be the most productive/efficient path. I do
know that there are tradeoffs in any decision like this. I also know and
accept that this is just an opinion.

~~~
jklein11
For the sake of discussion could you elaborate on why native code will be more
efficient/productive?

Is it the additional layer of abstraction? Or is it an issue of the uncanny
valley?

I understand that you may not want to discuss anything proprietary to your
app, but I'm interested in understanding your thought process.

~~~
beacham
Absolutely. Although, I'd like to say that most of the time people get into
discussions like these, it ends in an "agree to disagree" conclusion because,
in my opinion, the truth of the matter is it all comes down to tradeoffs and
opinions.

I need to keep this short due to wife so I probably won't be able to get my
full opinion across. From my experience, I believe that the additional layer
of abstraction provides a faster and easier development experience upfront,
but generally (not always) comes with an additional layer of bugs,
troubleshooting, updates, etc. I read an article on here the other day about
whether Xamarin was worth learning. I loved a comment that one user name eonil
left:

 _What you have to deal with;

Xcode = iOS bugs + UIKit bugs

Xamarin = iOS bugs + UIKit bugs + different runtime, language, memory model
abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs &
overheads + C# bugs + slow followup of platform updates

Xamarin Forms = iOS bugs + UIKit bugs + different runtime, language, memory
model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs
& overheads + C# bugs + slow followup of platform updates + extra UI
abstraction layers + lack of fine level controls & features_

[https://news.ycombinator.com/item?id=12948611](https://news.ycombinator.com/item?id=12948611)

While I know this is specific to Xamarin and is only an opinion, I tend to
think similarly about layers of abstraction over a language. Clearly there is
abstraction all over the place that I couldn’t go without, but maybe I’m not
just not yet ready to accept another one.

~~~
pawadu
I fully agree with what eonil wrote, but remember that environments like Unity
also come with a lot of tools and samples to simplify your development.

------
digitalmaster
react native

~~~
lucidrains
second this. mobile development is way too expensive for a single individual
like you

------
miguelrochefort
Doesn't matter if your idea sucks.

