Archive for the ‘iPhone’ Category
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!
* * *
More recent news and discussion about Sun Seeker on Facebook:
More recent blog entries on Sun Seeker:
Note – Sun Seeker is now available for Android! (March 2012)
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?
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
- 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.
- 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?
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.
AdMob has just issued a report with some very interesting data on the app store, and one of their claims is that the app store market is worth about US$200M per month.
This is disputed as being an unreasonably high estimate by some commentators. However, with data I have gathered from my own app sales, I am in a position to make my own estimate too. So what is it? Well there are four steps.
Step 1 – Sales Versus Rankings
In an earlier post I showed a graph of sales versus rankings for Oz Weather in the Australian app store during the first few months of 2009. Below is an updated graph covering the sales period July/August 2009.
Although Oz Weather hasn’t ranked highly enough to provide data points within the top 10, it does still allow a good estimate of the curve as a whole ie.
Daily Sales = 1800 * Ranking ^ -0.8
Note that this curve is substantially higher than the 6 month-old estimate, showing a large increase in the overall number of app sales per day – of the order of a factor of 2 or more.
Step 2 – Find area under the curve to give total daily app sales
The area under this curve is the integral of the curve formula. With some high-school calculus, we might know that this is:
Area under curve = 1800 * (Ranking^0.2 / 0.2)
Solving this for the range 0 to 50,000 apps (the approximate number of paid apps available) gives the result:
52,000 app sales per day in the Australian app store
Step 3 – Multiply by average app price
Assuming an average app price of US$1.80 (AUD$2.25) the total daily revenue for the Australian app store alone is
- AUD$120k per day
- AUD$3.6M per month
- AUD $42.7M per year
Step 4 – Expand to whole Globe
I have previously estimated the Australian market to be about 1/30th of the global market size. However, the AdMob report indicates about 45M iPhone/iPod Touch devices worldwide, and previous research has implied about 1.1 million in Australia, implying a ratio of about 1/40. In that case, the corresponding global sales figures would be
- US$3.9M per day
- US$115M per month
- US$1,370M per year
Although there are a number of estimates and assumptions involved in these calculations, the final monthly number of US$115M per month, although less than AdMob’s estimate, only differs by a factor of a 0.6.
A more accurate estimate would be possible with a wider range of app versus ranking data – especially from the larger app stores like the US. However, I did previously collate some data like this, and it also supported a rankings/sales tail off with a power factor close to -0.8.
I conclude that my own app’s sales figures imply that AdMob’s estimates are very plausible, and certainly likely to be in the correct ballpark.
This is the latest installment tracking the progress of the Oz Weather iPhone app in the iTunes app store. (Part 6 installment here.)
The latest stats, to 4th August 2009:
* Total app downloads: 48,600
* Net app revenue: AUD$73,800 (US$59,000) – net of 30% Apple share and 10% Australian GST
* Average User Rating: 4 stars – from 885 ratings of all versions
The following graph shows a complete history of more than 8 months of daily sales records, since launch on Nov 1st 2008.
The associated Australian overall paid apps ranking is as follows:
I already explained the cause of the great sales dip in June in the previous post, but the other feature that stands out here is how the ranking in the latter half of the graph has been declining despite a fairly constant average base level of sales (excepting June). The obvious explanation for this divergence is that the total number of all apps being bought is gradually increasing with time as the number of iPhones/iPods in Australia has increased. Recent estimates by AdMob put the total number of iPhones in Australia at around 750,000 and iPod Touch at 350,000 – making a combined total of 1.1 million devices on which Oz Weather could be installed. This would mean that Oz Weather has been purchased by about 4.4% of Australian device owners.
This might seem to leave room for plenty more sales, but others have suggested that 3% is a high ownership rate for other popular apps such as “Flight Control”, so maybe we’re already pushing the boundaries!
The app store just turned one year old! And to celebrate, Apple have added a little promo page to iTunes, which you can find via this link on the iTunes store front page.
And here is part of their colorful celebratory page, created with Apple’s usual great design flair.
Apple have “gathered together some of our favourite games and apps“, and to my delight, Oz Weather is one of the 32 apps they have chosen to feature in their apps list – appearing there in 10th spot.
What caused me to discover this? Today’s sales jumped up by 40%. Although sales can be quite variable day to day, this change seemed to be a bit bigger than usual, and I wondered if there was some material cause. Having been tipped off, it didn’t take long to find it.
As usual I will be watching carefully to see whether this has an extended effect on sales levels, and report back in due course.
Amendment 20th July – it has been pointed out to me that this 1st birthday page had been in iTunes for a week already. So I can’t attribute the sales jump to this after all. Looks like I’m getting a bit lax in my iTunes monitoring!
This is the latest installment tracking the progress of the Oz Weather iPhone app in the iTunes app store. (Part 5 installment here.)
The latest stats, to 3rd July 2009:
* Total app downloads: 44,800
* Net app revenue: AUD$68,000 (US$54,400) – net of 30% Apple share and 10% Australian GST
* Average User Rating: 4.5 stars – from 6 ratings of latest version, 4 stars – from 790 ratings of all versions
The following graph shows a complete history of more than 7 months of daily sales records, since launch on Nov 1st 2008.
The associated Australian overall paid apps ranking is as follows:
The most immediately noticeable feature of these graphs is the big “crash” in sales and rankings starting at the beginning of June, and then the sudden recovery on 26th June. What could have caused these big changes in fortune?
- The Fall – At the beginning of June, Oz Weather’s main head-to-head competitor (Pocket Weather AU) was given “Staff Favourite” status in the Australian app store, which meant that it appeared on the front page of the app store with that endorsement. So at the same time that Oz Weather sales and rankings tanked, Pocket Weather sales and rankings took off. While Oz Weather reached its nadir at 68th ranking, Pocket Weather peaked at around 29th ranking.
- The Recovery – On 26th June, Apple launched the iPhone 3GS in Australia. Oz Weather sales tripled overnight and its ranking jumped from 60th to 20th, while Pocket Weather’s ranking remained much steadier, hovering around the 40th to 50th ranking range. My surmise as to what caused this is Apple’s in-shop promotions which include Oz Weather as one of the featured apps, and a demo version is pre-installed on some of their iPhone shop demo units. This means that new iPhone customers who visit an Apple store to make their purchase get well exposed to Oz Weather.
Interestingly, the cause of both the fall and the recovery are apparently Apple’s own promotional mechanisms, over which individual developers have (as far as I am aware) absolutely no control. Either you are picked or you are not!
Overall, of course, Apple’s influence has been much more of a benefit than a hindrance to Oz Weather, and I am of course very grateful for that. And I certainly do not begrudge the fact the Pocket Weather was given a staff favourite pick by Apple. Like me, they’ve put a lot of time and effort into their app, and deserve their day in the sun as much as anyone else.
Climate Eye, our third iPhone app was approved and is now available in the iTunes appstore.
It provides daily climate averages and weather forecast information for more than 1300 major cities & locations throughout the world. All data is supplied by official government sources of each respective country.
A special feature which differentiates it from other weather applications is that it shows how unusually hot or unusually cold each city is (ie. how far their temperatures deviate from the climate average for the given day). Thus you can see at a glance which cities are enjoying (or suffering from) unusual weather conditions.
The app design, which I’m sure will impress many, is by Peter Fellows of Pollenizer – the same designer who was responsible for Oz Weather‘s fabulous look. Although he apparently didn’t set out with this intention, the design has turned out to be classic steampunk (what we might have seen if the information age had overlapped with the steam age), complete with mechanical sounds and animations as the app opens with the blink of a mechanical eye, and different views roll into place.
Want to know more about steampunk? You know you do! Here’s a great Youtube video on the topic.
The more things change, the more they stay the same. It used to be doctors, lawyers and clergymen. Now its our turn. Geeks FTW!
Source: The Australian Financial Review newspaper, May 30th, 2009.
I was contacted by Australia’s ABC TV late last week, as they were interested in compiling an article about iPhone development for their Midday Report news and current affairs show.
As usual, the initial focus was very much on how lucrative app development could be, especially for independent developers. Thankfully, though the article turned out to be quite balanced, and also featured Keith Ahern of MoGeneration Pty Ltd, who started up a now-thriving mobile development business, centered around iPhone apps.
Of course the interviews always end up as a compilation of brief sound bites from much lengthier interviews, but I thought they did a good job of weaving it all together. Well done ABC!
Special bonus to anyone who can name all the members of the Pollenizer crew who appear to be working very, very hard despite the TV lights and cameras, at around the 1m07s mark.