Oz Weather HD Update

Oz Weather HD for iPad has just had an update approved by Apple (4 days waiting for review, 3 days in review). [iTunes link]

The app reached #2 ranking in the Australian app store for paid iPad apps for two days last week. Since then it has drifted down to about #8. But I suspect that all we need is a really good dose of “bad” weather in a few capital cities to send it back up.

The enhancements are mainly things that will appeal to “high-end” users ie. weather geeks like myself.

Firstly the weather warnings have now all been color coded, so that important and relevant warnings stand out much more clearly than before. Typically most warnings are for coastal and ocean winds, which are only relevant to sailors and coastal dwellers. These marine are now shown in blue, whereas those relevant to land are shown in yellow, or red for severe warnings, storms and cyclones.

Secondly the Local Stations map view now has a new “Synoptic” view which shows traditional station wind arrows indicating wind direction and speed, as well as temperature and humidity where those data items are available. This really helps to get a sense of what winds are doing in the local area – especially helpful for people who do water-based sports, for example.

• Each weather wind arrows has a circle as its head, showing the actual location of the observation on the map, and a tail with feathers on it.
• The tail is drawn towards the direction from which the wind is coming, so that the arrow effectively points in the direction in which the wind is blowing.
• Therefore, if the wind is northerly (coming from the north), the tail is drawn on the northerly side of the location circle.
• The feathers on the tail indicate the wind speed. A long tick indicates 10 units of windspeed, and a short tick indicates 5. A filled triangle indicates 50 units.
• The units used depends on your choice of windspeed units in the app settings. For example, if you have chosen kmh, then two large and one small feather ticks would indicate 25kmh.

Thirdly there is a new “State Temperatures” map view. Although it is intended mainly for viewing the latest regional or state temperatures, in fact it displays all recent temperatures around Australia as a whole. The temperature labels are color-coded by temperature on a sliding scale, so wide-scale temperature patterns are easily visible at a glance. Check out the chilly alpine weather in the following screen-shot showing Melbourne, eastern Victoria and southern NSW (10:30am, 18th July 2010)!

Oz Weather HD

Oz Weather HD is an iPad only version of Oz Weather. I’m delighted to announce its approval and release by Apple today, after an impatient 8 day waiting period.

It contains all of Oz Weather’s features including the pro level ones, in a much more accessible way than is possible on the iPhone’s limited screen size. The larger screen size has also made it possible to present many of those features more attractively than on the iPhone as well.

This app has been a long time coming – I would have liked to get it out there much sooner, but was earlier pre-occupied with updating other apps (Sun Seeker and See Breeze) to work as universal binaries (ie. on iPhone and iPad), not to mention also releasing a brand new iPhone app called Moon Seeker, which is a lunar calendar, compass, and augmented reality position finder.

After much agonizing over the design of Oz Weather HD, and several false starts, I’m really pleased with the way it has finally turned out. My criterion for a good design is one that I get a warm feeling every time I run the app and this is certainly true of this one. I can only hope that lots of others get the same buzz out of it! The crux of this design is the inclusion of some of my favourite cloud & weather photos as backdrops.

Here are a few screen shot thumbnails:

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.

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…
in
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.

Yet Another Dubious App Rejection Story

As alluded to in a previous article, I have created an app with augmented reality capabilities, using Apple’s new camera overlay API calls which were first introduced in the OS3.1 SDK beta.

Given that “augmented reality” has caused such a buzz, I was of course keen to try to get it published as soon as possible. I noted that a number of other developers had already submitted apps which used camera overlays and yet were OS3.0 apps, and that some of them had been accepted into the app store, despite the widespread suspicions that such apps must be using private API calls to achieve this – something that Apple explicitly forbids.

But I didn’t want to risk raising the ire of Apple by trying to sneak through the cracks of the review process. After all, I depend on them for my living, and on the whole they have been very supportive of my efforts – for example by featuring Oz Weather prominently and repeatedly over the course of many months, which has kept it in the top 20 paid apps in Australia for much of the time.

So having more or less completed the app some time ago using the OS 3.1 beta, I dutifully waited for the final release of OS3.1 SDK, which upon arrival I promptly downloaded, verified that my app worked correctly with it, and then re-built and submitted it via iTunes Connect. That app submission was on 10th September.

