Finding the Loose Change

I’m thrilled to present a guest post by Ian Marsh, 1/2 of the independent studio (and wildly successful) NimbleBit. They’re the creators of iPhone hits such as Pocket Frogs, Scoops, and Sky Burger, and they recently announced they reached 20 million downloads on the App Store!

One of the most important steps on the way to becoming a profitable independent iOS developer is diversifying your revenue stream. Â While business lingo like that makes me throw up a little, all it really means is discovering all the ways you can earn money using the platform. Â New developers sometimes pigeonhole themselves into a single App Store strategy: “Sell as many copies at 99 cents as possible”. Â More savvy developers mix Â multiple strategies: “Paid apps”, “In-App Purchases”, and “Advertising”. Â I want to make sure all developers know about another additional option often overlooked: LinkShare.

LinkShare is a company which pairs publishers with retailers who pay said developers for driving clicks to their sites that result in sales. Â How does this apply to iOS developers? Â Luckily Apple (specifically iTunes) is one of the retailers which uses LinkShare. Â A good FAQ page for the iTunes affiliate program can be found here, but the basic gist of it that you earn a 5% commission on items bought on the App Store from your affiliate links. Â As an iOS developer you are probably already using links to your apps (and perhaps others) in lots of places, including “More Games” screens, twitter, newsletters, banner ads, or your web site. Â Replacing all these existing (and future) links to the App Store with your affiliate links is a great start. Â Retro Dreamer even wrote a nice quick guide to creating links that work seamlessly in iOS (there are some pros and cons to different link formats).

Now you might think the chances of someone actually buying an app you link to are relatively low, but that’s where things get interesting. Â If you read the fine print it turns out affiliates get paid 5% of any purchases made within a 72 hours after following your link. Â Lets say Joe clicks on a link to say, Pocket Frogs (our latest free game) which included your affiliate id, which even doesn’t result in a paid purchase even if the app is downloaded. Â But perhaps Joe ends up buying Angry Birds ($0.99) an hour later earning you $0.05, or Real Racing 2 ($4.99) that night earning you $0.25, or just maybe the Beatles Box Set ($149.00) the next morning earning you $7.45! Â The cool thing about the iTunes affiliate program is that it gives the affiliate 5% of any and all purchases made through iTunes within 72 hours including ring tones, songs, apps, in-app purchases, movies, tv shows, or rentals.

This of course means you can still earn revenue from linking to free apps, Â which can end up being a powerful thing. Â For example, in Pocket Frogs we run a promotion every week where we offer an in game item for downloading a certain free app (with a LinkShare link of course). Â This not only keeps players checking back, but lets us promote apps we like (like Flower Garden) or even our own. Â Like most other revenue sources LinkShare isn’t going to make you a whole lot of money if there aren’t that many people clicking your links, but it will certainly grow along with the number of users you have. Â While the majority of revenue generated from Pocket Frogs (which fluctuates between 150k and 200k daily active users) comes from the IAP included in the game, it also generates a healthy amount of revenue from LinkShare (in conjunction with some links inside other apps) as seen below.

The great thing about LinkShare is that it gives you a lot of freedom on how you use it. It doesn’t use up any bandwidth or take up CPU cycles, and it doesn’t require you to shoehorn 3rd party code into your app. It is as invisible or invasive as you want it to be. So whether you’re a new iOS developer just starting out or an experienced dev, you owe it to yourself to take a look at using LinkShare if you’re not using it already.

Flower Garden Featured For Valentine’s Day!

Two years ago, when I was working on the first release of Flower Garden, Valentine’s Day was my target ship date. Unfortunately (or fortunately depending on how you look at it), I missed it and rescheduled it for April. Last year I was eagerly awaiting the Valentine’s Day features hoping for a feature by Apple, but Flower Garden wasn’t one of the apps to be selected. It was disappointing but understandable given how many newer quality apps are out there.

Fast-forward another year, and this morning I woke up to a very pleasant and unexpected surprise: Flower Garden was featured on the App Store under Apps For Valentine’s Day!

Flower Garden is still going strong, but I wasn’t expecting that at all. Thank you, Apple! Not only that, but this feature also appears on the device App Store. Flower Garden was featured twice before by Apple, but never before on a spot that appeared on the device. So that’s a first for Flower Garden!

To make things more interesting, I had been planning on doing a bit of promotion around Valentine’s Day like last year. So a few days ago I released a new update, and included another in-app purchase for the most asked-for feature: More pots in another garden space.

Finally, to round things off, I planned on doing a similar promotion to what I did last year around Mother’s Day, and I set Flower Garden to be free from today until Valentine’s Day to encourage even more people to try it. To get the word out of the price drop, I got some promotion going from Pocket Frogs and a few other apps encouraging users try out the now free Flower Garden. I’m also hoping a few media outlets cover the sale to get the word out as much as possible.

As of this moment, Flower Garden is in the top 100 apps in the US and in the top 50 games, so the combination of everything seems to be working. We’ll see how things develop over this coming week. Until then, it’s going to be an exciting ride.

