Doodlemate: 1 Year Report

Doodlemate is the first app I wrote for the iPhone and was released in July 2011. Now it’s over a year old it seemed like a good time to review how things went. Hopefully my experiences will help others working on, or thinking of starting, their own apps.

The Backstory

Doodlemate started life as a personal learning project. Back in 2011 I was just starting out with IOS and XCode and trying to figure out how everything fitted together. Learning, for me, is better with a solid goal to focus my efforts, so I decided to pick an app idea to develop.

After looking at various tutorials I figured a drawing app of some kind would give me a good grounding in both the standard model-view-controller architecture and in custom drawing. Pondering it a while longer, I also decided that a variation on the drawing app tutorial would be good: smaller images with limited palettes, harking back to the days of pixel art on BBC Micro Computers where I started learning programming. It also occurred to me that I could easily string a few images together and make animations, which would be a lot cooler than just drawing stuff.

I sketched up some basic requirements and got started. I think my outline was:

  • home screen with list of animations
  • preview screen
  • drawing screen with animation settings on the flip side (it was in one of the Apple tutorials and I wanted to use the flip effect :) )
  • palette management screen
  • colour selection screen

As a learning project went, it was ok. At the time there were only a few animation apps available (that I could find) and most didn’t let you do anything with what you created. I figured animations stuck on the iPhone were ok, but if you could save them or send them to yourself then it would actually be useful. It was then I realised the animation app I was creating fitted the format for animated GIFs, and that there might actually be a market for my little pet project!

After that I shifted my thinking. Instead of developing a learning project to teach myself various concepts, I was developing an app for release to end users. I think I actually learned more about app development from that shift in thinking than from all the other programming problems I’ve encountered in the last couple of years.

First Year Stats

The numbers then. In the 12 months from July 2011 to June 2012, Doodlemate has sold a total of 468 copies around the world.

Personally I find this number amazing. That many people have bought my app and, over the year, it’s gathered enough ratings to get 5 stars on the app store!

The number of sales and ratings did seem pretty low to start with. It’s worth remembering that people are usually a lot more vocal about things they don’t like than things they do. I realised that for my app to have only positive reviews meant it was good enough that people don’t feel the urge to go rate it down. Not the most glowing endorsement, sure, but I must have done something right :)

Spikes in Sales

The sales saw several spikes over the year which are worth mentioning:

  • Release – can’t get any sales if you don’t release your app. Without any advertising or marketing my initial sales were fairly slow and probably consisted mostly of friends and family. Thanks everyone!
  • Update – A couple of months after release I finished the animated GIF saving features and made an update.
  • Christmas – Well, January really. Not sure why this might be but my guess is that everyone who got a shiny new iPhone, iTunes vouchers as presents or just had a lot of spare time flooded the app store over the holidays!
  • Getting a star rating – Getting enough ratings to get a 4.5 star rating on the app store (I think you need a minimum of 5 ratings) caused another jump in sales.
  • Getting a 5-star rating – Getting that last half star caused another jump in sales. Apparently there are people who only download apps with a 5 star rating.

Lessons Learned

There were a lot of lessons learned from developing Doodlemate, and only some of them involved the programming I originally set out to learn.

I Can Earn Money From Apps

Until Doodlemate was released, the idea of actually earning money from writing my own apps seemed like a pipe dream. While it hasn’t exactly made a fortune it has shown that it is possible for apps I write to actually sell.

App Development Takes Time

This goes without saying, but writing a decent app is going to take time. However long you think it might take, double it. That’s a good starting point, but you’re probably still short.

If you’re a first time developer (like me), then there are likely to be a lot of tasks you either don’t know about yet (so haven’t factored them in to your estimate) or that you are aware of but can’t accurately estimate.

Another consideration is whether you’re doing things in your spare time or if you can devote full days to it. Trying to develop apps around a full time job means spending all your spare time doing it. This can be ok for a while but is a hard pace to maintain for long. Life, people and events have a nasty habit of catching up with you so it’s worth factoring in a little ‘me’ time, no matter how disciplined and hermit like you think you can be.

In the end, it will all come down to your persistence in completing your app. Burning out through overwork or getting depressed and stopping after massive underestimation aren’t going to help things.

Get a Star Rating

It might seem obvious but you really must get a star rating on the app store, and ideally a 3 rating at minimum. Getting a star rating had a double effect for me: I got a spike in sales and it slowed the tail-off in purchases. I was getting higher sales figures for months after getting a star rating than I had on release.

Many people, myself including, ignore apps without star ratings, especially if they have a lot of competition in the store. I want to buy useful apps not test and rate new apps, so I leave it to other people. I assume that the crowd will have already tried apps and rated them if they’re any good.

You don’t have to resort to any underhand tactics here. Simply do a bit of advertising with whatever you have available (friends, family, social media, clubs, societies, school news, etc) and prompt people to rate it honestly if they like it.

Aim for a 5 Star Rating

