Acorn Heroes

We’re happy to announce that a new update to Acorn Money has just hit the App Store.  And to celebrate, we’re giving away copies of Acorn Money to the first five people to get in touch.  See below for details.

Along with a few minor bug fixes, the major update has been the addition of multiple accounts. Now you can not only track day to day spending, but also manage, say, a savings account as well.  I know it’s a big feature for me, because I typically have a working account and then several savings accounts – one for tax, one for holiday pay and another for general savings.

Working with multiple accounts is easy – just pick the account your interested in and enter your transactions. You can set up transfers between accounts, and they can be one-off or repeating occurrences.

The Summary screen has also had a big overhaul, it now contains more useful information to help follow trends in your spending.

To find out more, see our product page for Acorn Money, or else head on over to see it on the App Store.

Now, for the giveaways!  All you need to do is email us at money@acornheroes.com.  The first five people to get in touch will get a promo code for a free copy of Acorn Money.

A beginning is a very delicate time.

Know then that it is the year 2011.  The mobile space is ruled by the App Store.  In this time, the most precious substance in the Appverse is a successfully implemented game idea.  A successful App extends the Indie lifestyle.  A successful App expands possibilities and opens doors.

Ok, I think that’ll do, enough butchering of a great movie.

I have previously talked about my game-in-waiting Faerie.  Currently, Faerie is a simple game mechanic that has been prototyped and ‘just’ needs to be turned into a finished game.  Starting things has never been a problem for me.  But seeing them through to the end is a lot more difficult.  And so I have a plan.  A plan so cunning you could put a tail on it and call it a weasel.

The Plan

1. As of this post, Faerie officially enters production.  I can’t promise it will be a rapid process, but it is my plan to make demonstrable progress every week.
2. To add incentive for me to keep it up, I’ll write about the process as I go.  Posts will vary in nature, some technical, some design based, some will be about art style and some will be about marketing.  It is my intention to be as open and up front about the whole thing as possible.
3. If I fail to live up to my promises in 1) and 2) above, I fully expect to be harassed by you, my friends and readers, and to be called a lazy git.

As Sam Beckett would say, “Oh boy!”.  Here’s hoping this works.  If not, people seem to enjoy watching a train wreck so I hope it provides an interesting read either way

MVP

So there’s this new-fangled idea going around about “Lean Startups”.  But one of the key ideas for a lean startup is the idea of identifying your Minimum Viable Product.  In other words, what is the minimum product you can produce that is of sufficient worth that your customers will be willing to pay for it.  For someone with tight time constraints like me, identifying the MVP for Faerie makes a huge amount of sense.  It’s too easy to fall into the trap of trying to incorporate every great idea from every other game out there.  That way leads to madness, and stagnation.

So, what does my MVP look like?  Here’s the current idea:

• Game mechanics – a never-ending series of different coloured objects fall from the top of the screen.  The player creates chains of these objects as they fall.  Chains must either be all of the same colour, or all different colours.  Chains score points based on the rarity of the colours used and also the length of the chains formed.  If an unfinished chain reaches the bottom of the screen, it’s game over.  The player tries to last as long as possible, amounting as high a score as possible.  Ninjump and geoSpark are good examples of these kinds of games.
• Variety – to avoid things getting boring there will also be a number of ‘power ups’ that fall down.  Tapping one of these will, say, slow down time, or activate a points multiplier, or create an auto-chainer, or… It should also be possible to activate combo-like scoring by creating chains in quick succession.
• Audience – I want kids to be able to play the game and have fun, but I also want more serious gamers to find plenty to challenge them.
• Aesthetic – for various reasons, I’ve always seen the falling objects as being leaves falling in a magical woodland – chaining them together is a game played by Faeries (hence the name), and the result of scoring well is to bring life to the woodland in the background.  I’d love to pull off a sort of line drawing and water colour feel to the game.  See the image below by Linda Ravenscroft for an example of the kind of style / colours I’d like to work with.  I’m no artist, so this would indeed be a challenge!  How can I convey a similar feeling / impression with meager skills?

This image is from a great tutorial over at http://www.artgraphica.net

In terms of features, this is what I believe would make a worthy game, with everything non-essential removed (the plan is to add more in as updates, once Faerie has been successfully launched):

