Updates and freebies

Recently I’ve been spending some time teaching myself some new programming skills (Silverlight with C#) so not done much more iPhone development. However a bug came to light that needed fixing in my released app CodeSpin (if the screen was locked while the game was playing then the countdown timer misbehaved), so once fixed I was ready to release an update version (v1.2 in fact).

In the last few weeks the app hadn’t had many downloads, so I thought I may as well do an experiment and reduce the price from 59p in the UK (99 cents in USA, 79 cents in Euroland) to nothing, until the end of the month (May).

The following day I logged in to the Apple portal not sure what to expect – and found there’d been over 400 downloads overnight! Several hundred followed the next day, and a couple of hundred the next few days as well. So it tailed off a bit, but even so – a week with no downloads at all, followed by a 1000 downloads in half a week. Looks like a lot of people appreciate something for nothing!

I knew there were several websites that track and announce price drops for iPhone apps, but these numbers were still surprising. I’d also announced the update and price drop on various forums, but the number of views of these postings didn’t add up to half the number of downloads in the first day, so I can only assume a lot of people look at or subscribe to the price drop sites.

Now this is good since it means there is a way to get an app noticed (apps get almost no visibility on the app store unless they have enough sales to appear in the top 80 for any category, and the recently released list was no use to me when I released my app since it never appeared in the first couple of screens) but it’s also perhaps instructive of the number of people that will download something seemingly just because it’s free.

A common approach is to have a free version of an app purely as a sales driver for the full version, just so that the free version can get you some visibility and those all important iTunes ratings. I had tried giving away promo codes via forums which only got one or two reviews – but now I’ve noticed that several people who downloaded the app once it went free gave it one star on the same day it went free. I can only assume that these were people who saw that a game was free, downloaded it, and then immediately decided it wasn’t for them (it’s a logic puzzle game after all, not the next Doodlejump or Angry Birds), deleted it, and hit ‘1 star’ when prompted by the delete app dialog.

Now I don’t want to whinge, but this does seem a little unfair that the first people to delete an app when the realise it’s not their sort of thing, are probably also the first ones to rate the app. My game takes a little while to learn how to play properly, so people that give up straight away won’t have understood it – meanwhile (I like to think, at least) some other people who do like it are busy playing it, and aren’t prompted to rate it. A couple of 4 and 5 star ratings in the US store seem to indicate that some people like it, at least! (as did the test subjects I tried it on before release).

The other thing is, I’m not sure if making it free for 2 weeks was the best approach – there was such a spike in downloads from the first day or two that I can see why many developers have a one day sale for apps as a way to drive the app up the sales charts. Will the number of downloads tail off over the next week or so even though it’s still free, or settle at some level? Time will tell…

My first app available on the app store…

A while ago now I decided that going through the tutorials on Objective C in a book was all very well but I really needed to write something of my own from scratch in order to really get to grips with it, and I wrote a version of the old Mastermind or Bulls and Cows game where you have to guess the secret code based on clues about how many of your guesses are correct and how many are in the code but in the wrong place. To make it more fun I made it against the clock, and added a scoring system where you are awarded points based on how quickly you got the answer, but with points taken away again for each guess to discourage just trying every combination. I also used numbers rather than colours and the picker wheel UI which is a standard GUI element in Cocoa Touch.

This simple game proved to be a good way to learn about quite a few aspects of development, such as the difference between regular arrays and mutable arrays, how timer objects work, how to store data in plists, how the settings bundle works, and so on.

Anyway, when you’re 90% finished you’re halfway there goes the old saying, so a couple of weeks ago I decided to finish off the app to a proper standard and get it published. In addition to obvious things like adding instructions and making an icon, there turned out to be several other things to learn such as obtaining another device profile from Apple to build against (I already had a profile for my iPod Touch so I could build and run my program on the device, but you need another profile again for distribution), all of which was quite time consuming and involved. A lot of the reason why it’s quite involved is to do with Apple’s decision to lock down iPhone OS so that the only way to install software (officially at least) is via Apple.

When everything was finished and built against the new distribution profile in XCode I submitted it to Apple and awaited their decision – there seems to be a degree of automated checking which happened straight away but once that was happy the status of my app was shown as ‘waiting for review’ After 24 hours this changed to ‘in review’, and then a day later it was approved – see it here on the App Store.

At this point I encountered a couple of new traps for the unwary – first, my app is showing as only available for OS 3.1 (which I have installed on my iPod Touch) even though I didn’t use any APIs that weren’t in 3.0, which probably reduces the possible number of customers by a large margin (my son for example doesn’t see why he would spend any of his pocket money on updating the OS on his Touch) so I need to find out how to remove that restriction. Secondly, the App Store is meant to display apps by release date as well as by best selling, which is the only way a new app will get any visibility to potential customers on the store. However this seems to be a bit confusing at best (some blogs say broken); for several days my app didn’t appear on this list at all, and then it appeared but a very long way down where it won’t be seen by many people. Apple don’t seem to be very clear on exactly how this works, and this is another thing that I’m glad I’ve found out about on my first app and not when I come to release something which I’d invested a lot of time in and needed a return from.

You can read more about ‘CodeSpin’ here and if you like that sort of puzzle game, why not give it a try? I’m hoping that the scoring system (it remembers your high score for all 4 skill levels) and the element of trying to beat the clock will make it quite addictive – my best score so far is 716, if you beat that let me know!

Building an interface

As I mentioned in one of my earlier posts, programming these days is quite different to how it was when I first learned. You used to write a program and that was pretty much it – your program would interact with the operating system of course just by using standard functions or commands in the language you were using, and occasionally you might use some other library of functions. If you were implementing a GUI you’d need to design that on some graph paper as all the buttons etc. needed to be placed by writing code.

Nowadays, using IDEs like XCode on the Mac or Visual Studio on the PC, things are a bit different. For one thing, you never write an actual program from scratch – you create a new project, and a whole bunch of code, across several files, appears as if by magic. Your task then is to fill in your code at the relevant points, either adding to or replacing the boilerplate code that was automatically created.

Secondly, there’s probably some sort of graphical tool for producing the GUI. On the Mac this is known as Interface Builder. When you create a project in XCode, one of the files that is created for you is a .xib file (known, for some historical reason, as a “nib” file). When you click on this in XCode, up pops Interface Builder. These same tools work for both Mac and iPhone projects.

Now, at first glance this seems very nicely done – Interface Builder (I’ll call it IB for short) allows you to drag UI elements from a display list and place them where you want – in the case of iPhone projects, on an iPhone sized screen display. All the standard bits of iPhone UI are available, and when you place them IB does a very nice job of helping you position things properly with guide lines etc., it really is quite easy. Any text labels etc. can easily be typed in and the font, size, colour, etc. changed. So making the UI look like it should is about as straightforward as it could be. Of course, you’ll need to connect the UI elements to your code in some way before they actually do anything, and Apple’s way of doing this is for IB to spot certain markers in your code (for variables and functions/methods) and allow you drag a blue line indicating a connection between the UI element in question and these parts of your code.

To understand this you need some lingo, as you need to use “outlets”, “actions”, “data sources” and “delegates”:

Outlets are variables that the UI will interact with (the text in a text field for example)
Actions are methods/functions that the UI will call (the action to be performed when a certain button is pressed for example)
Data Sources are, well, sources of data that will be used in the UI (the choices available to the user on a picker list for example)
Delegates are classes that are used to handle something that Cocoa would otherwise do, but which for some reason Cocoa needs to delegate to you (populating the data of a picker for example)

In your code, if you use the keyword IBOutlet in the definition of a variable, or the keyword IBAction in the definition of a method, then IB will display these variables and methods (outlets and actions) and you can graphically (by dragging) connect input fields to outlet variables and buttons/sliders etc. to action methods. It’s worth noting in passing that IBOutlet and IBAction are effectively defined as null, they don’t do anything in terms of your code, they are merely markers for IB. Note that action methods should return IBAction, and also they normally take one argument which is the id of the ‘sender’ (i.e., the UI element that sent the message to cause the action).

So, you create the outlet variables and action methods in your code to store data from the UI or to do something when the user requests some action, connect them to the right UI elements in IB, save everything and build, and all should be well. Probably in most cases you would implement very simple action methods then connect up, save and build, then run to check you have the plumbing right before getting too far down the line of writing lots of code. Alternatively of course you might have already written and debugged some quite complicated bits of code and just need to connect it up to the UI.

Data sources and delegates are slightly clunkier in that you need to add some #pragma directives to your code but the principle is similar.

Now this is all well and good. But one problem that I’ve encountered a couple of times now is that, if you have managed to make some sort of error in IB (I think of it as doing some plumbing, or wiring everything up) then generally your code will compile fine but at runtime it will crash either on start up or when you perform some action in the UI, and all the debugger will tell you is that there is an unhandled exception. This doesn’t help you a whole lot since what it means is, some code you didn’t write and don’t understand is interacting badly with some other code you didn’t write and don’t understand. How do you track down what went wrong?

I’d love to know the answer to that, but so far I don’t. I had this a couple of times whilst going through the worked examples in the Beginning iPhone Development book, and I only fixed it by backing up and starting a project over. Then, I got bored of typing in example code and came up with a simple program of my own – at first I was pretty pleased with myself as that went well and I hooked everything up in IB and it ran and did what it should. Great, those earlier problems were clearly down to me just not really understanding what was going on. Unfortunately, several days later when I tried to add some new functionality to that program, I broke things again. Eventually I got the code for the new thing working, but the interface was still broken and it crashed on start up. So I spent some time commenting out all my new code, and removed the UI element I’d added in IB. Still crashes on start up. Clean build. Same problem.

So, I can’t help thinking there’s something less than ideal about this graphical approach to programming. In the old days you’d print off a program listing and go through it on paper, seeing in your head how everything worked, or should work. I kind of need something similar to that now, some table in the code showing the linkages between UI elements and code elements. Or some debugging tool that will tell you when you’ve done something really dumb in Interface Builder.

I asked my friend who is a more experienced Mac programmer about this and he said the best thing is just to get it right first time. This reminds me of the Dutch genius of 1970s football, Johann Cruyff, who once said “before I make a mistake, I first do not make that mistake”.

I think what this means is that practice makes perfect, so I’d better get back to it!

Hello World!

I recently decided to teach myself how to write iPhone apps, and this blog is all about that. I’ve worked in the software business for years, but despite starting out as a software engineer, for the last umpteen years I’ve mostly been a technical writer and so my programming has been limited to short example programs, scanning the source code for information needed in the manuals that the developers didn’t think to tell me, and so on. Oh and the odd perl script to automate various technical authoring tasks. Boring stuff, in other words.

Back when I was paid to write software it was mostly C on Unix (or Borland C on PC), and most of what I wrote was either systems stuff or computer graphics stuff, so I’ve not too much experience of implementing GUIs in modern development environments. Of course, these days what employers seem to be looking for is C# or C++ which mostly seems to mean knowing MS Visual Studio backwards. I’ve never really got to grips with Visual Studio, so wanted to do something more, well… fun.

So, the idea struck me that learning how to write iPhone apps would be a good, and more importantly fun, way to get back into developing software. There seems to be a lot of relatively simple software for sale or free download in Apple’s App Store, in a way it reminds me of the home computer thing in the 1980s. I don’t expect to become a millionaire from writing a hit app (most of the obvious ideas have probably already been done) but it also occurs to me that there’s a lot of scope for mobile front ends for a lot of software, as these devices (iPhone, Blackberry, etc.) are pretty commonplace nowadays. And again, the iPhone seems the most fun (sorry Blackberry fans…). I’ve even seen proper job adverts asking for iPhone developers. So it seems a good bet.