It's 2017 and I have a great mobile app idea. Start with Android or iOS? | Hacker News Reader

It's 2017 and I have a great mobile app idea. Start with Android or iOS?

19 pointsbeacham27 comments

It'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?

View on HN

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.

It doesn't have to be an old idea...i.e loads of apps already doing it out there.

It just needs to be better than what's out there :)

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.

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.

The report summarized here (for Q2-2016):

http://bgr.com/2016/07/20/ios-vs-android-developers-profits-...

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?

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.

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.

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.

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.

Note that this data is by no means undisputed. It does not come from Apple and Google but from various analytics services with unclear coverage:

1. Do these numbers include ad revenue?

2. Do these numbers include music, magazine and movie sales?

3. Do the Android number include Amazon and the Chinese stores?

4. Do the Apple numbers include desktop apps?

5. Do the Google numbers include chrome extensions?

6. Do Google numbers include third party services such as spotify and netflix? (from the article, the Apple numbers seem to do that)

7. Do Google numbers include hardware sales (via the Play store)?

With that said, both stores are showing extreme growth so neither is a dead end and you will be happy which ever you choose:

http://www.gsmarena.com/google_play_app_revenue_up_82_in_q4_...

Thank you so much. This is EXACTLY the kind of information and suggestion that I had hoped to receive.

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/) 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.

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.

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.

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.

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/

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.

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!

Why not hybrid mobile?

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.

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.

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

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.

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.

It honestly depends on how complicated your app will be, and how talented you already are as a developer.

But in truth, you should probably be looking at making your Minimal Viable Product in whatever you are the most comfortable in. Because you'll want to get it out and in potential customers hands as fast as possible and prove that your idea really is as useful to people as you believe.

I'm also going to take a stab here and say that you're probably not a super experienced developer, because trying to launch and support an app across two different platforms in different languages almost simultaneously isn't an easy feat to manage.

react native

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

Doesn't matter if your idea sucks.

Reply on news.ycombinator.com