• Single ‘endless’ game mode
• Seamless in-game tutorial
• Players can choose one of three levels of difficulty to start on Easy (Kids), Medium (Normal Player) or Hard (Hardcore Master Gamer)
• Scaling level of difficulty as the game goes on
• Gradual introduction of more types of game object over time (as in Tilt to Live, geoSpark, Linkoidz etc)
• Satisfying visual and aural feedback – the player needs to enjoy the process of putting together chains – the game should make them feel like a Minor God of Leaf Chaining.
• Online leader boards, or in some form the ability to brag to your friends.
• Dynamic music that gets more frantic as time goes on.
• All standard iOS behaviour works as expected – save and resume, multitasking, player’s music plays in preference to game music and so on.

I think that’s it.  It doesn’t sound like much, but even given my minimalist goals, I still want the game itself to feel stylish, fun and well polished.

Here’s the thing…

This is the part where I’m going to hit you up for a favour.  What I’m hoping for by conducting this process in the open is to get feedback from everyone.  Is the game good?  Does it suck?  Have you thought of a cool power up?  Would this game work better with Space Marines than Faeries?  Should I use a swipe gesture instead of a double tap? Whatever your thoughts are, I’d love to hear them as we go.  I can’t promise everyone’s ideas will make it into the game – that way lies madness.  But what I hope to achieve by throwing this project open to the world at large is to take this rough idea of a game and reduce it to an elegant, streamlined and fun game.  The more opinions I can get, and the earlier I can get them, the better this game will be.

So, my first question to you is: does the MVP sound viable?  Is it enough, or does it need something more before I can justify asking $0.99 or $1.99 for it?  Even at this stage, is there something that could be cut back on?  And a second question: what of the game’s theme / aesthetic (faeries, woodland scenes, water colour rendering) – does it sound promising / appealing?

Wow, what a turbulent year!  It seems to have shot by so fast, in a maelstrom of activity.  I guess that having three young children, full time work and a full time side-line can have that effect .  Having a second App on the store makes the whole “business” side of what we’re doing feel more real, more legitimate.

This is a short post to look at what my plans and goals are for the next year:

• Push sales to the point where we get a payment from Apple every month.  It’s a small goal, but an important one psychologically.
• Release a free, ad supported, version of Acorn Money to help spread the word about this great little App Sam has put together.  Our plan is to release a fully featured version of Acorn Money – at least based on the version 1.0 feature set – free, but with ads and the occasional nag to upgrade.  No artificial limits that cripple the app.  Who wants a money tracking app that can only have 6 recurring payments?  It’s a common pattern for free apps, but one that makes it nearly impossible to make an informed decision about the value of an App.
• Make enough in sales to purchase a new MacBook and an iPad.  There’s a couple of projects ticking over in the back of our minds that make more sense on the iPad than iPhone, plus we like our toys .
• To release Faerie, in both paid and free with ads versions.
• To get back into regular blogging – being near the top of the iDevBlogADay waiting list should ensure this happens!
• To spend more time in the company of other iDevs.  The NZiDev conference was great.  I’d love to get to GDC or WWDC if it were feasible.  Something to aim for at least.
• To stop saying “No” and “I can’t” by default, and concentrate on “Why not?”.  In other words, to kick some arse.

So what are your plans? There’s a lot of potential in the coming year, as there is in every new year.

We wish you all a happy and fulfilling year to come!

 

The question comes in a moment, but first a little bit of background…

So, the hard work’s been done.  Acorn Money is on the App store.  As a utility app, we felt that a soft launch was a viable option – people are always going to need to track their spending.  Also, it coincided without the fact that neither Sam nor myself are well versed in the intricacies of marketing.  A soft launch gives us the chance to try different strategies and see what works, ramping up our efforts over time.

To give you an idea, Acorn Money’s launch was a success in many ways.  We briefly hit #1 in the Finance section of the NZ App Store, largely due to the friends and family effect.  However we also did reasonably well (for a no budget, no marketing release) in other stores – the US and Canada for example.  Things are dropping off now though, which is more or less what you’d expect.  We are noticing a great deal more ‘stickiness’ in the iPad charts – partly due to less competition, and partly due to smaller sales numbers.

New Zealand Rankings for iPhone

US Rankings for iPad

