Plotting a Cold Change

Saturday 23rd January 2010 saw a classic heatwave/cold front event occurring up the eastern coast of New South Wales Australia, and I observed from Sydney, watching things progress during the day via the internet, as well as from my own home, where I have a view across parts of Sydney.

Oz Weather v2.1 introduced graphing of weather history as a new feature, and the graphs from that day show the change very clearly indeed. The following graph is a composite of the different ones available in Oz Weather, although I have overlaid a transparent bar indicating the time when the main changed occurred.

A summary of the changes:

  • Temperature dropped from about 41°C to 22°C.
  • Humidity jumped from 10% to 85%
  • Wind jumped from 30km/h to 65km/h with gusts to over 95km/h just as the change came through, and the direction shifted from NW to S.
  • Interestingly, the pressure started to rise an hour or so before the main change, and there was a little rain from some thunder cells that developed following the change.

The Doppler (wind) radar also showed the approach of the wind change very clearly. Unfortunately I didn’t save a graphic from when the change was passing right through Sydney, but an earlier shot shows the change passing through Stanwell Park, to the south of Sydney.

The key point here is to note that blue indicates wind towards the radar location (centre of crosshairs) and yellow indicates wind away from the radar location. So this is showing strong NorthWest winds (blowing offshore) over the Sydney region, but from the South at Stanwell Park and below. This picture was a lot more striking as the change passed through Sydney itself, but I’ll have to wait for another event to show that off better!


Sun Seeker Lite

I’m pleased to announce the arrival of Sun Seeker Lite – a free version of Sun Seeker (finalist in the 2009 Best App Ever awards), albeit without the augmented reality view!

After my recent experiments and experiences with in-app purchase, I’m now putting more effort into the Lite version concept. Although it requires creating a whole new app, in practice it is simpler and safer than the in-app purchase method, for a range of reasons. In fact I have already added an Oz Weather Lite version of the full Oz Weather app, and Sun Seeker Lite is my second Lite app.

That is not to say that the decision of exactly what features to put into a Lite version is an easy one. In this case I removed all augmented reality features, which is of course the big selling point of the full app, but on the other hand I’m pleased enough with the look and feel of the main screen’s flat compass view, that I think it will create the right impression for users, and persuade them that the quality is good enough to warrant purchasing the full app.

Despite the fact that it does omit the augmented reality view, the flat compass view in the Lite app can still be very useful in many situations. Please give it a go, and pass on the word to others if you like it, or perhaps even (gasp!) leave a positive review. 😉

Five Good Reasons NOT to Implement In-App Purchase

I’m writing this in light of my recent experience with the Oz Weather iPhone app.

In mid-December I issued an update to the app, immediately after which there was a major app store glitch which caused a huge problem in its own right. But having already documented that previously, I will here discuss the new in-app purchase which was introduced to allow users to enable a set of “Pro” level weather features. In addition to this, I provided a 7 day free trial of the Pro features. As a result of these changes I’ve had a significant number of sales of those Pro features, but I’ve also had a spate of awful (even vitriolic) user reviews, which have significantly lowered the app’s average star rating, and the app’s ranking and new app sales levels have been adversely affected ever since. 😦

Reason 1 – It is not trivial to implement it well

There is plenty of sample code available that you can use to implement the in-app purchase process, but you still need to design and implement your own “storefront” which displays information about the purchase, how much it costs etc. You also need to make sure your app logic works correctly both with and without the purchased items having been activated, and although this might be straightforward in apps where the content is already well compartmentalized, it is much trickier in other types of app where different app features typically have some integration, and need to be separated out carefully when split into standard/purchased functionality.

Testing that the purchase process works correctly and that the purchased content is made available correctly, and if necessary also registers on your own server, is also much slower and more difficult than ordinary app debugging, as it requires using a test sandbox accounts and server interactions. You also ought to test what happens if the purchase process is interrupted, or the server connection is interrupted during purchase or after purchase confirmation, but before you have saved the app purchase status to your own server. All these things can and will happen sooner or later if you have any significant number of users, and you will want to make sure you can deal with them all, and at least recover gracefully later if they can’t be dealt with up-front.

Reason 2 – The developer must take full responsibility for correct delivery of the purchased item

With a normal app purchase the developer can wash their hands of the sale process. Apple deals with the entire sale process and installation of your app, and if something goes wrong with that, and a user loses or needs to restore their purchase, install it on a separate device, or has any other issue, then it is Apple’s responsibility, and you are within your rights to refer any complaints about this back to Apple.

