Oz Weather Progress

I’ll save exact sales figures for a later post, but Oz Weather has moved gradually up the paid apps ranking in the Australian iTunes app store to 3rd spot.

As icing on the cake, Oz Weather also appeared for the first time today in the “What’s Hot” rankings in 8th spot. This means that Oz Weather now appears twice on the front page of the Australian iTunes store. It seems clear that this can only result in a sales boost – as it is being put right in everyone’s face, so to speak.

I have read in some postings on the Apple iPhone developer forums that it seems a bit unfair that top ranking apps by sales may also appear in the what’s hot rankings. As a beneficiary of this policy, I’m obviously not going to complain about it, but I do tend to agree anyway. I’m sure customers would prefer not to see the same app more than once on the front page.

So it is all great exposure and advertising – and yet all this without even a cent of advertising expenditure on my part. I guess that’s what makes the 30% Apple cut seem so very reasonable – especially when you compare it with the time and energy you need to invest when you are starting up cold with a new app or website in the “real world”. I’m betting you’d need to give at least a 50% cut to any marketing/sales partner you joined forces with.

The other benefit of the app store model is that developers don’t need to have a dual focus on development and marketing/sales. Instead they can just focus on what they presumably do best ie. develop good quality applications. I’m not saying that some additional advertising and promotion won’t help your sales, but if that’s not your expertise, using the app store to sell your products may allow you to achieve some success without it.

PS – Almost forgot to mention it, but Oz Weather v1.1 appeared in the app store on 20th November – about 4 days after it was submitted to Apple for approval (in contrast to 2 days for the first version). This updated version is in response to user requests for more radar coverage, and a number of other smaller tweaks and enhancements. In fact there are now around 150 different radar locations and ranges covered in all. It makes for a bit of a hit on the Oz Weather server, but user feedback has been very positive, so well worth the extra time and effort it took.

Advertisement

Oz Weather Apponomics

At the time of writing, Oz Weather is listed as 7th in the list of top paid apps in the Australian iTunes store.

So apart from that warm, fuzzy feeling you get when you see your the fruits of your labor actually being bought and used and appreciated, just what does this mean? In particular I mean in terms of sales and revenue. Is that level of success enough for someone to retire on? Or is it just a folk legend that you can get rich quick if you can just find someone to help you build your own iPhone app?

Its not the norm to publish your own app’s sales and revenue figures, but I thought that by sharing Oz Weather’s data I might encourage some others to share also, and so perhaps help us all build up a true picture of the economics of building and selling iPhone applications.

The Costs

I started developing the weather data collection back-end in June 2008, before I had any expectation of building an iPhone app. At that point, I was just experimenting/playing with a prototype web application displaying some useful world-wide weather data in a different and more-accessible way than is available elsewhere. I used PHP and MySQL and put together a basic website using Dreamweaver. I probably spent about 10 days worth of effort in putting this together. However, I’m not going to count that as part of my economic assessment, because it occurred prior to project commencement proper, and I would have done it anyway.

The first phase of the project proper was to build an iPhone web-app (the idea being to test the water before attempting a native app). To do so I invested AUD$1400 (US$1,000) to hire a designer plus AUD$100 (US$70) in miscellaneous other costs, and spent about two weeks of my own time to adapt the existing back-end to cope with detailed Australian specific weather data, and to fine tune the app to its release state. The result was a web app listed and endorsed by Apple as a “staff pick”.

The second phase was to build an equivalent native app. Although I toyed with the idea of out-sourcing the development, I decided that I really wanted to learn how to develop iPhone apps myself. Subsequently I spent about 30 days effort in bringing it to a releasable state. (I estimate that would have been maybe 20 days if I had not had to go through a steep learning experience with Objective-C, X-Code and OS-X to start with.)

If the total effort invested of 40 days were factored in with a modest contract programmer’s rate of say AUD$350 per day (US$245), the total project cost would be AUD$15,500 (US$10,850).

The Sales Volumes

For the first 14 days of sales, the total number of units sold was 1586, and averaged 140 units per day over the last 7 days. The daily sales are graphed below, for the period Nov 1 to Nov 15, 2008. Sales to Australian customers are shown in orange, and to overseas customers in yellow.

The Revenue

The initial web app was monetized by including AdMob advertising as a banner across the top of the page. In a previous post I mentioned that AdMob had started with an eCPM of about US$7, but shrank progressively to around US$1.20, which is roughly where it remains now. With about 26,500 cumulative ad requests so far, at an average fill rate of 77%, total advertising revenue amounts only to about AUD$50 (US$37).

