The answer has been simple for me: start on Android. The ability to push new fixes to live within a few minutes is a godsend. There is still the overhead of getting people to update the app after the download, but this can be easily remedied by in-app notification for a one-touch update experience.
I don't think it's too unreasonable to assume that if you hit product/market fit on Android, you probably hit it for iOS. Launch MVP on Android -> get first 1k guinea pigs -> pivot, iterate, pivot, iterate -> achieve product / market fit -> spend 3 months creating a beautiful iOS app.
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."
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.
> 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.
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!
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.
I don't think it's too unreasonable to assume that if you hit product/market fit on Android, you probably hit it for iOS. Launch MVP on Android -> get first 1k guinea pigs -> pivot, iterate, pivot, iterate -> achieve product / market fit -> spend 3 months creating a beautiful iOS app.