Aside from the numbers, feedback we’ve had from customers so far has all been positive.  People are finding the app does what we meant it to – provide an uncomplicated, effective way to track their money.  We’ve had very few bug / crash reports and these have been addressed in our 1.1 update which is due out soon – adding multiple account support which is something we’ve been asked for a lot.  Parth also gave us a great review on simple-reviews.com.

So.  We have a solid app, one that people enjoy using and find helpful.  The question is, what do we do now to push sales?  Obviously there’s all the usual options – contact review sites and spread the word in as many ways as possible.

But say you had a little money based on previous sales.  Not a lot, but enough to do something with.  Imagine a number with 3 digits in it.  Yeah it’s not much, but it’s what we have after feeding the mortgages and paying the children.

What would you spend it on?

The two best options we can see are marketing or a designer.

Both Sam and I are programmers.  We can dabble in design / art (the Acorn Money icon is mine, and the art for Goo! is Sam’s), but really we need some help from a designer – to unify colour choices, fine tune layout and so on.

Hiring a designer would allow us to elevate the look of the App hugely.  And in a marketplace as busy and crowded as the App store, first impressions count for a lot.

Alternately, we could put money into getting the word out there.  And here I’m thinking mainly of advertising options – Ad Words, Facebook ads etc.  This could raise our profile enough to bring in some sales.  It could also be pouring money down the toilet.  Paying for an ‘expedited’ review is not an option – I’ll stick to the O.A.T.S. system, thank you very much…

Of course, I could have pondered over this all day, all week or all year – or – I could ask the Twitterverse for an opinion:

Replies came in thick and fast.  In the end the votes were about 2-1 in favor of getting a designer to do a style pass over the App.  I think the iPhone sets such high standards in terms of design that customers expect the same level of polish in their Apps.

So, the short term plan for Acorn Money is to push it out there to review sites and try to find ways to get more eyeballs on it without spending money on advertising.  Perhaps we’ll try to get a video up on YouTube – another chance to learn some new skills!  And if we do spend money, it’ll be on a reasonably quick style pass from a designer – keeping the same basic theme, which works well, but fixing and improving all those tiny things that set great design apart from mediocre.

What do you think?  Have we made the right choice?  It’s a tough question, one which possibly has no right answer, but we’d love to hear your thoughts in the comments below…

Acorn Money, our new App, is now out in the App store (iTunes link).  It’s a Universal App, which means it works across the iPad, iPhone and iPod touch.  We’re already getting great feed back from people who have purchased it, and have plenty of plans for future updates.  Acorn Money is an App that’s designed to make it easy to keep track of your finances, and help to answer those awkward “Can I afford this?” questions.

Acorn Money grew out of a conversation with a good friend Chris.  He was using Excel to track his day to day finances and recurring payments.  Obviously this was a time consuming process, and not particularly portable.  But it was effective.  The key to improving your financial situation is to first be aware of every dollar, and where it goes.  Many financial Apps are very powerful, but they sacrifice ease of use.  We thought a better option was to make tracking money as simple as possible, without the need for a degree in accounting.

We’re very happy with the way Acorn Money has turned out, the graph view provides a really handy way to check ahead for unexpected spending, and entering transactions is as simple as we can make it.

If you’re already using Acorn Money, we’d love to hear what you think of it – good or bad – so that we can make it even better.  If you haven’t tried it yet, it’s on sale till Christmas at US$1.99 (or local equivalent) on the App Store.

I thought it was about time to wrap up this series of articles by showing a fully working example of a build.  I’ve been using Hudson both for my private work and in my day job for the last couple of months now.  In that time it has save me a lot of time and effort producing AdHoc builds (now a one click process), and also occasionally catches me when I fail to commit new files to SVN.  Setup is far simpler than any other CC tool I’ve used, so I’d encourage you to have a go!

The story so far…

For convenience, here’s an index for the whole series.

• Part One, Overview of what an automated build is, and why it’s so useful.
• Part Two, setting up a basic build.
• Part Three, automatically versioning and tagging your project.
• Part Four, this article.  An example of a complete, working build.

Running all the time