For the latest news on Flower Garden, join the Facebook page by clicking “Like”:

Sleep-Deprived Reflections On The 360iDev Game Jam

About 48 hours ago, I participated in the 360iDev Game Jam. I’m still recovering from the sleep deprivation and caffeine excesses, but here are some random thoughts about the game jam and why I highly recommend the experience to all developers.

This was my third 360iDev Game Jam, and it gets better all the time. It’s great to see that it has become a 360iDev tradition, and that the number of people participating is going up every time. The last couple of times we had one invited guest to participate remotely (and preside over everybody else in the big video screen), but this time we opened it up so anybody, anywhere in the world could join us and participate in the updates and discussions through the web site (big thanks for Mike Berg for all the excellent work on the web site!).

What’s The Point

Some people don’t understand what the point of the game jam is. Other people see the value in it, but disagree with what other people see. The point of a game jam is the same as a jamming music session: To create something while surrounded by other developers and feed off each other’s energy and enthusiasm.

In addition to the jamming aspect of it, different people have different goals, and they’re all just as good and valuable:

Trying a new game idea
Learning a new API or technique
Making a finished product
Starting something new
Being totally experimental
Stretching their comfort zone

There were even people using the game jam as a means to make progress in their own game or app they had already started. It’s a bit far from the original intent, but why not? It’s the jamming part that is the most important.

I was glad to see that most people decided to work the theme (“changing the world”) in the game somehow. I definitely find that having some constraints helps me focus and be more creative at the same time.

One of the most attractive aspects of a game jam for me is that it’s a very focused, but very short effort. Yes, it sounds epic: “A full night of pizza, coffee, and coding…” but it’s only 8-10 hours. That means the cost of “failure” is minimal. It’s about a work day. That’s it. So that means it’s possible to try new, risky, experimental things, and, most importantly, be OK if they don’t work out. You don’t learn by succeeding at everything.

Swapping Roles

The last two game jams, I experimented with different kinds of game designs (heavy use of multi touch and limited visibility). This time around I’m in the middle of a new project (Casey’s Contraptions), and Miguel and I did about 5-6 prototypes earlier this year, so I wasn’t itching to do another experimental gameplay prototype.

So instead, Miguel and I paired up again, but with a twist: He would do all the programming and I would do all the art. How’s that for crazy? Actually, he’s in a lot better shape because he’s a good programmer in addition to being a great artist. Me, on the other hand, I can barely find my way around in Photoshop to copy and paste images from Google Images, so this was definitely going to be way out of my comfort zone.

As you can expect, we didn’t make as much progress as we had hoped. On the other hand, I never had more fun or learned more new things at a game jam before! It helped a lot that I wasn’t just flailing around with Photoshop, but that Miguel was there giving me pointers and showing me what the right way of doing things was. I went from not knowing that there was such a thing as a path tool, to becoming relatively proficient with it over the course of the night. It was like drinking a potion of +5 to Photoshop skills.

Apart from learning a lot, I also developed an even deeper appreciation and admiration of game artists. I knew it wasn’t easy stuff and that you needed a lot of talent. What I wasn’t quite fully appreciating is how technically involved art creation is! It’s very different from traditional painting and drawing, and it’s very highly technical. In a way, it’s almost like 3D modeling in how it requires mastery of a very complex tool and you need to work on very small parts for a long time.

Here’s a screenshot of the game showing all the assets I created during the jam:

Lessons Learned

Some random, unsorted, lessons learned from this jam:

Come ready with an empty project you can start working on. The jam is not the time when you want to start stripping out old code. I learned that one in my first game jam, but didn’t come prepared with an iPad project (Hint: the iPhone -> iPad automatic conversion sucks–does anything automatic not suck?).
Everything takes longer than you think. If you think you’ll just finish the game by morning, it’s probably too big. Choose something smaller.
Learning stuff during the jam is great. Just adjust expectations about what you’ll create (we knew this going in, but still caught us by surprise).
Take a moment to interact with the people around you. We’re all in a hurry to make something awesome, but take some time to talk to other developers. It’s well worth it, and makes the long night more bearable (and energizes you more).
Pizza and coffee is a killer combination. I suspect I might never have to go to sleep if I keep the two in balance ;-b
When wifi sucks, it’s hard to take the time to post updates or read other people’s updates.
Hotel wifi always sucks.
The jam is not a popularity contest. Sure, it’s great to show it off the next day, but make sure you create what you want for yourself and not based on what will demo best the next day.

If you haven’t done a game jam, you should. I strongly suggest collaborating with at least one other person, and doing it live with a bunch of other developers. The energy is incredible and it will be an experience you’ll learn a lot from and will remember for a long time.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter. This will be my last post for iDevBlogADay for a while (need to give those people in the massive waiting list a chance!), but I’ll definitely continue posting regularly.

The Power Of In-App Purchases

I finally managed to get through the hotel wifi and upload the slides for this morning’s 360iDev talk: The Power Of In-App Purchases. Thanks everybody who attended for the great questions and feedback!

Session description