Of course, as usual, I then had to sit back and wait for my app to reach the front of the queue and be reviewed by Apple’s team. The first and only sign you get that this has happened is to get an email either approving or rejecting your app. This arrived on 23rd September ie. 13 days later. And of course it was a rejection.

The Reason for Apple’s Rejection

Although I have previously made at least a dozen app submissions (new and updates), only one had ever been rejected, and that was due to a crash that occurred during Apple testing, so a fully understandable rejection. But this rejection was different. The reason given was as follows.

Thank you for submitting [redacted] to the App Store.  Unfortunately it cannot be added to the App Store because it is modifying or extending an undocumented API, which as outlined in the iPhone Developer Program License Agreement section 3.3.1 is prohibited:

“3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.”

There is no documentation for the custom subclasses or self-contained views of UIImagePickerController in iPhone OS 3.0.1.  This includes PLCameraView and its custom subclasses (PLImageTile, PLRotationView, PLImageScroller, PLImageView, PLCropOverlay, PLCropLCDLayer, TPBottomDualButtonBar, TPPushButton and TPCameraPushButton).

Additional Camera APIs are now available in iPhone OS 3.1.  Please review these new APIs to see if they meet your needs.  If any additional APIs are desired, please file an enhancement request via the Bug Reporter, <http://bugreport.apple.com>.

So apparently they were rejecting it because they believed I was using UIImagePickerController in an illegal manner under OS3.o. Huh?

My Denial

Well of course the app was doing no such thing. I had gone to considerable effort to ensure that I was conforming fully with Apple’s rules, and the app was compiled with OS3.1 as its base SDK. But… I am guessing that my “mistake” was to try to ensure backward compatibility, with a graceful and  minor degradation of capability for those still running OS3.0.

What I had done was to set the deployment SDK target to OS3.0, so that the app could also run on devices with the older OS3.0, but avoiding any use of the UIImagePickerController in that case. The reasons for doing so were

1. The camera overlay view is not essential for the app to be useful – the OS3.0 view with a plain background still gives a good 3-D “augmented reality” perspective which is more than adequate for the type of data being presented by the app.
2. If users upgrade from OS3.0 to 3.1 (a free upgrade anyway), then the camera view will become available to them without needing to obtain a new or upgraded app, so it should serve simply to encourage the OS upgrade.

So to re-iterate – the app was NOT using any private API calls, under ANY circumstances.

I can only assume that the tester/s jumped to the erroneous conclusion that it did so because they did not read or understand my app description (in which I explained the app’s difference in behaviour on OS 3.0), and/or that they did not test it on OS3.0 as well as on OS3.1.

The above is essentially exactly what I explained to Apple in my emailed response to their rejection notice, and I asked them for confirmation as to whether or not they were maintaining their rejection, and if so whether recompile the app to run on OS3.1 only would be required.

Apple’s Further Response

I am pleased to say that it was less than 24 hours before I heard from Apple again – this time via a phone call from the USA. However, the bad news was that Apple was requesting me to resubmit the app for deployment only on OS3.1. Of course I queried why this was necessary, given that I was not using any private APIs, and the (polite) response I got was that, for the sake of the approval process, it would simply be necessary for me to make this change. With hindsight, I should have pushed for a more detailed justification, but being on a crowded and noisy bus, and not sensing that any negotiation might be possible, I agreed to make the change and resubmit.

The Status Quo

So, despite the fact that Apple’s rejection was justified with spurious reasons, the situation now is that I have resubmitted the app for deployment only on OS3.1.

The main question I have now, of course, is whether or not I have gone to the back of the queue once more, and will likely therefore have another two week wait. I’m not holding my breath – I’m betting on at least another two weeks.

The saddest part of this story, of course, is that it is just one of many weird and wonderful rejection stories. I’m not going to dump on Apple, because there are some great upsides to working with them, but I have now joined the ranks (throngs?) of those who find whole app approval process somewhat arbitrary and disempowering.

If Apple does have any formal rules and guidelines, why can’t they let developers know what they are? Why can’t they have an arbitration or escalation process for those who rejections appear to be based on dubious grounds. And why oh why can’t we know exactly where our apps are in the queue?

