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

Turbulence in the App Store

Oz Weather usually provides you with all the latest Australian weather information, but today is a little different. Oz Weather has itself been experiencing some app store weather – and its been a bit rough.

Background

Oz Weather has so far been a very successful iPhone app in the Australian app store. You can read more about it here.

But this particular story started with an app update to Oz Weather.

Because I wanted to add many new features, I had been thinking about creating a new app altogether, and perhaps calling it Oz Weather Pro and of course charge a bit more for the extra features and work that had gone into it. But the problem with doing this is that Apple offers no upgrade route between apps. Consequently existing users of Oz Weather would have had to pay just the same as any new users, and that to receive a partial replication of the features they already owned and had paid for before. I thought that was hardly fair to all those customers who had so enthusiastically supported the app since its launch last year, and other developers who had done that were panned for it.

So I carefully devised a plan which would ensure that no existing user would be disadvantaged at all. And what’s more I thought I would attempt a little tried but oh-so-frequently requested feature – a fully working, but time-limited trial of the new features before you decide whether or not you want to pay for them via in-app purchase.

I was encouraged by the fact that some others had indeed already attempted this, and actually had their apps approved by Apple (eg. the Palettes app). All I had to do was implement it all.

This did turn out to be a bit trickier than I first thought, but I did manage to solve it all, and I may write a little more about that in a future post.

Planning the Release

Before releasing the app, of course I carefully reviewed what I had done in light of Apple’s approval process. I was keen to get the app approved before Christmas, so didn’t want to risk a rejection after two weeks, which then leads to at least another two week delay after a re-submission. Once thing that particularly concerned me was that one of the new features used the camera overlay API call, which was introduced in OS3.1. My concern was realistic, as it was based on the fact that the Sun Seeker app was initially rejected precisely due to this API, as a result of  the fact that I had provided backward compatibility for OS3.0 users. Even though doing this is within Apple’s guidelines, and is even recommended by them, it was rejected anyway, supposedly for “forbidden” use of camera overlay. I also took a quick poll about this issue on twitter, and the general consensus of other developers was that it would be risky to do this, and even though perfectly legitimate in practice, was quite possibly still going to be rejected.

From previous usage statistics, I estimated that about 25% of existing Oz Weather users would be excluded from an update that worked only with OS3.1+. However, I reasoned that there was nothing to stop me submitting a further update which re-introduced backward compatibility with OS3.0 after the initial OS3.1 update was approved. In that case, if the backward compatibility issue still resulted in rejection at that point, the initial update would of course still remain available to 75% of OS3.1 users.

So I took the executive decision, for the sake of quickest possible approval, that the update would have a deployment target of OS3.1+.

The Release

Dec 10th, 10am – I was notified of the approval. The review and approval process had taken 12 days – par for the course at the moment. I was relieved that it hadn’t been rejected, and delighted it had happened well in advance of Christmas. For a while, I felt quite contented.

Dec 10th, 11:30am – Received an email from a user saying that although iTunes had notified them of the upgrade to v2.0, when they downloaded it it still appeared to be the old version (1.7.1), even after several retries. How odd, I thought! I was puzzled, but reassured the user that it was probably a server caching issue, and it would probably resolve itself later.

Dec 10th, 1:30pm – By now I had received 10 similar emails. I created a standard reply, suggesting that they contact Apple to report the problem. I was quite concerned because it would be unusual for more than 1 in 100 users to contact me directly, so there could be thousands of users with this problem. And of course they would all be assuming it is an Oz Weather fault.

Dec 10th, 7:20pm – By now had received about 40 similar emails, but suddenly my server started showing that many users were starting their trial – at the rate of about 10 per minute, indicating that of course the correct new app update version was now being served to them. Phew, I thought! Glad to see the back of that problem!

Dec 11th – One of the users who had contacted me yesterday was reporting that he now had the new version, but that it was crashing on startup. I had several email exchanges with him to try to get to the root of the problem, and by incredible good fortune, he was expert enough to be able to follow Apple’s instructions on where to find a crash log, and sent it to me. Within seconds of opening the log file I saw the problem. His device was running OS3.0, and a 3.1 deployment targeted app can simply do nothing but crash on an OS3.0 device. But how on earth did he manage to get an OS3.1 app onto his OS3.0 device?! iTunes controls that! Uh oh! My heart really started sinking at that point.

