Promote an iOS app with a free initial release

January 30, 2013 by · Leave a Comment
Filed under: iOS 

My next iOS app GameTimer is getting closer to release and I’m thinking how to generate more interest for the app. One idea I’ve been considering is to do a free initial release. This blog post goes into some more details and pros and cons of this strategy. As I love to come up with new terms, maybe I should call it  “FIRST”, the Free Initial Release STrategy?

What do I mean by FIRST?

The idea behind “free initial release” is to promote an iOS app by making it available for free on the AppStore. This app is not intended to be free forever – monetization is through sales on the IOS AppStore. However, after releasing the app, it will be free for some time – maybe a few weeks, until switching to a paid app.


Here are a few of the Pros I see:

  • Limit the amount of (initial) development work
    The sooner you can release your software and get feedback, the less time and effort you waste developing features no one will use.
  • Get honest feedback from interested users
    For a relatively new iOS developer such as me (i.e. without a track record of good apps or a sizable number of influential followers), it is usually not easy to get feedback from users outside of the immediate friends and family category. A free app is going to be interesting to many more users – and you don’t even have to know them in order to “make” them test the app. One example of feedback is crash logs: You’ll have them, even after testing your app – so you should regularly check the iTunesConnect crash logs or include some crash reporting mechanism such as HockeyApp or Crashlytics. Even better is direct feedback to you as a developer, so make sure to include an easy way for user to leave feedback, such as sending an email or tweet directly from your app.
  • Generate (hopefully) positive reviews on the AppStore
    Users are a bit more generous with good reviews for a free app, and they are also less annoyed by being asked for a review. If your app has a few positive reviews (rather than the standard three or four 1-star-reviews) or even a good average rating, users will be much more likely to buy your app once you’ve switched to paid. In order to encourage ratings, your app should include some friendly way of “nagging” users for a rating and/or review.
  • Easier to create interest for your app
    Generally, you will be able to create more interest for a free app: Anyone remotely interested in the app will be able to give it a try. In order to hold these users’ interest, it is important to build a good first use experience. In fact, a good first use experience is probably much more important than having a long list of features that only a few users may need.


As usual, nothing comes for free and there are some disadvantages and risks using FIRST:

  • Miss sales to initial buyers
    With each new app, there seem to be a few users that buy that app (maybe just because it’s new). If the initial release is free, you miss out on these initial buyers.
  • After an embarrassing 1.0 version, nobody cares about a polished V1.5.
    I’m not exactly sure where this sentiment comes from (I read about it on the AppCubby blog). But it makes clear that even your version 1.0 has to be compelling enough to captivate the interest of your users. It also means that you can’t just push out an unfinished, crappy version of the app you want to sell – at the least the core of the app has to be “polished”. However, I see this as a bit of a reality check: If there is too much work involved, maybe your app idea is just not feasible.
  • Missing the right point to switch to paid
    If the idea of FIRST is to generate interest and then make money, there is the danger of missing the right time to switch. You want to do the switch when the interest for your app is sizable, but still increasing – a good point would be right before a link from a John Gruber or being featured on the AppStore. However if you miss that crest, you will again leave money on the table by not properly monetizing on the interest you’ve managed to generate. This means you have to actively monitor how interest is developing, and make sure to be able to change the price on a relatively short notice.
  • Interest in a free app is different to something people have to pay for
    One of the main points of “Lean Startup” is to build a “MVP” (Minimum Viable Product), but also to validate the concept by asking people to pay money for it. I think it was Jason Cohen who made it clear that people don’t like to say no and will give you all kinds of nice answers if you ask them if they like your idea. Asking for money cuts through that politeness layer. As the discussion around “freemium models” has show, generating interest into a free service does not guarantee financial success for a paid product. (However, I feel that this notion is helpful in “enterprise sales”, but doesn’t fully apply to the iOS AppStore – of course there is a difference between a free app and a 99¢ app, but you are still in “impulse buy” territory.)

It’s not a Beta Test

One thing should be clear: FIRST is not a beta test. First of all, Apple does not look to favorable on buggy apps that are submitted for release and has made it clear that the app has to be fully tested. As noted above, you want your users to have a great experience with your app (after all you want to generate interest in it), so you can’t afford to release a buggy or unpolished release. It is much better to cut features and deliver a “MVP”. When switching to paid, you should make sure to add some features in addition to removing some bugs that have occurred.

