Combat the 1-star menace

In my previous post I mentioned the big problem with the way Apple prompts users for reviews, by asking uses to rate an app at the point that they delete it, this naturally leads to all the people who didn’t like an app leaving a low rating. This is a particular problem with free apps – people download something because it’s free, decide it’s not for them after about 30 seconds and then hit 1 star when Apple invites them to rate it. Meanwhile who knows how many happy users, who didn’t delete the app, aren’t invited for their views.

So, to encourage users to review your app while in a positive frame of mind, and therefore drive up your average score (actually, to encourage a less skewed set of ratings), one remedy is to add code to your app that takes them to the page on the app store where they can review your app. You don’t want to do this too often or it will annoy, and that could generate the type of review you don’t want. So, perhaps you could prompt users who have had the app installed a certain length of time, or in the case of a game if they get a good score, but only do this once. Hopefully enough users will see the prompt while they’re feeling good about your app to generate some good feedback.

I decided to add such a prompt to my game CodeSpin – here’s how to do it:

- (void)rateAppDialog {

   UIActionSheet *actionSheet = [[UIActionSheet alloc]
      initWithTitle:@"If you like this app, please rate it. Thanks!"
      delegate:self
      cancelButtonTitle:@"Maybe Later"
      destructiveButtonTitle:@"Rate it Now"
      otherButtonTitles:nil];

   askedforreviewalready = TRUE;
   [actionSheet showInView:self.view];
   [actionSheet release];
}

- (void)actionSheet:(UIActionSheet *)actionSheet
  didDismissWithButtonIndex:(NSInteger)buttonIndex {

    if (buttonIndex != [actionSheet cancelButtonIndex])
    {
       NSURL *url = [NSURL URLWithString:
          @"http://itunes.apple.com/us/app/codespin/id357871024?mt=8"];

       [[UIApplication sharedApplication] openURL:url];
    }
}

Obviously you need to change the URL to be the page for your app on iTunes. Also, note how we set a boolean flag to remember that the user has been prompted once already. Elsewhere in my code I persist this along with all the other data that I want to store between sessions, and then at the point in the code where a user sets a high score > 200 (which is my way of identifying someone who’s played the game for a little while), I check this flag and if they haven’t been prompted yet, show the alert defined above:

if (hiscore>200 && askedforreviewalready == FALSE)
{
        [self rateAppDialog];
 }

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!

That announcement from Apple…

It can’t have escaped many people’s notice that Apple finally unveiled its new gizmo yesterday to much media fanfare… and as largely expected, it was a small tablet computer which Apple hope will fill a gap between a smartphone / PDA and a laptop, and is called the iPad.

Basically, it seems to be a large iPod Touch, running a version of iPhone OS but with a more powerful processor as well as large touch screen. My first impression was that it is something that would be ideal for someone who wanted what most computer users want (web access, sorting out their music and photo collection, play the odd game, type letters, send emails) without the hassle of actually needing to use a computer, worry about viruses, etc. Most people don’t need a proper computer after all, and find them hard to use (think of your parents or grandparents). For that kind of casual user, the iPad would be ideal. You can connect it to a Mac or PC, but I’m not entirely clear yet whether you need a ‘real’ computer as well, it would seem a shame if you do.

From the development perspective, the interesting thing is that there is a beta available of version 3.2 of the iPhone SDK, and this supports iPad development. The iPad will run iPhone/iPod Touch software and uses the iTunes App Store in the same way, so presumably the main thing in the new SDK will be support for the larger format screen (rumours of support for multi-tasking seem to have been jumping the gun). Apple’s website says something about universal applications working on both devices which presumably means apps which can present different interfaces depending on what device they find themselves running on. The iPad uses a custom designed chip, more powerful than the ARM processor in the iPhone so it’s not clear if it shares the same instruction set or will emulate ARM code.

If the iPad takes off, it will represent a big opportunity for iPhone developers. At the very least, refactoring the UI of existing apps so they can take advantage of the larger screen will keep a lot of people busy for a while. A lot of iPhone apps are very cheap, in some cases novelty items, or wrappers for website to provide a better mobile interface – it will be interesting to see if the iPad drives up the quality and price of the software on the App Store. We might get a new price point emerging, less than the price of full Mac or PC software, but more than the couple of pounds/dollars/euros that the majority of iPhone apps cost.

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!

Getting started

So, how do you get into iPhone development then?

Well, the first step is to get a Mac, as the development kit is only available for Mac. I’d never owned a Mac, so that’s another new thing for me. Which is good.

So, I went off to the Apple Store in my local mega-mall (MeadowHell as it’s known around here) and bought a nice shiny white MacBook from one of the achingly keen people there. I’d only been in the Apple Store once before, to buy a power convertor for my iPod Touch so that it would charge in the car (thanks to Apple changing the voltage that newer iPods work on, something to do with USB versus Firewire, in other words 5v instead of 12v, guess what voltage car stereos work on), and for some reason the people there remind me of the Stepford Wives. Perhaps I just need to be assimilated…

The second thing I did was to buy a book. After some intensive browsing in the bookshop I decided on “Beginning iPhone 3 Development” by Dave Mark and Jeff LaMarche, published by Apress. It seems fairly readable, full of worked examples, and has a website with a forum to go with it.

So I get home with my MacBook, switch it on, and first impressions are good – it powered up fast, found my home wifi, asked me for the WEP key, and that was it, all sorted. Everything looks nice, and once I got the hang of the new multi-touch track pad I was away.

So first task, download the iPhone SDK (software development kit). This is available free on Apple’s website, though you have to register. Although the development kit is free, if you want to actually run apps on your iPod/iPhone (or publish apps via the App Store) you have to pay $99 for an individual or $299 for a company. I left that step out for now, as you can run your code on the simulator which runs on the Mac and is part of the development kit.

The development kit consists of the following:

Xcode
Interface Builder
iPhone simulator

Xcode is the place where you build your code, and Interface Builder allows you to build the GUI to go with it. They’re nicely interlinked, Interface Builder automatically picking up on the parts of your code relating to GUI elements and allowing you to put things together quickly. iPhone simulator allows you to run your code and see the results on a simulated iPhone on your Mac, so you don’t need to port the code to your own iPhone until it all seems to be working properly in the simulator.

The next thing to note is that the language used is Objective-C. This is an extension to C, adding object-oriented concepts. The object oriented syntax is based on the Smalltalk language, and looked pretty odd to me, despite having done a little Smalltalk programming at university. The other object-oriented C like language I’ve had exposure to before is C++, and the syntax is quite different, though the concepts are the same. There are a lot of square brackets involved!

The other initial thing to note is that there is something called Cocoa Touch. This is the API for the operating system used on the iPhone / iPod Touch, and is similar to Cocoa on Mac OSX, or I guess .net or MFC in Windows. It’s basically an API in the form of a bunch of classes (in Objective C) that your programs will make use of to interact with the iPhone.

So, looks like there’ll be plenty to learn…!

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.