The common-sense approach to make money on the App Store used to be to do anything to get on the top charts. In-app purchases changed all of that. Good in-app purchases can make your app profitable without being anywhere on the charts, and are the best hope for the independent developer. Come to this session to learn why IAPs can be so effective and how to leverage them effectively: what makes a good IAP, how to increase your user involvement, how to present IAPs in an attractive way, what things attract users, and what things turn them away. We’ll go through lots of detailed real-world data from Flower Garden and other games with strong IAPs.

Presentation slides: [Slideshare] [pdf]

Chronicle Of A Failed Experiment

In the last year and a half, I’ve written about the different things that I’ve tried with Flower Garden and their effects on sales. From adding Facebook support, creating a free version, adding in-app purchases, or giving Flower Garden for free for a limited time. Some strategies worked and some didn’t.

Today I want to share my latest experiment, and how it was a total and complete failure: Adding the option to gift IAP items from within the game.

Promo Codes

Before I can talk about how I implemented the “Gift This” feature, we need to talk about promo codes. Since Flower Garden has so many in-app purchases, I figured it would be very handy to have the ability to give some of them away to people for any reason: They mistakenly downloaded the wrong thing, they bought it in the free version and want to upgrade to the full one, or they supposedly paid for one but they never got it. Whatever the reason, having my own promo codes for in-app purchases was one of the best decisions I could have made. I would highly recommend it if you have IAPs, especially consumables.

The implementation of promo codes was totally straightforward. I have two tables in the Google App Engine: One for active promo codes and one for redeemed ones. The active promo code includes the code itself, the IAP item it refers to, the amount, and whether it’s limited to one user or not (if it’s limited to one user, the code goes away as soon as it’s redeemed, otherwise, any amount of users can redeem it).

Here’s an example of a code I just added (yes, feel free to redeem it in the Flower Shop):

Whenever a promo code is redeemed, I enter that data in the other table. That way not only do I have a log of what codes where redeemed and when, but I can also check and prevent the same device from redeeming the same code multiple times.

Another important reason to keep a redeemed promo code table is that I want promo codes to be as valid as purchasing the IAP directly. That means that if you ever attempt to purchase an item, I check first to see if you’ve redeemed a promo code for it, and if so, you can re-download it for free. Same thing when you do a restore purchases (although I believe I haven’t gotten around to implementing that part yet 🙂

Here’s my plea to Apple: Please, please, please, give us an “iTunes Account ID” along with the IAP data. Right now the best we can do is associate a purchase with a device (which is not good enough), or have a whole registration system for users (which is a pain and more time consuming for users). They’re already doing this with a Game Center ID, so why not with an iTunes Account?

Gift This

Once the promo code system was in place and field tested for a couple of months, I finally implemented the Gift This functionality. In the Flower Shop, users have the option to buy an item for themselves, or for someone else.

The first time you use the Gift This feature it explains how it works: You purchase the item and then you send it to someone else through email.

Under the hood, it purchases the IAP, contacts the server to generate a new promo code for that item, and then creates an email with the promo code and even a custom URL. Whenever someone receives a gift email, they can just click on the custom link and they immediately receive the item (assuming they have Flower Garden installed, of course).

One interesting consequence is that to implement this, you need to create one new IAP item for every item you want to gift (especially if they’re not consumable). Otherwise, someone couldn’t gift an item they had already purchased, or they couldn’t gift it more than once. This can add quite a few extra IAPs in your list!

In the case of Flower Garden, I started with the easiest case, and I only implemented gifting for fertilizer purchases (because they’re consumable, so I don’t have to keep track of who receives them and restoring them).

Total Failure

I really had great hopes for the Gift This feature. I had already envisioned writing a blog post showing IAP revenue going up 20-30% because of that feature. Not quite! It was pretty much a complete flop. The only positive thing I can say about it is that it didn’t actually lower regular sales.

See for yourself. In a period of about a month and a half, all the fertilizer gifting in the free and paid versions of Flower Garden amounted to a whopping $191!

Definitely not worth the 3-4 days it took me to implement it (and the opportunity cost of not being able to add some other feature or IAP).

Compare it to fertilizer sales during that period of over $7,000:

(That’s the spike of the new feature plus the Pocket Frogs cross promotion if you were wondering about it).

I’d love to know how the Gift This feature on the App Store is working out for Apple. I’m sure it’s doing better than my attempt at it, but I’m going to bet it’s still a very small percentage compared to regular sales.

Here comes the important question: Why was it a failure? Do people don’t like to gift? Was it presented badly? Did most people not know it existed?

There’s no way to know for sure, but my current guess is that people don’t like to gift something they don’t already own. Psychologically, there are several too many steps involved: Oh, I want to gift something, look for it in the store, purchase it, and send the email. Not a very fulfilling experience.

On the other hand, gifting something you already own is much more appealing. You have it in front of you, you’re proud of it and it looks great. You tap on a button and send it to someone. That is a lot more satisfying. So in the future I’ll take that approach and allow people to gift things they already own, even if they had to previously pay for it in some way.

What do you think? Do you have a better theory? How could it have been improved?

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.