No doubt, I realised, this must be linked to the fact that iTunes was initially serving all these users with Oz Weather v1.7.1 – which was an OS2.2 targeted version. What if iTunes had based its list of customers to serve the update to was based on v1.7.1, and NOT on v2.0? That would explain this user’s problem. And it would also suggest that the problem might be much more widespread. Uh oh! My heart sank even further. And yes, iTunes was already showing a series of very recently posted one star reviews, complaining that the app crashed on startup.

My life flashed before my eyes. One star reviews?! Every developer gets them of course, at least once in a while. You can never please all users. But suddenly I was getting a constant stream of one star reviews from irate users – and it was all totally beyond my control, due to some weird Apple server glitch. And this kind of avalanche of negativity could probably kill an app quicker than the blink of an eye! And this app is my lifeblood. Of the various apps I have created and worked on, this is the one that truly supports me, and makes it possible for me to continue my “career” as an independent developer.

I fired off an email to Apple dev support, requesting assistance and pleading the urgency of the situation. Later I sent another email to a local Apple marketing rep, pleading urgency and lack of response from dev support. To his credit he responded promptly that he had forwarded the issue to the USA. However, even now, three days later, I have still not had any further response from them.

Dec 12th – Now, to make matters worse, a number of users (who obviously had OS3.1 on their devices, and therefore had no problem running the update) were leaving very negative reviews about the in-app purchase.

I was aghast. I had really gone out of my way to find the fairest possible system, which disadvantaged not one user, which offered a free 7-day trial of all additional features, and which even offered enhancements over v1.7.1 to those users who did not want pay for the new features. And yet I was being blasted for it. Many users latched onto the term “double dipping”. But how can it be double dipping when the user doesn’t have to pay for anything they don’t want to, and even if they have just got more functionality than they paid for in their original version anyway? The only explanation I can find for this is that these people had either not read, mis-read or just misunderstood my explanatory words about the trial and in-app purchase system. Perhaps I just hadn’t made it clear enough?

After a while I began to notice a bit of a pattern. There seemed to be a link between the app crash complaints and the in-app purchase complaints. It was as if they were fueling one another – scathing one star reviews cross pollenising one another in a kind of feeding frenzy – along the lines of “wow this guy wants to double charge us for an app that crashes on startup!”.

This really looked terminal. How can an app recover from this? What was the chance of Apple actually removing any of the reviews that erroneously blamed Oz Weather for the download and app crash schemozzle? And even if they were to do that (which would be completely unprecedented as far as I know, and hence extremely unlikely), would they also remove reviews referring to the in-app purchase which had been influenced by the crash reviews? And for that matter, why is it that users who haven’t and obviously won’t use the in-app-purchase be allowed to leave a bad review for the app supposedly based on their disapproval of the in-app purchase being offered, at all?

So what could I do now? The first step was to quickly submit a backward compatible 3.0 version, and submit a request for expedited review. Fortunately this was a very quick step, because I had already expected to be submitting such an update very soon, as explained earlier. And if approved, and providing Apple’s servers didn’t mess things up again, that would at least allow 3.0 based users (currently with what appears to them to be a dud app) to actually get it working. But it wouldn’t help anyone using OS2.2. And perversely, it would also no doubt appear to users as if I had submitted a new app update because the previous version was itself faulty – rather than the reality that the update was being submitted principally to help work around Apple’s server mess-up. And hence it would implicitly appear as an admission of fault/guilt on my part, thus appearing to vindicate all the reviews that misguidedly chastised me for having submitted a “faulty” update in the first place.

Another step was to recommend that users upgrade to OS3.1, as presumably this would also remedy the app crash. But of course only a small proportion of victims of the crash would actually contact me about it, so this wouldn’t reach many. So I decided to edit the app’s description in the hope that at least new users would be able to see my explanation of the reason for the slew of terrible reviews. And then in yet another quirky twist of fate, very shortly after I had done this, Apple suddenly started deploying a new app store layout, and all of a sudden most of the app description was hidden by default.