Switch to paid

The switch to a paid application can happen in a number of different ways:

  1. Just change the price (without submitting a new version)
    This is the quickest way to switch to a paid app (afaik it does not require approval from Apple). But with the changed guidelines concerning the app description (changes are only allowed with a new version), you shouldn’t refer to the app being free for a limited time in your description if you want to be able to use this option.
  2. Change the price while submitting a new version
    This is a more flexible option: You can refer to “free for a limited time” in your app description and you can also tout the new features when changing the price. (Your existing users probably won’t care.) However, a new version requires approval by Apple and takes at least a few days of review. In order to be able to react quickly, one idea is to submit a new version and hold it for developer release.
  3. Switch to “free + inApp purchase”
    Instead of making all users pay for your app, you can offer a free starter version and an inApp purchase to get to the new features. This option requires new coding to work properly with the inApp purchasing APIs. (I haven’t worked with that API yet, so I’m not sure how much effort that requires.) The other tricky question is what to do with your existing users. If the free version is very close to your existing version, it’s probably okay to keep them on the free tier, but if you are cutting functionality that would waste a lot of the goodwill you’ve generated.
  4. Switch to a completely new app
    This is probably the least desirable option: You have to leave all the “buzz” you’ve been able to generate behind. However, if the reaction to your 1.0 release was so bad that the app doesn’t really have a chance any more, this may be your only option if you still believe in your app idea. But you have to evaluate very honestly if your idea is still feasible – maybe it’s time to cut your losses.

Thoughts for GameTimer

I’ve put a lot of thought into what is the core idea of GameTimer, and I’m confident that I can deliver an MVP that is still engaging users. I’m pretty close to that for the iPhone version of my app, but have decided that having an iPad version would be a great bonus – so I’ll have to have a closer look whether to include that in my 1.0 release. My goal for GameTimer is to go beyond my current level of  “one sale per day”  – therefore I’m not too worried about missing a few initial sales but hope to generate more interest.

To sum up, I think that I’ll give “FIRST” a try when releasing GameTimer – but I’m very interested in your thoughts on this issue. You can leave a comment, send me an email or a tweet.

GameTimer – Getting closer to a “Beta Release”

January 24, 2013 by · Leave a Comment
Filed under: GameTimer, iOS 

As I’m not working on a project in January, I was able to spend some more time on GameTimer. To recap, GameTimer is a multi-person timer allowing you to measure how much time each player spends during a board game.


I’ve spent a lot of time designing the interface. A good part of it was to make it “look good” (and the associated exploration of Core Graphics), but also to make the interface easy to use and suited to the task of measuring time during a game without undue distraction. For example, the first workable version used portrait orientation, and there wasn’t a good way to make the buttons large enough – so I switched to landscape only.

Here’s a look at the current state of affairs:

GameTimer 13 01 24

Each player has his button (similar to people sitting around a table to play a game), displaying his name and the time he has used so far. The screenshot shows that there is some way of coloring the buttons with the color each players uses in the game. (The screenshot shows no color, wood, white and black, but I’ve also coded red, orange, green and blue and can easily add more colors if needed.)

The game can be started by tapping the ‘Start’ button:

GameTimer 13 01 24 active

A few things happen:

  • Player1’s button gets a green glow to indicate that it’s his turn. Also, his time display starts to advance.
  • There is a subtler glow for Player2’s button to indicate that he is the next player. (In the first screenshot this “next player glow” was shown for Player1 to indicate that the game would start with him.)
  • The ‘Start’ button turns into a ‘Stop’ button to suspend timing. (Then the active player becomes the next player and when tapping Start again, the game continues with him.)

There are two ways to advance to the next player: You can tap Player1 or the ‘Next’ button. Both actions make Player2 the active player and Player3 the next player. After Player2 finishes her move, you can either tap Player2 or the ‘Next’ button – the ‘Next’ button works for every player. (I’m also thinking about handling random order, but haven’t found the right interaction for it.)


