4 ms·

Once you have a good app idea, flesh it out in at least 5 different implementations and send them all to the store. See which implementation takes off, and foc

Once you have a good app idea, flesh it out in at least 5 different implementations and send them all to the store. See which implementation takes off, and focus on that one and develop further. This is true both for games and utility apps. Use the A/B testing thinking and try several different "look and feels" for your app idea.

learnstats2 8y ago
Is this advice tried-and-tested? Because it sounds a lot of work. I would suggest that putting all of your energy into 1 implementation (at first) would probably work better.
- mseebach 8y ago
  Parent is basically describing A/B testing, so seems solid enough. It does seem to presume a fairly simple functionality, though, it probably won't work well if each version takes you five months to build.
  - Bartweiss 8y ago
    A/B testing should generally be done within an app, though. If your app already calls home to a server, you can collect usage stats and send feature flags for A/B testing. If it doesn't, you probably have to run your tests on in-person groups. The parent here proposes releasing multiple versions of an app and seeing which ones get downloads, which seems much harder and riskier - you end up splitting downloads across multiple apps, and then have to deprecate or maintain the ones that don't work out well.
  - learnstats2 8y ago
    Realistically, I suspect multiple new apps are unlikely to get enough users for there to be value in A/B testing.
- Bartweiss 8y ago
  For games, I seriously doubt this advice. Getting to 'hot' or 'featured new' or whatever the category is named is a huge source of no-ad-spend success, and it depends on getting a lot of new downloads shortly after release. A/B test before you release, sure, but don't release multiple versions and split those key early downloads. (Also, you're going to annoy all the users of any fork you deprecate, unless you maintain all 5 pages and move them to the same source. Also, will Apple even let you do this?)
smilangalang 8y ago
This is an incredibly crummy thing to do when the app stores are already overflowing, no, spewing with garbage apps and even more garbage apps abandoned by devs.

learnstats2 8y ago

Is this advice tried-and-tested? Because it sounds a lot of work. I would suggest that putting all of your energy into 1 implementation (at first) would probably work better.

mseebach 8y ago
Parent is basically describing A/B testing, so seems solid enough. It does seem to presume a fairly simple functionality, though, it probably won't work well if each version takes you five months to build.
- Bartweiss 8y ago
  A/B testing should generally be done within an app, though. If your app already calls home to a server, you can collect usage stats and send feature flags for A/B testing. If it doesn't, you probably have to run your tests on in-person groups. The parent here proposes releasing multiple versions of an app and seeing which ones get downloads, which seems much harder and riskier - you end up splitting downloads across multiple apps, and then have to deprecate or maintain the ones that don't work out well.
- learnstats2 8y ago
  Realistically, I suspect multiple new apps are unlikely to get enough users for there to be value in A/B testing.
Bartweiss 8y ago
For games, I seriously doubt this advice. Getting to 'hot' or 'featured new' or whatever the category is named is a huge source of no-ad-spend success, and it depends on getting a lot of new downloads shortly after release. A/B test before you release, sure, but don't release multiple versions and split those key early downloads. (Also, you're going to annoy all the users of any fork you deprecate, unless you maintain all 5 pages and move them to the same source. Also, will Apple even let you do this?)

smilangalang 8y ago

This is an incredibly crummy thing to do when the app stores are already overflowing, no, spewing with garbage apps and even more garbage apps abandoned by devs.