Can a free version boost sales of a paid iPhone Applications in AppStore?

Many iPhone publishers found that a dual release of a free lite version and a paid pro version of an iPhone app pays off.

Our own experiment...

We wanted to see if the free/pro approach works and have released a location sharing utility called Pinpoint for the iPhone. The Pro version of Pinpoint was released 3 weeks ago with expected download figures. The app was prices at US$2.99 and had reached approximately 150 downloads in 3 weeks.

Our experiment was constructed to see whether a free Lite version of Pinpoint could increase the sales figure of the paid Pro version. We also wanted to see whether we could boost the downloads of the paid app to get it into one of the Apple top lists. So we lined up three things

1. new free lite version

2. drop the price one tier (from US$2.99 to US$1.99)

3. Show messages on our existing apps to our existing user base

As @quamen pointed out it would be not trivial to see the impact of the free app because we have changed 3 variables at the same time. So, to isolate the the impact of the free app we have experimented with prices drop (2) and promotion messages (3) before and know what the impact of each of those changes is. So we should be fine to filter out the impact of the free app release (1).

after 5 hours...

Pinpoint Lite was approved by Apple on the 11th of August and reached 100 downloads within the first 5 hours. For tracking and user notification about the newly released app we are using shoutmob.com.

after 12 hours...

Over the last 12 hrs people have downloaded Pinpoint Lite more than 300 times.

Downloads in Pinpoint Pro have more than doubled. Knowing the impact of the price drop and promotion messages we can say that the impact of the free app alone was approximately 100% increase in paid app downloads.

So far we can confirm the boost and the effectiveness of shoutmob user notifications.

after 2 days...

I did not expect that the Lite version would be so popular. It made it in less than two day in the AppStore to #30 in Australia under Free Navigation apps and #46 in the US. That's a nice side effect but was not goal of the experiment.

The Lite version was downloaded 630 times so far.

So, how is the Pro version going after 2 day?

The conversion rate is lower than we thought. We are converting less then 10

% of the Lite users to upgrade to the Pro version. The price drop should start wearing off by now and all the downloads from now onwards come from Lite to Pro upgraders.

For the Pro version we can see the same download figures as in the first 3 days in the AppStore. The graph shows the downloads in the last week for the paid app. The impact of the price -drop and Lite version release are quite obvious.

[UPDATE]

after 3 days...

The Lite version is still on the "new Releases" page in the AppStore. Downloads decreased slightly compared to yesterday. I would expect that once we get on page 2 that downloads will decrease by 50% - lets see.

Pinpoint Lite ranks #42 in US and #28 in Australian free navigation apps.

Pinpoint Lite was downloaded 1000 times within three days with approx 340 new users a day.

The Pro version is almost unchanged. Even the price-drop should have worn off by now we see similar download numbers as in the previous two days.

The paid app is still going OK and I suspect that most downloads come from people

upgrading from Lite to Pro. Here are some graphs based on

shoutmob realtime analytics.

The total usage per day which trends upwards.

[UPDATE 2]

after 4 days...

The Lite version is no longer on the "new Releases" page in the AppStore. As expected, the number of new has decreased.

Pinpoint Lite ranks #43 in US (-1) and #27 in Australian (+1) free navigation apps.

Pinpoint Lite was installed 1300 times within four days. With 280 new users on day 4 which is 80% compared to the day before .

The Pro version the same user rate as the day before.

From here it will be really hard to stay in the top 100 with the free version.

More downloads than installs

One interesting fact is that the Apple reports show higher numbers than shoutmob. Where Apple reports showed 480 downloads shoutmob showed 350 users. So some 130 users have downloaded the free app but never used it. While Apple's report shows download numbers shoutmob shows the number of app that have been used. So there seem to be people who download free apps but do not use it. Looking at my own app download behaviour I sometimes download in iTunes but may take another day before I synchronise with the iPhone. Maybe that is what other people do too.

[UPDATE 3]

after 5 days...

Pinpoint Lite ranks #44 in US (-1) and #32 in Australian (-5) free navigation apps.

Pinpoint Lite was installed approx 1500 times within five days. With 260 new users on day 5 which is 92% compared to the day before .

The Pro version has now increased the number of users by 33% compared to the previous day.

JSON and RESTful web services on the iPhone

We use JSON on the iPhone to access RESTful services on the Internet.

JSON seems to be the dominant and easiest way to use web services over the Internet. 

We used it in our native iPhone app (PinPoint) to integrate with Googles Geo Location APIs. Fortunately, Google supports JSON and XML. I have chosen to use JSON over XML for no particular reason other then "want to play".

 

What kind of app do you have?

1. A web-based  app that runs on Safari
   
2. A native iPhone app that uses Objective-C and Cocoa.
   

Both flavours of JSON-iPhone integration are covered in this blog entry.

1. A web-based  app that runs on Safari

JSON form web apps based on WebKit / Dashcode

The first iPhone JSON integration I did was for a web app that I developed with Dashcode. The app required only the list of trips from our Rails app. No associations or nested objects were required. The JSON response was an array of simple objects. This list was displayed as a typical table view and tapping an item opened the detailed view without making another http request. 

This exercise was surprisingly simple because I could deal with well-known technology (JavaScript, HTMP, CSS, DOM, AJAX).

2. A native iPhone app that uses Objective-C and Cocoa.

JSON using Objective-C / Cocoa / XCode

I have to admit this is not as nice as for the web app using WebKit/Javascript. Not really a surprise since JSON is actually a serialiseed JavaScript object and no mapping is required.

Using JSON in Objective-C / Cocoa is less natural. The Objective-C / JSON framework I used does return the JSON structure mainly as a NSDictionary and NSArray.

If you are using the JSON framework with the iPhone SDK 2.2 then check out this article.

I used JSON to get Geocoding data from Google. The Google JSON API was actually not documented at the time I developed my app, which made it a bit more exciting. The JSON structure that is returned by Google is a mix of nested objects and arrays. I would say that the Google Geo location API returns a pretty complex but well structured data structure.

The JSON framework  for Objective-C does all the hard work of mapping the JSON structure into Cocoa data structures (NSDictionary and NSArray). Now that the data is in Objective-C object my code needed to access the parts I am interested in. The code needs to be aware of the returned JSON structure and that is where I feel things become a bit hardcoded. I needed to access parts of the NSDictionary objects that where pretty nested and had to traverse the tree through pretty long statements.

Show me the code:

Here is a simple example that shows how I get the JSON data for a reverse geo coding call to Google. The exampled will get the address string from the JSON structure.

NSString *jsonRep    = [[NSString alloc]        
      initWithData:data  encoding:NSUTF8StringEncoding];  

NSLog(@"Got this form JSON");

NSLog(jsonRep);

NSDictionary *dir = [jsonRep JSONValue];

NSArray *arrPlacemarks = [dir valueForKey:@"Placemark"];

NSDictionary *dirPlacemark0 = [arrPlacemarks objectAtIndex:0];

NSString *address = [dirPlacemark0 valueForKey:@"address"];

NSLog(address);

The code to get the more granular part out of the Geo location  JSON string is not that simple but in principle the same approach.  

1. You need to know where the particulare information resided in the JSON strucutre.

2. Navigate the structure to the particular NSDirectory or NSArray and get it.

What could break:

As soon as Google changes their API I am sure my app will break. The above approach will not survive any serious schema changes. As soon as Google changes the nesting of objets in their JSON response I will need to modify my code.