Everywhere – Timezones, Holidays and Current Weather

Another app is born. 🙂 This one has the potentially grandiose title “Everywhere“. But in fact that is exactly what it’s about! This app keeps you in touch with the world.

At a glance, you can see

• Current local time
• Timezone
• Current temperature and weather
• Next forthcoming holiday

You can create a list of any locations  that interest you – for example, where-ever your family, friends, colleagues and business associates live and work.

And as an additional tool to help you work out the crazy timezones of this world, it offers a fantastic scrolling full-screen visual zone comparison table. So no longer any need to accidentally call your uncle when it’s 3am in his part of the world.

And along with the time is a color-coded time-status that indicates, again at a glance, whether each location is in normal working hours, normal waking hours, nighttime hours, or public holiday hours.

In fact this app is not entirely a new creation – it has heritage (and pedigree!), being a re-incarnation of a much older Windows app called ZoneTrekker, which had the notable achievement of having had the Pentagon, no less, purchase a site-wide multi-user license for it. That harks back to the days when I made my living as a Windows desktop app developer. But with such an illustrious past, I felt it was time to re-birth the concept as a mobile app – so now here it is as a universal iOS app – and in fact much nicer than the original in a number of ways!

App Screens

App Guide

Key to Colors

Color-coding is used in various places in the app to indicate time status, for the location in question. The colors are:

• ■ Light Blue – normal working hours (9am to 5pm)
• ■ Dark Cyan – non-working but waking hours (7am to 9am, 5pm to 10pm)
• ■ Dark Green – night-time or sleeping hours (10pm to 7am)
• ■ Pink – public holidays waking hours (7am to 10pm)

Editing Locations

• To add a location, tap on the + button, and type in a city name.
• To delete a location, tap on the Edit button, and then on the – button at the left of the cell.
• To re-order locations, tap on the Edit button, and then drag entries into the desired order using the drag-bars on the right of each cell.

Holidays List

• To see a list of the current and next year’s holidays for a given location, tap on the ellipsis on the right hand side of the cell.
• Note that public holidays are shown with Pink, whereas “observances” which are not usually taken as public holidays are shown with Dark Cyan.

 

So there is is! Now what are you waiting for? Go and get it!

Advertisement

Indie Mac and iOS Developer Influence Rankings

Here is an interesting take on just who are the most influential indie Apple developers, using a tool for ranking people’s influence in their particular field, based on twitter and website stats.

It was developed by Ross Dawson, who first used it to rank KeyNote Speakers. You can find out more about the algorithm it uses from his detailed and fully-transparent explanation of how it works.

As a result of my special association with him (yes, he’s my brother), I had the opportunity to apply it to my own field of endeavour, and I think it does indeed provide a valuable insight into who the influencers really are. Note that I’ve included myself in the list, not so much for vanity as for the sake of having a good control point. 😉

Here is a snapshot of the rankings as at 11th March 2015 18th Jul 2015. Note – As this is a graphical snapshot, the green buttons are inoperative – they normally would show you the twitter handle and website link used. I hope to replace this with a fully-functioning *live* version, eventually.

Selection criteria I used for appearing on this list
1) Have developed successful Mac and/or iOS apps
2) Write publicly via twitter and/or blog/website about app development, app store and Apple
3) Be posting (only or mainly) as an independent developer i.e. have own website or blog
4) Reasonably prominent – anyone scoring too low in this ranking system may be dropped from the table, for the sake of expediency and avoiding overload

Please note – I have compiled an initial list based on my own conjecture about who was reasonably prominent in this field. If you have a suggestion about who else to add, please let me know via twitter @gpdawson. Note that the individual must have 1) a twitter account and 2) a website or blog for which they are the primary contributors. Generally, anyone with a company website with multiple contributors can’t realistically be included without distorting the results.

HyperAltimeter – Barometer and Altitude Tracker

Here it is! I’m excited to present my first new app in a long, long time! It’s called HyperAltimeter, and it’s all about pressure and altitude, and pushing the limits of what can be done with the new barometer sensor that is embedded in your iPhone 6 or 6 Plus.

Whilst most smartphones are already equipped with GPS receivers, which do provide altitude readings, these are not typically very accurate. The GPS system is designed to obtain your horizontal position to a good degree of accuracy, but accuracy of altitude was not a key design factor.

However, the new barometer sensors are very sensitive, and can detect pressure changes as small as those experienced just by raising the device from your chest level to above your head. This means that it excels at measuring changes in height as you climb stairs, or walk or run a course.

However, longer term changes in pressure due to moving weather systems means that height changes can only be determined accurately over short periods of time, and similarly it also means that your altitude from sea level cannot be determined accurately from barometric data, alone.