Sometimes you have to wonder, when so many coincidences stack up against you, whether you are simply fighting a losing battle. So that was when I started thinking about pulling Oz Weather from the app store altogether, at least until some real solutions emerge. Wow, that seems so drastic. A bit like cutting off your own leg to save your body after you get crumpled by an avalanche. But what exactly would the consequences of this be? Would any existing users be disadvantaged eg. would the in-app purchase become unavailable, for those existing users who did actually want to have the new features? If so, that would be making things even worse.

Despite all this, and helping me to keep things in perspective, there were still people leaving five star reviews, who obviously did really appreciate the new version and features, had not experienced Apple’s server glitch (or at least had understood that it was a temporary Apple issue), and had not misunderstood the in-app purchase system. And in fact some reviewers were obviously going out of their way to counter the negative reviews. So my faith in human kindness has not been lost. (If any of you are reading this – thank-you!)

What Next?

At time of writing (Sunday 13th Dec 2009), I have heard from Apple via the automated iTunes Connect system that they will provide an expedited review of an app update (v2.0.1) I submitted two days ago, which provides backward compatibility for OS3.0 users. This is something that they occasionally do when a developer requires an urgent update – usually of course due to bugs in their own app rather than due to an Apple problem. However, this will not help any pre OS3.0 users who were served the app update by Apple. According to my own analytics, this means that up to about 1000 users could still have an app that will not run, even after (and if) Apple approves this new update.

How on earth can that problem be fixed? Does Apple even have the ability to restore the older version to those users? But apart from that automated reply from iTunes Connect, I have not had any response at all to my pleas for help to Apple’s advertised email addresses for developers and iTunes Connect users, and I am not even sure whether or not Apple is *still* serving the existing Oz Weather update to users running older OS versions. (I am assuming that they are not, because the flood of emails has decreased, but I cannot be certain.)

And even if and when Apple manage to remedy that problem, what about all the negative reviews that Oz Weather has acquired due to Apple’s glitch, and the consequent loss of sales and rankings – possibly permanent? Having a new app upgrade will of course relegate those reviews to the pool of reviews for non-current versions, but my observation is that irate users can and will update their bad reviews whenever new updates come out, anyway.

The iPhone device, its SDK and the app store environment have provided me with a fantastic creative outlet, and overall it has been very gratifying and rewarding. But right now its is all feeling a bit tenuous. There seems to be little I can do now but wait for Apple to do something. Or nothing. Judging by past experience I should certainly not be holding my breath.

Oz Weather Apponomics – Birthday Edition

This is the latest installment tracking the progress of the Oz Weather iPhone app in the iTunes app store. (Part 7 installment here.)

Oz Weather v1.0 arrived in the app store on 1st November 2008 (now at v1.7.1), so I now have a full years of stats to share with you.

• Total paid app downloads: 64,500 (176 per day on average)
• Net app revenue: AUD$99,600 (US$89,700) – net of 30% Apple share and 10% Australian GST
• Average User Rating: 4 stars – from 1187 ratings of all versions
• Average ranking: 17.5 – in Australian app store

[Stop Press - AUD$100k sales were reached on 3rd Nov 2009]

The following graph shows a complete history of one year’s worth of daily sales records.

The associated Australian overall paid apps ranking is as follows:

So there have been a number of peaks and troughs. The single biggest factor causing those peaks and troughs appears to have been Apple promotions in the Hot / New / Staff Pick lists. But this has worked both ways – the biggest troughs have occurred when Apple has promoted competing apps.

The second biggest factor has been the weather itself. In Australia it seems that people are more interested in summer weather than they are in winter weather, hence causing an underlying annual cycle which peaks in summer (Dec/Jan/Feb) and troughs in winter (Jun/Jul/Aug).

Some individual weather events (eg. extreme heat waves, major rainfall events) seem to account for much shorter term peaks – especially noticeable around Feb 2009 when a major app update was also released.

Its also worth noting that during the course of the year the number of competitors has grown substantially. No doubt other developers have noticed how well weather apps seem to do in the app store ecosystem, and I would guess that my blogging about such attractive sales figures has probably encouraged some of the new ones into the game too.   However, most of the newer competitors have failed to get any significant visibility, at least so far, and overall I don’t regret my decision to be transparent and open with my sales figures. I am always delighted to read about the inside stories of other app developers’ successes and failures, and hope that my own story has been interesting and useful to others too.

Sun Seeker – What is it Good For?