Of course there are quite a few obvious limitations (and some not so obvious):

  • No way to reset the clocks (This is next on my list – the workaround “kill the app” is not exactly user friendly ;-). )
  • No countdown schemes (For now, the app just measure how much time is used, but I want to use different count down schemes. Also need way to indicate time is up.)
  • iPhone only (I want to develop a universal app. Actually, the iPad may be better suited to the use case: The iPad may be placed on the table along the game board, and each player has to press his own button when his move is done)
  • Can’t set the players’  names (The buttons should display the name of the associated player. I also need a way to choose a color for the player. There will have to be another view for this.)
  • Fixed number of players (Currently, there are four players, but the final product should work for two to four players, maybe up to six players on the iPad.)
There is a number of smaller issues that I also have to address (e.g. iPhone5 support, help screens, avoid lock-screen) before being able to release.


Nonetheless, I’d like to get some user feedback as soon as possible. If you are interested, you can play around with the current state of the app (just send me an email and I’ll make it available to you.) The route that I’ll probably take is to release a minimal version of the GameTimer through the AppStore as soon as possible. While the app is not completely polished, I could make it available for free, get the apps into the hands of potential users (more than in a “private” beta test), get some feedback and may also be able to generate a few positive reviews. Have you tried out this strategy or had success with other approaches? Please let me know in the comments!

Next iPhone app: GameTimer

January 16, 2013 by · Leave a Comment
Filed under: GameTimer, iOS 

Recently, I’ve started to work on my next iPhone app. The working title is “GameTimer”. It’s purpose is to keep track of how much time each player in a multi-person board game uses for his/her moves.

Game Timer: Usage Scenario

GameTimer is very much a “scratch-you-own-itch” app: My wife and I love to play board games with friends, especially strategy games that require some thought and do not purely rely on luck. (Some classics in this category are “The Settlers of Catan”, “PowerGrid”, “Carcassone”, or “Ticket to Ride”. In Germany, we also have a series called “Game of the Year” that makes it easy to identify new, exciting games.) One constant issue is that someone takes much more time than the others to make his move. (I’m saying “his” on purpose, as it’s mainly the men that get accused of this behavior.) 

Inspiration: Chess Clocks

When I was younger, I played a lot of chess. In competitive games, you always play with a chess clock such as this:


The following description is take from the wikipedia article on game clocks:

game clock consists of two adjacent clocks and buttons to stop one clock while starting the other, such that the two component clocks never run simultaneously. Game clocks are used in two-player games where the players move in turn. The purpose is to keep track of the total time each player takes for his or her own moves, and ensure that neither player overly delays the game.

Chess clocks also have a mechanical way of indicating when “time is up” (called a “flag”) which is raised by the minute hand and then falls to indicate the exact moment the player’s time has expired. Chess has also come up with different timing schemes, such as “blitz chess” (every player has 5 minutes for the full game) or tournament versions (40 moves in two hours, then 20 moves in one hour) and interesting time control variations.

Extending the idea

It would be relatively simple to code the app-equivalent of a chess clock (and in fact there are some apps of that kind in the app store), but the main disadvantage of a chess clock is that it can only be used for exactly two players, so it can’t be used for the usual strategy games, typically with four players.

So the idea of the GameTimer app is to provide a way of controlling the time in games with two and more players in the form of an iOS app. I’m in the very early stages of designing and implementing the game, but here is a first draft of what the user interface may look like:


Each player is represented by a button with his name, also showing how much time she has used already (or how much time she has left). Some adornments may show whose turn it is and who is next. By tapping the button, a player (or a designated “timekeeper”) can indicate that his move is finished and it’s the next players turn. I will play around a bit with the interface, maybe I’ll also provide a large “Next” button to switch to the next player. Together with my friends I also want to determine if using a single timekeeper works well, or if each player should finish his move on his own. (With a physical chess clock, each player “presses the clock” after making his move on the board.) Obviously there also has to be a way to set up player names, the time control to be used etc. 

So there are quite a few open questions to be answered before I can release a finished app, and I’m very much looking forward to work through them in the next weeks. If you want to keep informed about my progress, please have a look at the marketing page for GameTimer and subscribe to my mailing list. Of course, I also welcome any feedback on my idea!