The solution to longer term accuracy in height changes and absolute altitude measurement comes from combining the device’s barometric data with weather data i.e. readings of local pressure and temperature.

Amazingly, from first idea to this app becoming available in the app store was just six days! I’ve typically spent one to three months developing each new app, and then many more months, over time, enhancing and refining them. But in this case, by leverage code and experience from my other apps, I submitted the app to Apple after just five days. And then Apple’s approval came within twelve hours. By comparison, review time for app submissions is currently averaging about twelve days. So it seems Apple is especially keen to help along apps that make use of the iPhone 6’s new capabilities.

---

 

About the App

This app measures your altitude via three very different means (or via two means if your device doesn’t have a barometer sensor). This allows much greater accuracy than relying only on the device GPS sensor alone to find your altitude.

In fact the standard GPS readings of altitude are far less accurate than the other two methods, so it is provided here mainly just for the sake of comparison.

The three methods are:

1. GPS sensor
2. Online mapping survey data
3. Barometer sensor combined with current local atmospheric conditions

Altimeter Screen

This screen shows all available altitude-related data, as well as showing your current location on a map. The displayed data items are:

• GPS Altitude – this is the altitude from the standard GPS sensor. Note that the given accuracy is one returned by the sensor, although by observation the stated accuracy range is sometimes too small, and does not overlap the more accurate measurement taken via the two other methods.
• Map Altitude + Δh – This shows the altitude for your current location as determined via online mapping data. It is generally very accurate in relation to gound level. If you are in a high-rise, use the Height Above Ground field to enter your local height – this will automatically then be included in the altitude value shown in this field.
• Barometric Altitude – Barometer sensor combined with current local atmospheric conditions (means sea level pressure and temperature), which are then used to calculate your actual altitude. Note – this method is only available on devices which include a barometer sensor.
• Device Pressure – Shows the actual pressure reading from the device barometer, as used in the altitude calculation.
• MSL Pressure – Shows the mean sea level pressure from the nearest available weather observation location, as used in the barometric altitude calculation. Tap on this cell to see detailed information about the local weather data it is currently using.
• Height Above Ground (Δh) – this is a value you must enter yourself, if you are in a high-rise building or otherwise abve local ground level, and is used to refine the the Map Altitude calculation, above.

 

 

Graph Screen

This view allows you to see how altitude is changing with time, via a constantly updating graph. The three option are:

• GPS Altitude – Shows the altitude data returned by the device GPS sensor.
• Barometric Altitude – Barometer sensor combined with current local atmospheric conditions (means sea level pressure and temperature), which are then used to calculate your actual altitude. This value is retrospectively adjusted when each new local mean sea level pressure reading is obtained, to take account of the atmospheric pressure trend. Due to these adjustments, this graph should show reasonable stability over the long term.
• Δ Altitude – Shows the relative difference in altitude from when you first started the app, or tap the reset button, based on changes in pressure. This is very accurate for measuring short-term altitude changes, such as going up or down stairs, taking short walks or runs across terrain etc. Over longer time periods it will likely suffer from drift due to changes in atmospheric pressure, due to moving weather systems. For this reason you may want to reset this graph just before using it to make a measurement of change in your altitude.
• Pressure – Shows the raw pressure readings from the barometer in your device. This value changes over time for two reasons – one is when you move up or down, as pressure changes with your altitude, and the other is changes in local atmospheric pressure due to weather systems and wind gusts. If you keep the device stationary, then this graph will reflect only atmospheric pressure changes.

 

 

So what are you waiting for? Go and get it from Apple’s app store!

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!

* * *

More recent news and discussion about Sun Seeker on Facebook:

• http://www.facebook.com/pages/Sun-Seeker/149617118440015

More recent blog entries on Sun Seeker:

• https://ajnaware.wordpress.com/2009/10/24/sun-seeker-what-is-it-good-for/
• https://ajnaware.wordpress.com/2010/01/03/sun-seeker-is-finalist-in-2009-best-ar-app-award/
• https://ajnaware.wordpress.com/2010/01/23/sun-seeker-lite/
• https://ajnaware.wordpress.com/2010/02/14/sun-seeker-3rd-in-best-app-ever-awards/
• https://ajnaware.wordpress.com/2011/03/19/sun-seeker-update-v1-5/
• https://ajnaware.wordpress.com/2011/03/24/sun-seeker-test-shots/

Note – Sun Seeker is now available for Android! (March 2012)

https://market.android.com/details?id=com.ajnaware.sunseeker

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?

App Store Turns 1

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!

Oz Weather Apponomics – Part 6

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.

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