In contrast, the native app went in for sale at Apple’s “Tier 2” retail price of AUD$2.49 (US$1.99). After deducting 10% Australian Goods and Services tax (applicable to sales made to Australians), and Apple’s 30% share, this leaves approximate revenue of AUD$1.58 (US$1.39) per copy sold. Hence total revenue so far is about AUD$2,500 (US$1,750).

Projections

This current weekly average rate of sales if it were to be maintained equates to AUD$6,700 (US$4,700) per month. That look like a good rate of return for the investment of AUD$15,500 (US$10,850), suggesting a break-even point at between two and three months.

However, I believe that the likelihood of maintaining the same rate of sales over an extended period of time is low. Here are a few reasons why.

• I gather that there is typically an early peak in sales, especially as your app initially appears at the top of the list of recent releases, and is hence typically most visible to potential customers in its earliest days in the app store. It also gets a boost if it rises into the top ten (as it then appears on the front page of iTunes in the top apps listings – apparent in the graph above on day 9), but if it drops down below 10th again, then visibility is lost, and hence that fall in popularity is likely to be amplified, too.
• There is the factor of competition. There was already a very worthy competing Australian weather app in eh app store before Oz Weather was launched, and although they have now dropped back in popularity (sorry guys, if you’re reading this!), they could rise again, and there could be further new competitors too – perhaps even more so if others like look of these revenue figures.
• There is the possibility of market saturation for this type of product. Whilst the market is continually growing in size, with ongoing new iPhone sales, you may manage to saturate pre-existing iPhone owners, and have to rely only on sales to new iPhone acquirers.

No doubt other developers with app store experience will also have some thoughts on this… If so, please do leave a comment.

Conclusions

Of course I would be lying if I suggested that I wasn’t optimistic about doing much better than just breaking even with this app. But its early days yet, and I haven’t got a lot of other app data to compare with.

When looking at the bigger picture and applicability of these figures to other apps and other countries, the following points are probably also relevant.

• Because the Oz Weather app has only Australian weather content, these figures reflect the apponomics of the Australian iTunes store only. The population of Australia is only about 7% that of the USA, and hence equivalent app ranking in the US iTunes store may well reflect a much higher level of sales than those I am reporting here. However, there is also likely to be a greater level of competition within larger markets like the US, given the greater revenue possibilities these present, and achieving the same ranking is therefore also harder there.
• Whilst Oz Weather is a country-specific app, a weather app like this one has a broad target audience within Australia. Other applications which are more niche-oriented would presumably also have a much harder time achieving an app store ranking of this level in any country.

What Next?

I intend to report back from time to time to see which direction things are heading in as time goes on. And I also hope that some of you other iPhone developers out there will be willing to share your data (or at least their broad characteristics) too. That way we can all get a better idea about just what to expect before we actually start trying to implement our next big iPhone app ideas.

So… now I have a question for you. Have these figures put you off, or have they encouraged you to get started on your own iPhone app right away?

Are you being shortchanged by your iPhone’s GPS?

Executive Summary

Yes you are, but you’ll just have to get over it.

Full Article

As you might expect of a geeky runner, I have always enjoyed measuring my runs – time, distance, pace, heart-rate, etc – and then competing against myself.

A couple of years ago I acquired an accelerometer based device which you attach to your shoe and works in conjunction with a heart-rate monitor watch to give you your distance speed etc. It worked pretty well for a year or so, but then even with fresh batteries it started mismeasuring by 10 or even 20%, which made it useless, and I had to give up on it.

But then – enter stage left the iPhone – along with its built-in accelerometers and its GPS system. Unfortunately, after some investigation using  a test application that I built, I realised that the accelerometers were not going to be accurate enough for any real-life measuring purposes. But that still leaves the iPhone’s GPS system as a candidate for run tracking.

So a couple of days ago, during a brief break from app development, I stumbled across just the app I was looking for. Enter stage right RunKeeper for the iPhone.

There are several iPhone applications which perform similar functions, but RunKeeper just happened to be the one that caught my eye, and I decided to try it first.

My first attempt at a run had a few glitches. Specifically, I overlooked the advice not to put the device to sleep. Consequently, half way through the run I woke it to find that it had correctly kept track of elapsed time, but it hadn’t yet realised that I had moved at all, at least until the GPS kicked in a few seconds later. Later analysis of the map that RunKeeper creates for you on its website showed that it then thought I had traveled in a perfectly straight line from start to that point, even though my path had actually meandered, and consequently the distance traveled estimate was well short of reality.