New Appstore User Review Flaw Emerges

Apple has recently made major improvements to the user review system for apps, making it generally much fairer and more useful to customers.

Reviews are now labeled with the date on which they were written, the version of app being reviewed, and there is a graphical view of the distribution of ratings, making it much easier to see the overall response of users to the app.

But there are still some ways in which the system can be abused or gamed, as I have only just discovered myself, after noticing that despite Oz Weather’s typically high user review scores, the 3 reviews shown to all users on their first view of the app information (in the Australian app store) happened to be 1 and 2 star reviews, with correspondingly negative sentiments.

The reason that these unrepresentative reviews are being shown persistently is because Apple considers them to be the “most helpful” ones according to the algorithm that they apply to their peer review system ie. where users rate other users’ reviews.

But closer examination showed that those particular reviews had received feedback from just one other user ie. they were marked with the statement “1 out of 1 customers found this review helpful“. And looking down the list of 31 reviews of the current version it was apparent that the low ranking reviews had all been found “helpful” by 1 out of 1 users, whereas all the high ranking reviews (many more of them of course!) had all been found helpful by 0 out of 1 users (ie. found “unhelpful”).

Given this pattern, what’s to bet that all this was the work of just one person?

Most disappointingly, a review I left myself was similarly marked as unhelpful, thus making it virtually invisible to most users. I had left this for the purpose of trying to help those users who had app problems but not realised they could just email me for support. And in it, I clearly identified myself as the developer. (As I had to leave a star ranking, it had to be 5 stars – what would user’s have thought of the app if it’s own maker had ranked it less?!)

This problem with user reviews of reviews has been there since day one of the app store, but due to the fact that numbers of users, their reviews, and their reviews of other reviews was always growing, it wasn’t a big issue for long. Once enough users had been acquired, the chance that a single user’s feedback could affect things this dramatically became negligible.

But with Apple’s new review system in place, whenever any app update is issued, the reviews for the current version only start at a count of zero, and the prospect of this distortion and/or possibility of gaming the review system by just one (or very few people working together) arises again, at least until the number of user reviews has grown enough to drown it out again. Given that many app developers do release updates relatively frequently, this makes it into a real issue – one that happens to have been made much worse as a consequence of the new review system.

So how could this be solved? Well Apple has already solved a similar issue in relation to the average star rating ie. they no longer give a star rating at all until a sufficient number of reviews have been received. So perhaps the solution is simply to ignore the helpful/unhelpful ratings until a sufficient number have accrued – at least several, preferably more.

Another approach would be to limit the number of helpful/unhelpful ratings that any one user can give – thus preventing them from sullying the entire complement of existing reviews in one go, as appears to have happened to Oz Weather in this case.

Yet another would be to look for patterns of user response eg. if a user consistently rated all low star reviews as helpful, and high star reviews as unhelpful (or vice versa), then their ratings are simply ignored. Of course this might require some advanced algorithms to make it work, which may be unrealistic for now, but it doesn’t hurt to think about them!

Appeal

Because a solution to this issue is not going to be implemented or appear overnight (despite Apple’s many other talents!), I would like to appeal to any existing Oz Weather users to go into the Oz Weather app store entry in iTunes (you can use this link) and use the helpful/unhelpful feature to rate some of the existing other reviews. I would ask you to do this with integrity and honesty ie. please don’t just do it for the sake of panning the bad reviews or glorifying the good ones – rather do what feels right and appropriate to make the review rating more realistically representative of your own opinion of the app.

Postscript

By the way, those bad reviews on the front page are no-doubt quite honest. The app can (rarely) start crashing, and the only solution is to delete then re-install the app, and I do believe that it is very important to listen to complaints, and think carefully about what you could do to avoid similar complaints in future.

To this end, I have recently rooted out the likely cause of any crashing, and also put in a crash recovery mechanism just for those 1 in 10,000 type scenarios. Hopefully this will mean that eventually there will be no 1 star reviews at all – and then it wouldn’t be possible for anyone to game the helpfulness of reviews either! What? Me? An idealist? Well maybe.