However, with an in-app purchase you suddenly take on much more responsibility. Although Apple does keep track of in-app purchases itself, and can restore these to the user, you will probably also want to keep track of purchases too – at the very least a database of app ids which have made the purchase, so that if the user simply re-installs their app, the app can determine on startup whether the purchase was already made previously, so they won’t have to go through the in-app purchase process again to get it back. Of course if you want to offer a trial, as I did, then you will have to maintain a similar database to keep track of that too.

The most difficult scenario, though, is if your in-app purchase is a time-limited subscription. In that case, Apple has no record of whether or not the subscription has expired, and it is totally up to you to maintain correct reliable records which can be used to restore each users app state. If anything goes wrong with your implementation of this, then it is you who will be responsible for refunding your users! Will you be able to sleep at night knowing this?

Reason 3 – A lot more user support and interaction is required

Although most users will already be familiar with app purchasing paradigms, many users have not used in-app purchase before, and this means that you will likely get a lot of queries due to their inexperience with the process and its quirks and implications.

Here is a list of some of the types of new user issues I’ve had to deal with as a direct result of the in-app purchase, for example:

  • Questions about why they get a message saying purchases are disabled on their device
  • Questions about why they get a message about a “Test User” account when they try to purchase (jailbroken devices)
  • Questions about why they get a message about “Sandbox Account” when they try to purchase (jailbroken devices)
  • Questions about why the in-app purchase apparently did not register on their device
  • Questions about how to restore the purchase if they load the app onto a different device
  • Questions about why they are told they have to purchase the original app before they can buy the in-app item
  • Questions about why the in-app purchase items are not free to them, given that they already paid for the app

And then there were more issues relating to the trial, rather than to the purchase per-se, for example:

  • Questions about exactly what the new features contain, after their trial has finished
  • Questions/complaints about why they have lost trial features they believed were part of the standard app

Reason 4 – Users who don’t/won’t pay for the in-app purchase can still leave a bad review about it

In my own case, this is the hardest one to deal with – and should give other developers plenty of pause for thought.

Apple has gone to some lengths to tidy up the user review system, and it has certainly improved a lot since the early days. However, there remains a glaring hole in the system – although users can no longer leave reviews for apps that they haven’t purchased they can still leave reviews relating to in-app purchase items that they have not (and obviously will not) purchase.

In my own case, most of the bad reviews are apparently due to misunderstandings by the user about the nature of the in-app purchase. Some people obviously thought that they were losing what they had previously paid for, and had to pay again just to keep the app.

Of course I have to take responsibility for any lack of clarity in how the in-app purchase has been presented to the user, and I have indeed attempted to tweak this. I suspect that the worst reactions have come from people who for one reason or another, did not see the message that appears at the start of trial, explaining what was happening, after which they assumed that the trail features were theirs to keep. I’ll continue to work on this, and this might help, but the basic issue will remain as a major potential problem for anyone implementing in-app purchases, and wants to maintain a strong app rating in the store.

Reason 5 – Some users have the impression that all app “upgrades” must be free

Quite apart from users who misunderstood the trial and in-app purchase structure, there are also a number who simply seem to feel entitled to any additions to the app for free, perhaps having misconstrued Apple’s free update system as meaning that all types of app updates in functionality must necessarily also be free.

In a way it a compliment of course – the fact that they are so upset about not having the extra functionality must mean that they really do want and value it. However, the fact remains that these people also leave bad reviews, and there is no shortage of others who find those bad reviews “useful” and vote accordingly, thus pushing them to the top of the review list.

In Summary

In-app purchase may well be a useful and rewarding system for some developers and for certain types of apps, but it comes with some disadvantages, not all of which are immediately apparent. In particular, if you have a high profile/high visibility app which relies heavily on having good user ratings, you should think carefully about the possible drawbacks before you add in-app purchase to it. So now I’ve warned you. The rest is up to you. Good luck!

Sun Seeker is Finalist in 2009 Best AR App Award

I have a vague memory of Sun Seeker having been nominated for something at some point… but then obviously forgot all about it. But today I received an email telling me it is a finalist in the “2009 Best App Ever Awards” in the category of Best Augmented Reality App.

I’m guessing that it wouldn’t have reached this stage without some people having decided that it was a worthy app, so this much is gratifying in itself. But if you have any inkling at all to offer some support for the public vote, please feel free to use the following link to place a vote, and augment the app’s chances against some of the other very high profile contenders. 🙂

Vote for
Sun Seeker: 3D Augmented Reality Vi…
Best Augmented Reality App

This is especially pleasing to me because I have found that most people (at least initially) don’t seem to understand what the app is useful for. But when they do finally get it, the response is of course much more enthusiastic.

BTW – I’m still intending to do much more with AR, and hope to be able to report on my progress later.