Ok, this might be a hard one to achieve but it should be what you’re aiming for, as a developer making an app and so that you maximise your returns. Essentially this means constantly testing, reviewing and revising your app to improve it as your working on it.

There are books devoted to this sort of thing so I won’t go into it, but I will say that the more testing, reviewing and improving you do before release then then better your app will be. Just remember to be honest about your app to yourself and be willing to accept feedback from others, even when they trash your favourite features. I’ve also found the more people you get involved in testing the better. Remember: you don’t have to like or use all the ideas people come up with, that’s your call as the developer.

Release Updates

Making an update does two things:

  1. It improves your app. You should have either fixed something or added a new feature to warrant making a new release. The better you make your app the more likely people are to like and buy it.
  2. It puts you back in the new releases section of the app store. This gives you a little extra visibility and another shot at getting into the coveted featured slot.

The flip side of this is that unless you’ve been very thorough in the original development, there’s a good chance your app will need improving or bug fixing after release. Prepare and plan for this in advance, don’t simply hope that once it’s released it’s all finished and you can stop.

What’s Next?

Well, Doodlemate is on hold at the moment. I do have plans for a round of updates and improvements based on all the new technology that’s now available and what I’ve learned from writing my second app. The simplest (and at the same time hardest) change is to make it a universal app. I would love to see it running on an iPad as well as the iPhone, partly because I want to play with all the extra space you get on the iPad display and partly because it opens up a whole new market of people who might like to make animated gif’s again :)

So there you go: some sales figures from a first time app developer and some things to think about if you’re developing your own app. Hope it helps!

Progress and the 80/20 Rule

The last couple of weeks have been a bit of a blur with lots of work, lots going on and lots of distractions :)

Progress

The bad news is I haven’t got round to doing a new comic yet. I’m sorry, I know you’re all terribly disappointed, you’ll just have to wait a while longer.

The good news is progress on my IPhone game has been very good. The main game development is complete, the levels are all in place and I’ve even managed to rope some friends in for game testing over the weekend and got some very good feedback. That leads me nicely into this week. I’m going to be working on the feedback from the test session over the next few days, sorting out what needs to be done and hopefully getting some more bugs ticked off the list. I should also be meeting up with my graphics guy, Syd Emery, now that he’s back off holiday, to sort out what’s left to do in that department.

The 80/20 Rule

If you haven’t heard of it before the 80/20 rule was first observed by the Italian economist Vilfredo Pareto, who noted that 80% of income in Italy was received by 20% of the population. It’s official name is the Pareto principle I love it this rule because it’s  simple, elegant and applies to a diverse set of situations. Here’s a few other examples that it generally fits:

  • Saving and investing: 80% of the income will come from the last 20% of the saving period.
  • Sales: 80% of your income will come from 20% of your customers, and conversely 80% of your customers are responsible for only 20% of your sales.
  • Business: 20% of your customers will take up 80% of your time.
  • Projects: 80% of the work will be done in 20% of the time, while the final 20% of the work will take 80% of the time.

The principle is so consistent that it can be used to help make decisions. For example, a company trying to decide how to increase profits could, instead of increasing advertising to everyone, look at their current customers and focus on the 20% that bring the most income. Tim Ferriss in his book “The 4-hour Working Week” actually makes a good case for cutting the customers who caused the most problems rather than trying to please them, freeing up more time to work with the good customers that he really wanted.

In the list above, the last one is currently interesting for me as I approach the end of my game. The large strokes for getting the game up and running (the screen management, basic behaviour, basic gameplay and handling levels) were done relatively quickly. There was a huge amount of progress from having nothing to having a game hanging together and playable. Back then, the task list was full of many large and small tasks and seemed to stretch on into the distance as far as my (mental) eye could see.

Now, I’m approaching the end and the 20% consists of a few broad tasks: (more) testing, bug fixing, tidy up and release. That looks pretty nice. However the number of sub-tasks for achieving those looks as long as the original list. Not only that but for every task ticked off the list another one or two seem to get added. As more bugs, ideas and improvements come to light the last 20% of the project looks like it really is going to take 80% of the time.

Fortunately this isn’t a problem for me. I’m writing the game in my spare time and already have a day job to support me, so having delays is just a little annoying.

So why write about it? Well, having such a brilliant example of the 80/20 rule is always nice to see. Plus, it highlights the risk of not accounting for that last 20%. If I was working on a fixed price contract, I was relying on the income from release of a new game or managing the project as part of a team within a company then those delays would be a serious issue. Remembering and planning for the 80/20 rule could mean the difference between having a successful on-time project, having enough money for food and keeping your job or not!

Another use of the 80/20 rule is in evaluating what features to work on to improve game quality before release. Determining which 20% of the features will give the 80% improvements to the overall game quality, for example, or identifying which 80% of features can be done in 20% of the time, so that the other 20% can be left for a future update.  As a rule of thumb for deciding what can or should be done, it’s pretty handy :)