There have been quite a few news and blog mentions of Sun Seeker since it’s release (described in this previous post), which has created some good interest in it, and yes, some good app sales too. But a common reaction of press reviewers seems to be to question what you would use it for. I have to say, frankly, that I am a little surprised. How could you not immediately understand how useful this app really is?!

But then it dawned on me (whoops, no pun intended!). We are not all born the same. Some of us do seem to have that extra geek gene, which means that some things which seem really obvious to us are pretty much obscure to others. And vice-versa of course, as I know all too well, often to my own detriment.

Thankfully, however, some of those who bought the app do already “get it”, and a few kind souls have left some great comments explaining exactly how they find it useful – and some of these are in ways that I had not even imagined myself. As these comments are spread around different countries’ app stores, I thought it might help to list a few of them here. I have added highlighting to various words and phrases to emphasize the types of usage people are using it for.

I bought this app to track the suns position on the cockpit window during my trips as an airline pilot, this app works better than I had hoped. I now use this app as a situational awareness tool, keeping track of possible solar glare on final approaches to particular runways. It works awsome in the virtual 3d view because of the slaved compass I can find the suns relative position with reference to any runway. This is really a great app. (Lwm5 – USA)

Fantastic – shows the true utility of augmented reality apps. As an architect I have been doing solar analysis of sites by printing solar charts, taking pictures and noting bearings & altitue of horizon (trees mnts structures etc) – then combining info in Photoshop. With this app it’s as easy as pointing the camera to get a sense of the solar access of a site at different times of day / year. (smh_iTunes – USA)

I work in the Solar industry and this works exceptionally well for aligning solar arrays and showing customers the path of the sun. GREAT app (Clear James – Australia)

The perfect app for DOP’s Gaffers and anyone that needs to know where the sun path will be and where you will lose the sun behind a building etc. The augmented reality is flawless and helps anyone plan out a photo/film shoot to the hour. A steal at this price. (Metromadman – Australia)

It might also be worth noting that, currently, the best sales of this app are being made in… Japan. How fitting, given that it is sometimes know as the land of the rising sun!

Currently Sun Seeker is #6 in paid apps in the Navigation category, there. I’m guessing that this might have something to do with the fact that Japanese are known for being early and enthusiastic adopters of new technology. This helps in two ways – firstly because there might be a strong uptake of the latest 3GS iPhone model (required for this app), and secondly because the area of augmented reality is so new to the consumer space, and offers exciting new ways of using the technology, which may not be immediately obvious to those more reluctant to embrace unfamiliar technology.

Now why can’t Westerners be more like the Japanese?

So until next time – Konichiwa!

Sun Seeker – Seeing the Light with Augmented Reality

I am pleased to announce that my new app “Sun Seeker” was approved by Apple on the second attempt, 31 days after the initial submission, and is now available in the iTunes appstore. Note – As it requires use of a compass, it will only work with the iPhone 3GS devices.

I have recorded a brief video demo showing how it works.

This app shows you where the sun is now, and what path it takes through the sky, either for today or for any day of the year, for your current location.

It has two main views.

• A flat compass view
• An augmented reality camera overlay view

It is valuable for real estate buyers (to find the sun and light exposure of any room throughout the course of the year), for gardeners and landscapers (to find hours of sun exposure for any location in the garden), for photographers (to find when the sun will be shining at the right angle), and for anyone interested in daily variations of rise and set times of the sun.

The above shot shows the opening view – which displays the sun’s day/night path segments using the flat compass. Typically you would hold the iPhone horizontally in your hand, and then you can easily see the directions of the rise point, set point, and which direction the sun is in right now – the yellow triangle. The other information displayed here is:

• Current latitude and longitude (from built-in GPS)
• How long since the sun rose, and until it sets; or if at night, how long since it set and how long until it rises
• The sun’s heading (azimuth) angle and elevation. If you watch these you will see them ticking over as the sun moves.
• Shadow ratio (length of shadow in comparison with the vertical height of a an object) and path length (the multiple of atmospheric thicknesses through which the sunlight has traveled).

Tapping the camera icon changes the app into its augmented reality overlay view.

The types of information you see here are:

