Here are the download figures. Notice the 70 000+ peak on July 5th:

Then, came the ad bug, which as crazy as it may sound, was a pain to fix¹. As you can see on the chart, downloads plunged dramatically. Now that the bug is gone for good, downloads are picking up but they are in no way as large as they once were.

This is where you can help. We’d really like to achieve the One Million Mark by July 31st. All you need to do is download the game and play it. If you enjoy the game, tell your friends on Twitter to download it and so on².

Warships is a nice game and you’ll probably enjoy the two players mode. We are planning to improve the game over time and fast-app switching will be part of the 1.4 update that should be submitted to Apple next week.

So thanks all and be sure to let us know what you think of the game!

Product page: http://edovia.com/warships/

iTunes Link: http://bit.ly/9b0DaQ

¹ A longer, more detail post will be available in August to explain what happened and to tell you about the whole “Warships now free” experience.

² The game is free and ad-based. It does generate revenues but we’re far from getting rich (see ¹). Most revenues are reinvested in the game.

Product Page

App Store Link

While I enjoy the extra money this provides me with, I’m more concerned about learning about how advertisement campaigns are performing so that’s why I’m redirecting visitors to my website before sending them to the App Store.

When you apply for an iTunes LinkShare affiliate ID, you’re likely to get rejected at first, especially if your website is outside the US. If that happens to you, just contact LinkShare to let them know that you intend to use your affiliate ID for the US iTunes Store only and you should get approved.

Now that you have your affiliate ID and have created your products links, it’s time to put them to good use. I suggest that you create a link on your website (ex: http://edovia.com/appstoreredirect…) to which you pass needed parameters. In my case, I pass the appId and the u1 parameter you’ve read about in Shane’s posts.

Try that link on both your iPhone and your Mac and see how it behaves in both cases:

http://edovia.com/appstoreredirect/appId=6&u1=blog

This allows me to log the redirection and know where it comes from. It also allows me to control how to present the redirection to the user. I treat the iPhone traffic differently since I don’t want the user to have to go through yet another webpage before hitting the App Store.

When a redirect occurs from say a desktop, I present the potential user with a “Thank You” page, that replaces the default redirect page you normally get when Safari jumps to iTunes.app:

The redirection occurs in a 1×1 iframe. I got this method from a Karelia’s blog post. I highly recommend subscribing to their feed about indie marketing. Really useful information!

Mobile Safari won’t handle the iframe tag so this method won’t work on an Apple mobile device. That’s why we have to check the user agent and make sure our redirection will open App Store.app directly.

So I’ve added some PHP detection code to my redirect page to handle this:

<?php
	// Log redirect into database
	...
	...

	$serverAnswer = $_SERVER['HTTP_USER_AGENT'];

	// Fetched LinkShare link associated with product and u1 parameter
	$url = $product_item["appstore_link"].$dResponse["linkshare"]; 

	if (ereg("Mobile", $serverAnswer)) {
		// Simply redirect to the App Store through LinkShare.
		// This will gracefully launch App Store.app
		header('Location: '.$url);
	}
	else {
		// Present the redirect "Thank you" page that
		// contains that iframe I've told you about.
		$dResponse['views']['header'] =
			array('url'=>'./app/pages/header_front.php');
		$dResponse['views']['content'] =
			array('url'=>'./app/pages/appstoreredirect.php');
		$dResponse['views']['footer'] =
			array('url'=>'./app/pages/footer.php');
	}
	exit;
?>

That’s it! I’m sure I’ve probably missed a few conversions along the way and that my method could probably better but I don’t really care that much for conversions anyway, as long as I can see trends and confirm that advertisement campaigns are successful. I also like the idea that I can control the redirection and change it along the way if necessary.

While I was wondering how I could help, Justin Williams at Second Gear Software tweeted about bringing Mac/iPhone together to gather funds for Haiti: Indie+Relief.

More than 150 indie developers participated and while at this time no official numbers were given, it seems that the operation has been a success!

Update: Indie+Relief raises $143,872 for Haiti.

We offered to give away 100% of the total price for Warships and Currencies. That meant that we’d also give the 30% share that Apple keeps from every sale. However, sales we a little disappointing: both apps sold for a total of $144 so we boosted the amount to $400! We decided to give this sum to CECI, a local Montreal organization.

I feel that we’re very fortunate to live where we do and that more than often we take our comfort for granted. I also decided to give more because my brother, who is an helicopter pilot in the Canadian Army, will be sent to Haiti in the next couple of days to help. He’ll be there for 2 months. Giving a little more was the least I could do.

If you haven’t bought any of the apps yesterday, you can still donate to your organization of choice. Here’s a few:

CECI
American Red Cross
Doctors Without Borders

In our view, reality is that there are a lot of good reasons to take the in-app route:

• Settings.app becomes a total mess with more and more apps and takes long to load all apps
• Most users simply don’t understand the mechanism and miss the settings if they are only placed in Settings.app
• A context switch is needed to switch between settings and the app. If the app happens to be on the 16th screen, this involves quite some tapping and flicking.
• In-App settings can instantly change the behavior of the app

On the other hand, some (albeit a minority, we feel) users are used to the mechanism of Settings.app. Also, being part of Settings.app gains some user exposure and apps included there are viewed as first-class citizens by many advanced users.

So how can this dilemma be solved?

Many apps decide to get rid of a Settings.app pane altogether. Interestingly, all user-installable apps from Apple are amongst them (Remote, Keynote Remote, MobileMe iDisk). Further examples are Twitterrific, AIM and countless others.

We’re proposing a second approach that we call “hybrid settings”. In this model, the user has the choice: the settings are available in Settings.app. But they’re placed in-app as well. That way, every user can decide where to edit the settings. The in-app settings are a 100% clone of the Settings.app style.

How does it look like?

Well, the settings look exactly the same as in Settings.app. This consistency does make sense if we don’t want to confuse our users. In TouchPad, a “Settings” button shifts in the settings dialog. In Where To?, the settings are entered by tapping on the i-icon on the top right of the first screen. The settings then appear with a nice flip animation known from Weather.app or Stocks.app.

Can I integrate this in my app?

At first, the solution was developed by Luc Vandal of Edovia and Ortwin Gentz of FutureTap because we both had the need. So we wrote this piece of software as a Canadian-German co-production. Then, we thought twice and felt the code might be useful for some other folks. So we decided to release “InAppSettingsKit” as open source. Check out InAppSettingsKit.com for more details. This site also lists all apps currently using the framework and we hope it will be adopted widely.

Dan Wood, one of the guys behind Sandvox, just launched a new blog dedicated to issues surrounding marketing as an indie Mac developer. Mac Indie Marketing kicks off with a nice post listing 11 free eBooks that pertain to the subject. Can’t beat the price, here’s to a long and healthy life for Dan’s new blog.

Tons of useful resources. Every indie dev should take a look at this. More than often, we tend to overlook the importance of our website to concentrate more on development. Big mistake.

At least, now I know that our website is totally broken! I’ll dedicate some time to improve Edovia’s website in the coming weeks and will let you know about the results.

Many thanks to Daniel Jalkut for letting us know about this.