One thing you want to set up with your build is to have it running all the time in the background.  I found this very helpful article by Jérôme Renard that covers a useful technique.  Read the comments, they’re very handy too!  In an ideal world, Hudson would run happily under all user logins.  And in fact the comments in Jérôme’s article describe how this can be done.  Unfortunately, when it comes to iOS development, the code signing that is done on AdHoc and Distribution builds requires various certificates etc to be present in the user’s keychain.  Setting these up for all users is a pain that keeps on hurting, especially every time you need to update a profile – when you add a new device, for example.

My advice is to just set up Hudson to run under a single user account – either your own developer account, or a special ‘build machine’ account if you have a dedicated computer available.

Hudson-wide setup

Hudson has a number of settings that can be applied to most or all projects.  By following the links to Manage Hudson | Configure System, you can set things such as non-standard paths for source control, default email setup and so on.  In my case, it’s a place to set up email defaults and twitter settings:

You’ll note that I’ve had to set up a non-standard port for email, and that I’ve added my email address as the system admin – if anything funny happens, Hudson will let me know through this address.  While it’s possible to set these on a per project basis, doing it here once just makes sense.

One more thing.  When I was talking about setting up a build from scratch, I’d typically use the ‘Build a free-style software project’ option when setting up a new job.  Once you have a working build, the ‘Copy existing job’ option becomes very useful, and is a huge time saver.  Typically a new build can be up and running in the five minutes it takes to change a few path variables.

The build job itself

OK, so let’s look at the setup for the actual build.  First of all, version control:

There’s nothing particularly unusual here.  I nominate the folder to check out the code into (‘Acorn Money’).  This is not necessary, but feels a little tidier to me.  The main thing to note is that I don’t trust an update and build here – an automated build should always be completely clean.  While Hudson doesn’t offer this out of the box, it does have the ‘Revert’ option to ensure no modified files are included in the build.  If anyone knows of a way to force Hudson to wipe and fetch the project clean from version control each time, let me know, I’d love to know how to do it.

So, no build triggers here.  This is because I want to generate an AdHoc build on an ‘as required’ basis.  Hudson is running on my MacBook, so the last thing I want is scheduled builds kicking off while I’m working.  The ‘Poll SCM’ option is handy for Continuous Integration, while the ‘Build periodically’ option is useful for nightly builds when the machine is otherwise idle.

Right, let’s look at the guts of it now, the shell scripts that do the actual building.  I use several scripts, separated into logical chunks.  They could all be run in a single script, but I prefer the separation here – each script has a singular purpose.  First up, we increment our build number and tag the code in SVN (see part three of this series):

cd AcornMoney
agvtool -usesvn bump -all
agvtool -usesvn tag -baseurlfortag http://acornsvn.no-ip.org:808/acornheroes/svn/AcornMoney/tags
cd ..

Next, the easy part is actually building the code, using an AdHoc configuration:

 

cd AcornMoney
xcodebuild -project AcornMoney.xcodeproj -target AcornMoney -configuration AdHoc
cd ..

For setting up a Distribution or AdHoc configuration, I generally refer to this cheat sheet, which is great for helping me ensure I don’t miss anything.  Finally, the fun part.  Once a build is successful, wouldn’t it be nice to make it available to all your testers automatically?  With the help of DropBox.com, it’s relatively easy.  Here’s the script:

cd AcornMoney
mkdir Payload
cp -rp build/AdHoc-iphoneos/AcornMoney.app Payload/
zip -r AcornMoney.ipa iTunesArtwork Payload
rm -rf Payload