• If the sun is not already in view, then a pointer showing which direction to turn towards to find the sun
• The current heading (azimuth) and elevation of the centre of your camera view
• The sun’s current position and its opposite shadow point
• The sun’s path throughout today with hour positions marked – including the nighttime segment below the horizon
• Optionally also in blue the sun’s path on the shortest day of the year, and in red for the longest day of the year
• Grid lines of equal heading (purple for cardinal compass directions E/S/W/N and red for others) and elevation (blue)
• The horizon line (green)

You may find this especially valuable if you look towards the rise and set points near a room’s window or on a balcony. You can then see the range of directions through which the sun rises (or sets), and therefore when it will shine through that window or onto that balcony, and for roughly how many hours at different times of the year.

Further details you can obtain are shown in the following view.

So you can see that this app uses augmented reality a little differently from most other newly released apps, and it can provide genuinely valuable information that is not easily available by any other means. It effectively turns your iPhone into an advanced sun tracking device.

I created this app because I was myself in the process of buying property, and it was just what I needed myself.  I hope that some of you might also find it useful, as well as fun to use and to show off your iPhone!

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?

Geotagging and Augmented Reality – New Standards Needed?

Augmented reality (AR) apps are all the buzz at the moment, and they do offer some exciting possibilities. In fact I have already created an iPhone app using certain AR techniques myself, and intend to submit it to the app store as soon as Apple will permit it. More later.

However, whilst considering some of the implications of using AR, I was surprised to find that current geotagging standards don’t seem to be on a par with what AR technology permits. There is definitely scope for extending the current standards, and its seems very likely to me that demand for this will grow rapidly from now on.

In its simplest form, geotagging is simply a means of tagging a piece of data (such as a photo) with a latitude and longitude, and thus allowing data to be mapped or accessed via locational search.

An implicit assumption (given that it is called geotagging) is that the data is associated with a point on the earth’s surface, whatever the altitude of the surface might be at that location, in which case an altitude is not strictly required, because the earth’s topography can be assumed to be reasonably constant and knowable via other sources. But what about the case, for example, when a photo is taken from an aeroplane? In that case, altitude would be an additional parameter required in order to correctly differentiate it from a photo taken on the earth’s surface. Given that GPS systems typically record altitude, it is hardly a stretch to include it as  standard additional tag item.

And going further still, given that augmented reality devices measure spatial attitude of the camera, would it not make sense to enable any photo taken to be tagged with the heading (aka azimuth) and elevation (ie. local horizon coordinates) at which is was taken, and further also with the camera tilt (eg. whether portrait or landscape relative to horizon, or any angle in between), and with angle subtended by the camera shot, both vertically and horizontally. It would be necessary to provide all this extra geotagging information in order to be able to correctly reproduce/model the exact “window” into space that the photo represents. Whilst this additional data might would be unnecessary for common scenic or portrait photography, it could be quite valuable in other situations. For example, two such fully (and accurately) geotagged photos taken of the same object from different locations would allow a 3-D reconstruction of that object to be created. This is not a trivial implication!

One of the existing geotagging standards (FlickrFly) also allows an additional item to be specified ie. distance or range from the camera to the subject of the photo, which presumably is necessary when a locational search is being done for the subject of the photo rather than for the location from which the photo was taken.

In order to avoid missing out on the possibilities that AR apps can already provide, and to be able to start constructing better, more powerful geolocational systems and applications which take advantage of this, I would propose that existing geotagging standards be extended to include all of the following:

• date, time, timezone offset (to provide instant in time)
• geographic latitude, longitude and altitude (to provide location relative to earth’s surface and mean sea level)
• camera viewpoint central heading (0°=N, 90°=E, 180°=S, 270°=W)
• camera viewpoint central elevation (0°=horizontal, -90°=vertical downwards, +90°=vertical upwards)
• camera tilt (0°=portrait/upright, 90°=landscape/top points left, 180°=landscape/top points down, 270°=portrait/top points down)
• camera angle subtended vertically (ie. along nominal top to bottom)
• camera angle subtended horizontally (ie. along nominal side to side)
• range of point of interest from camera (if there is a relevant POI involved)

I would welcome feedback on this proposal from anyone knowledgeable with the current state of geotagging. I am certainly not an expert in this area, but for those who have the capabilities to influence things in this area, I believe that there may be opportunities for valuable advances, especially in relation to the new generation of AR technology.