What about the Android fragmentation problem? In the words of MG Siegler today:

"The problem is that all of these different devices require testing for each and every app. They all create a different Android experiences — some in subtle ways, some in big ways. Some run certain Android apps, others don’t. Some apps work fine on one device then are buggy as hell on another one. Sometimes this gets fixed, sometimes it doesn’t. It depends on the popularity of that device and the resources the development team has."

[source] http://parislemon.com/post/29497373610/im-not-sure-fred-wils...

If your whole goal is to use Android as the platform to build your MVP, you can probably live with limiting your app to, say, only ICS and up to begin with. This cuts down drastically on the fragmentation issues. Even though Gingerbread is still dominant, 1K "guinea pigs" is not an unreasonable goal on ICS.

Fragmentation is really variable depending on the kind of app being made. In terms of UI design, fragmentation is not much of an issue as there are a lot of techniques and libraries, official and unofficial, to allow UI patterns across 90%+ of devices.

The real issue for fragmentation comes from manufacturers and carriers changing the OS for their purposes in a way that breaks some API functionality in some or all cases. Apps that have to do tricky things with streaming data, multimedia playback, and hardware sensor interaction have this the worst, but just how bad it will be really depends on what you are doing. It should be noted that most devs will never have a major fragmentation problem and that the platform is improving with each major release to make these problems less apparent.

In case anyone is unaware, anything MG Siegler writes about Android should be taken with a grain of salt.

Particularly prescient nearly two years ago: http://news.ycombinator.com/item?id=1675574 (and parent discussion)

  > It's really unfortunate that a writer like him gets a voice in an influential 
  > blog like Techcrunch. I hope he just post things like these on his personal blog.

Edit: Android fragmentation affects different types of apps to different degrees; games have the toughest time from what I understand.

One of the big issues I see is mobile app distribution. In app store, you have this dynamic where the top ~25 are making tons, and then there's everyone else not making so much. I'm assuming it's the same dynamic on Android.

So how do you get your first 1,000? Do you spend money on some mobile incentivized downloads, or ads, or what?

I'd love to hear from someone who has built on both platforms extensively. My concern with this path is that the QA madness of the world of Android would slow you down as much (or more) than the app store madness of Apple?

The app store updates aren't really THAT big of a problem with Apple. I mean it isn't pleasant for sure. But you can use TestFlight or something while still in beta. I'm not sure that will scale to product/market fit but it will scale enough to give you good engagement metrics.

I've found testflight to be an absolute UX disaster for non-geeky users.

We've been using TestFlight to distribute new builds to multiple clients around the world, distributed to their user's iPads with a notification through mail, during their user acceptance testing phase and it just works great! None of our users complained about Test Flight's UI for sure!

We found it ok when a user only had one app they were testing on only one device. Once devices and apps multiply then good luck.

Do you know if compile-to-JVM languages can be used for Android (both technically and realistically)?

Yes, absolutely.

The main drawback is that all of them (at least the main ones - Scala, JRuby, Groovy, Clojure) all have their own runtime libraries, which bloats the size of the app considerably. I believe most people who go down this route use ProGuard to mitigate this problem.

Yes, but with certain downsides. The app is going to be larger than it would otherwise be. The development process is going to be far more difficult that it would otherwise be (configuring things, getting it to work, dealing with new versions of your tools). If you're writing a real-time game, it's probably not going to fly to do this, because in a game you need complete control over all memory allocation to avoid or control garbage collection. Something like Scala spins off a whole bunch of little objects non-stop in ways you can't control, in addition to using far more memory than a normal Java app.