My second attempt was more successful. I kept it awake the whole time, and when I got back I logged into the RunKeeper site and could see that it had actually tracked my run pretty well. But its estimate of distance covered was a little bit short of the distance I found myself by using the Google Earth ruler to measure the path I took in some detail specifically 3.59kms according to RunKeeper vs 3.75 kms according to Google Earth manual measurement. That’s a 4.3% shortfall. Not too bad from a big picture point of view, but terrible from an egotistical runner’s point of view, because it makes you look 4.3% slower than your actual pace!

The reason for this becomes apparent from the following screen shot from the RunKeeper website, to which I have added the yellow path and labeled arrows. I zoomed the map right in to Cremorne Point and switched on satellite view instead of map view, to make it more apparent what is happening in a small segment of the run.

You can see that the GPS record of the path (red) cuts off the sharpish corner that I actually took (yellow). And the same thing happened at almost all abrupt turns that my course took, such as at street corners. The reason for this is quite obvious – its because the GPS tracking data only gets updated at intervals, and if you happen to turn a corner between GPS fixes, then the tracking software can’t really do anything other than assume a straight line between those points.

So in actuality this issue is not just an iPhone issue or a RunKeeper issue. Its more an issue with using GPS tracking in general, and just how much you get short-changed by your GPS run tracker depends on how often accurate fixes are obtainable by your GPS device.

If anyone out there knows the inherent limitations of GPS tracking intervals vs the inherent limitations of the iPhone’s own GPS device and SDK, please show your hand now. If we can’t actually prevent ourselves being short-changed by our GPS tracking systems, then it might soothe our egos just a little to understand why.

Oz Weather Video Demo

And just for those who refuse to rush in and buy, buy, buy without knowing just a little bit more, here is a brief video demo of Oz Weather.

No iPhones were harmed during the making of this movie, but I should probably apologise to residents of Perth for making their city look like the bad weather capital of Australia. Sorry – but it had to be done!

Oz Weather Goes Live

It seemed like an endless process, and had many twists and turns, but Oz Weather is now alive and well and kicking in the app store.

Click here to check out Oz Weather in iTunes

[Update – also see my later post for a video demo]

Since my last post on Oz Weather just 9 days ago, some major changes have taken place – especially to the colour scheme and visual design. For what is obviously a massive improvement, I am especially indebted to Peter Fellows, who (presumably frustrated with my pedestrian and unadventurous color scheme) created a mockup of several proposed designs, one of which I was so taken with that I just had to implement it immediately. And here is the final result.

I have to say I am very pleased with the new appearance. I think it is fully in keeping with the iPhone design paradigm, and more than does justice to all the work that went into building and refining the back-end and data delivery framework.

The app submission process wasn’t an easy one – not so much from the technical perspective, which was reasonably straight-forward by Apple standards – but more from the admin and taxation side of things. This even involved making a phone call to the US Internal Revenue Service to obtain an Employer Identification Number, which is not an easy feat given the timezone difference between Sydney and USA, and completing an obscurely-worded tax form to claim a (partial) exemption from US withholding tax. The fact that Australian companies get only a partial exemption from US royalty withholding tax when there are a good 20 or so other countries that get a full exemption, in spite of the so-called Free Trade Agreement we have with the USA, is something that is as irritating to me as it is puzzling. But that really belongs to another kind of blog.

The timing went like this. I submitted the application details and executable file at 8:30pm on Thursday. I then read and agreed all the contracts, contacted the IRS, filled in all the forms, sent copies of my GST registration and supplied my banking details, including such details as my bank branch’s SWIFT code. So by midday Friday all the status icons in the “iTunes Connect” developer portal had turned to green, and the only orange light was for the app executable awaiting approval. Based on other stories I had heard I expected to wait at least a week, and with a 50% chance of rejection due to some slight oversight I may have had. But, incredibly, at 8:15am on Saturday, the final approval email arrived. That’s less than 36 hours since submission! I then started looking in the App Store to see if it had appeared, and temporarily gave up at midday, wondering what part of the process I may have overlooked that was preventing it appearing. But then when I checked again at 4:30pm on Saturday it was there. So in entirety it was less than 48 hours from submission to being on sale.

So potential iPhone developers – take heart. It may just be worth it, after all. And perhaps Apple have actually now worked throught the backlog of submitted apps to approve….?!