rm -rf ~/Desktop/Dropbox/Acorn\ Money\ Builds/Latest/*
cp AcornMoney.ipa ~/Desktop/Dropbox/Acorn\ Money\ Builds/Latest/
cp ~/Library/MobileDevice/Provisioning\ Profiles/AcornHeroesAdHoc.mobileprovision ~/Desktop/Dropbox/Acorn\ Money\ Builds/Latest/

if [ $BUILD_NUMBER -lt 10 ]
then
 TMP_BUILD_NAME=AcornMoney00$BUILD_NUMBER
elif [ $BUILD_NUMBER -lt 100 ]
then
 TMP_BUILD_NAME=AcornMoney0$BUILD_NUMBER
else
 TMP_BUILD_NAME=AcornMoney$BUILD_NUMBER
fi

mkdir ~/Desktop/Dropbox/Acorn\ Money\ Builds/$TMP_BUILD_NAME

cp AcornMoney.ipa ~/Desktop/Dropbox/Acorn\ Money\ Builds/$TMP_BUILD_NAME/
cp ~/Library/MobileDevice/Provisioning\ Profiles/AcornHeroesAdHoc.mobileprovision ~/Desktop/Dropbox/Acorn\ Money\ Builds/$TMP_BUILD_NAME/

It may look like there’s a lot going on here, but most of it is just copying files around.  First of all we create an .ipa file (just a zip file with a different extension) which contains our build plus an ‘iTunesArtwork’ png image – otherwise the App icon doesn’t show up in iTunes for an AdHoc build.  Next up, we remove any existing ‘Latest’ build folder in our Dropbox folder.  Then we create a numbered folder for this build (e.g. AcornMoney08) and copy AcornMoney.ipa into this folder and the latest folder.  We also copy the provisioning profile from ‘~/Library/MobileDevice/Provisioning Profiles’, as it will be needed by our testers.

From here, Dropbox takes care of syncing this folder with anyone who is sharing it.  Our testers get a notification and a new build delivered to their own PC!  The post-build actions are fairly uninteresting, all I have set currently is email notification on a failed build.  Even this is slightly overkill, as for an AdHoc build I’m normally sitting at the machine watching the build anyway.

That’s it, a fully working build.  With Hudson, it’s possible to set one of these up with just an hour or so tinkering around.  Once you have a working build as an example, making a new build can be just a few minutes work.  Give it a go and let me know how you get on!

Acorn Money update

For those of you interested in Acorn Money, our money tracking App, we’re still in review.  Sam made some significant improvements to the graph rendering code and we felt the best thing to do was to pull the submitted build and re-submit.  Unfortunately this sends us back to the end of the queue.  Still, we’re hopeful Acorn Money will be available in the next couple of weeks.

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

 

This post is appearing on iDevBlogADay as a guest article while Owen Goss of Streaming Colour spends some special time with his wife and new born son.  To Owen – we wish you all the best for you and your family, you’ve joined a special club as a parent, life will never be the same again!

For a while now we’ve been keeping one of our projects under wraps.  Not out of any particular need for secrecy, rather just a desire to wait until Project M was ready to go.  And now is that time.  Our second App, Acorn Money, has just been submitted to the App Store.

And no, before you ask, it’s not a game.  Acorn Money is an App designed to help you track where your money goes.  The idea came from a conversation with our good friend Chris, who is full of great ideas.  He said that there was no App out there that made tracking your money simple.  Most financial Apps try to be high powered packages that can be everything and do everything for all people.  Such Apps typically end up bloated, confusing and unhelpful to the typical user.

What was needed was an App that just let you record one off and repeating payments to allow a person to get control of their finances.  And so Acorn Money was born.

Our goal with Acorn Money was to build an App that was:

• Streamlined – it just did one thing, and did it well.
• Appealing – there are a lot of truly generic financial Apps out there, we wanted something a bit more fun and friendly.
• Efficient – entering a new payment should be simple and fast – you’ve got plenty of other things you’d rather be doing.

Sam, the other half of Acorn Heroes, has put in a huge amount of effort to get Acorn Money ready.  It’s a Universal App for iPhone, iPod touch and iPad.  We’re really happy with the result, and think we have something that will help fill a need many people have.  This isn’t an App for a business school graduate, it’s an App for anyone that wants to have a better understanding of their financial situation.



 

I won’t go in to too much detail here – that’ll come once the App is approved by Apple.  Here’s a few key features though:

• Enter, edit and delete one off or repeating payments with a minimum of fuss.
• Modify individual payments on a repeating schedule, or alter all future payments.
• Graph your balance over time, including projections into the future.  Don’t ever be caught out by those once a year payments like vehicle registration again!
• Backup your data to your computer.

Acorn Money should be ready for sale within the next couple of weeks, Apple willing.  Rest assured, we’ll let you know as soon as it’s ready!

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.

Almost two years ago, I found myself unexpectedly unemployed.  Overnight I found myself working as a freelancer – more by necessity than choice.  It’s scary.  The lack of a regular pay check takes a lot of getting used to.  Still, I seem to be surviving, the mortgage is covered and the kids generally get new shoes when they need them.  I’ve put down a few thoughts that may help someone entering out the freelance world.  I’d love to hear your thoughts / experiences in the comments below.

Finish Well

The thing that sticks in a client’s mind will not be how well you started a project, it will be how you finished it.  To ensure your chances of getting more work, try to ensure that a job always finishes well.  It’s a measure of your professionalism.  What does this mean?  Leave code in a tidy state and document design choices and non-obvious parts of the code base.  As a project comes to a close, make sure you’re concentrating on and testing a working, real piece of software, as the end user will be using it.  It’s all to easy to concentrate on small test cases and forget the larger picture of a cohesive, complete deliverable.  Do this and you risk delivering software that falls over on day one due to unexpected loads or similar “real world” problems that don’t show up in testing.

Also, when the project you’ve worked on needs maintenance or expansion down the track, who are they likely to come back to?  Repeat work is as good as it gets for a freelancer in terms of a regular ‘gig’.  When you come back to this code in 4 months, do you really want to spend time sorting out the mess you left?

Iterate, Iterate, Iterate

Working as a freelancer means you come in cold to projects.  It can take time to get a feel for a project’s requirements and the client’s needs.  The worst thing you can do is take a client’s design brief and come back 4 weeks later with a completed piece of software that’s nothing like what they wanted.  To ensure you’re on the same wave length, do everything you can to get something concrete in front of the client as soon as possible.  Identify the minimum feature set that will do something useful, mock up the user interface and ensure that you are headed in a direction that will keep everyone happy.  If you don’t show the client anything until delivery I will guarantee they will be disappointed, and you may lose out on future work.

By showing regular, demonstrable progress you can build up a trust with the client, everyone wins and there are no last minute surprises.

Learn to Estimate Accurately

Estimation is not a black art, it’s a skill you can acquire with practice.  As developers, we tend to have a habit of estimating optimistically.  We guess how long a task will take based on that first 90% of the code that we can bash out in a few hours.  But to finish a job to the client’s satisfaction will require handling the last 10% that’s full of corner cases, API bugs and unknown risks.

Get used to asking yourself “What could go wrong?” and “What are the risks here that will cost time later?” when estimating time for a task.  A client will be over the moon if you over deliver because your initial estimate was too conservative.

Embrace Challenges

Chances are you won’t get to work on your dream job as a freelancer – you’ll be working on someone else’s dream.  Don’t let this get you down, treat it as a challenge.  I would never choose to work on databases, embedded hardware programming, web services and yet I’ve done all this in the last year.  The work has been varied and interesting, and I’ve learnt a lot about a wide range of disciplines.

Learn to Say No Nicely

At times there may well just be too much work to take on.  You will have to say no to work.  How you do this may well affect your chances of future work.  Be polite and apologetic.  Sometimes the client may be able to reschedule a project to fit your time table.  I would have really struggled over the last two years without the goodwill of clients and friends.  The effort you put into these relationships will pay big dividends down the track.

Know What Your Time is Worth

This one’s fairly straight forward.  Know how much money a week you need to get by, and how much you need to be comfortable.  Budget assuming you’ll get the minimum amount each week, and save the rest for a dry patch when work is not available.  You won’t have a regular pay check, so you need to know where every single dollar is going.  I’ve started to think of the things I buy in terms of hours work – it definitely changes the value you place on luxuries.

These guidelines are based on my experiences spending the last two years or so as a freelancer, as well as my career before that “working for the man”.  Is this useful or do you disagree?  Let me know in the comments below.

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.

In my previous articles, we’ve looked at how we can set up an automatic build, with a focus on catching issues with bad check-ins immediately.  Another useful aspect of an automated build is that it can remove the chance of human error whenever we have a task that consists of a lot of manual steps.

One such example is generating a build for ad-hoc distribution to beta testers.  We could create a build by hand, but if we forget to increment the version number in our project, then our testers won’t be able to update from a previous build unless they delete the old build by hand off their devices and iTunes – definitely a pain for people you don’t want to inconvenience.

 

Also, imagine the scenario in a couple of weeks when a tester notifies you of a serious bug they’ve found.  Chances are the code you have now is quite different to the build they have.  Can you get back to that point in the code easily?

Fortunately Apple provide us with a handy tool called agvtool that can handle these situations for us.  It’s a command line tool, so it integrates nicely into Hudson.  But first let’s look at agvtool on its own, and see what we can do with it.

agvtool

In order for agvtool to do its magic, we have a few things to set up in our project first.  Most of the steps here are described in detail by Jamie Montgomerie on his blog.  Briefly though, we will use two different version numbers – a release version and a build number.  The release version is our “marketing” number – what our clients see (“Now updated to version 1.2!”).  Our build number is for internal use, and will connect a given instance of our App to a specific tagged version of our code in source control. To test this, I created a simple OpenGL project in Xcode and added it to SVN as a starting point.  The only modification I’ve made to it is to add a label on top of the GL view.  We will use this later to display our build number for testers.  Note that SVN is not necessary for using agvtool, but it will give us a few nice options down the track.

 

So, following Jamie’s instructions, we:

1. Open our project’s PROJECT_NAME-Info.plist file and set the Bundle version to 1.  This represents our build number.
2. Ctrl (or right) click on the plist and choose Add Row.  From the options presented, select Bundle versions string, short and set its initial value to (say) 0.1.  This is our release version.
3. Ctrl (or right) click on the project in the Groups & Files window, and select Get Info.  Make sure you’ve selected All Configurations and find the Versioning section, near the bottom.  Set the Current Project Version to match you build number – 1 in our case.  Set the Versioning system to apple-generic.

OK, not too painful and we’ll never need to touch these bits again!  Let’s test our a few things.  Open up a terminal window and cd to your project directory.  We can use agvtool to tell us both the current build and release version numbers (agvtool calls them version and marketing version respectively):

 

You should see the build number (agvtool what-version) and release version (agvtool what-marketing-version) that you entered into the project settings.  Now, using agvtool we can also update our build and release version numbers.  Note that doing this modifies your project, so ensure it’s either not open in XCode or everything has been saved – otherwise you may lose changes to your project such as settings or newly added files. So, to increment our build number we use:

agvtool bump -all

On the slightly rarer occasion that we want to adjust our release version, this can be done as follows:

agvtool new-marketing-version 0.21b

 

You can use the agvtool what- command to verify what’s going on here.  Note that our build number is automatically incremented by one using the bump command.  Our release version is in fact a string, and we can supply whatever we want there, in this case 0.21b.

Assuming you’re paranoid like me, now is a good time to check this into source control as we have all the basics covered.

Open the project in XCode and build it.  XCode will now automatically generate a .c file as part of the build.  In my case, these were found at:

build/AutoVersionTest.build/Debug-iphonesimulator/AutoVersionTest.build/DerivedSources/AutoVersionTest_vers.c

You don’t need to even open this file, or include them in your project (that happens automatically).  This file declares two variables, a version string and number that correspond to our build number.  We can put them to good use.  In my sample project, I’ve declared the build number as an external variable in my App delegate:

extern const double AutoVersionTestVersionNumber;

And then in my application: didFinishLaunchingWithOptions method I’ve used the build number on the label I added earlier:

versionLabel.text = [NSString stringWithFormat:@"Build: %1.0f",AutoVersionTestVersionNumber, nil];

Now when testers run my App they’ll see something like this:

Now, a tester can easily identify the build they’re running when giving me feedback.  By the way – if anyone know an easy way to get at our release version number in code, please let me know!  What we need now is a simple way to tie that back to a specific version of our code…

 

Tagging in SVN

Note, this also works with CVS as well, however while there are good arguments for not moving to a more modern system like Git or Mercurial, there’s no good argument for sticking with CVS.

 

agvtool has the ability to update our version information and then commit the changes, simply by adding the usesvn tag like so:

agvtool -usesvn bump -all

Nice.  But it gets better.  We can then tag these changes to make getting back to them simple:

agvtool -usesvn tag -baseurlfortag http://URL/to/svn/AutoVersionTest/tags

The -baseurlfortag option specifies where the tag should go.  After this operation, you’re SVN repository should look something like this:

Now, when you receive feedback from a tester it’s a simple matter to check out the tagged code and you can track down issues with the same code base your tester was using.  Note that the folder specified by the -baseurlfortag option must already exist – agvtool will not create it for you.

 

And Hudson?

Hopefully it’s not too much of a stretch from here to see how we can use this in Hudson (or any other automated build system).  First off, we should create a project in Hudson that will check out our code and build it.  If you already have an existing Hudson project that builds periodically or with each new check-in you can simply clone it (Hudson is good that way).  Configure the project to only build manually by unchecking all the build triggers:

 

And add in new build step(s), calling agvtool to bump our build number and (if using SVN) tag the resulting build.  Note that if this project were set up to trigger a new build when check-ins are detected we have a potential race condition, with agvtool checking in changes which would trigger a new build which would make agvtool check in changes….

So, with these changes in place we can now reliably build a version of our code for testers, tag it and know that we can come back to the code for that build at any time.  And it’s all done automatically.  Also our version numbers will always increase, insuring that our testers don’t have trouble updating to a newer build.

 

And Another Thing

OK, I haven’t played with this one extensively yet, but will add it here for your consideration.  Hudson allows us to add parameters to a build.  When we start a build, it will ask us to supply parameters that affect the build.  As an example we can add a BuildNumber parameter that will decide which tagged version of our code we want.  Configuring it in Hudson will look something like this:

 

So what’s the use of this?  Well the parameter becomes an environment variable when Hudson is building the project.  So we can slip the environment variable into our source control link.  This way, when we kick off a build we can specify the tag to use, making it easy to recreate our App as it was at any stage in its development.

Well that’s it for this week.  If you have any questions or feedback please leave a comment below.

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.

Note: No final article on Automated Builds this week – check in next week when I should have the final article prepared.

It must be the time of year or something, but obviously a few developers have been evaluating their progress and plans for the future.  Not afraid of being a slave to fashion, it seemded like a good time to have a look at the progress of Acorn Heroes over the past year.

In our case this navel gazing has been triggered by the fact that we’re due for our first payout from Apple on September 2nd.  Yep, you read that right, our first.  That may sound like a fairly mediocre result, and in some ways it is.  But there’s also a ray of hope there.  Read on…

Some context

Sam and I are both fully employed on other jobs.  We both have three kids, a wife and a mortgage.  The good side of this is that we’re relatively stable and don’t need to be successful on the App store just to survive.  The flip side is that anything we do is done in a spare hour here and there at the end of the day, family commitments allowing.

Past

Goo! (App store link) was released back in January, and is a fairly niche application for maths nerd who like playing with cellular automata, or possibly two year olds who like the pretty patterns (my youngest is a great example of this).  Despite that it’s been ticking over quietly averaging about 2-3 sales a day.  While it won’t make us rich, or let us quit our day jobs, it will cover the cost of our web hosting and dev license for another year.

iDevBlogADay has been (and continues to be) a wonderful experience – the requirement to write each week is a great motivator and has introduced me to an expanded network of great Indie developers.  If you haven’t subscribed to the iDevBlogADay feed yet, your missing a ton of great content.  Here’s a handy link.

Present

Sam (the quiet one) is doing wonderful things with Secret Project M. It’s only secret because we haven’t talked about it yet – but we should be announcing M officially soon.  We’re in what can probably be described as an ‘early beta’ stage – polishing features and UI and squashing bugs.

Faerie is a promising game idea that I’m looking to develop fully.  Basic gameplay is solid and we’re looking to build a solid, appealing game that will appeal to people of all ages.  Sneezies and Robot Unicorn Attack are great examples of the kind of experience we’re aiming to replicate.

In my day job, I’ve been part of a team working on data capture for high performance athletes – there’s a good story covering what’s been going on here.

Future

So, what does the future hold?  It’s busy, that’s for sure.  We’re aiming to finish M in the next month or two.  Having a second App on the store is a huge milestone for us, especially as Goo! was a proof of concept as much as anything.  To say we’re excited is an understatement.

Faerie is on hold for a little while, because I’ve taken on full time contract work until the end of the year.  I can’t reveal many details at the moment, but we’ll be creating a game for iOS that is linked to a major TV channel.  I’m hopeful that I can cover our progress over the next three months or so.  We’re aiming for a November/December release.

So, interesting times ahead with lots going on.  Sam and I would like to take this chance to thank everyone who’s bought Goo!, followed our blog or provided advice on working in the magical, mercurial world of iOS development.  Your words of encouragement mean a lot to us!