You may – particularly if you’re a British landscape photographer – look at the screenshot below and wonder to yourself, there’s something familiar about that location, but there’s something different too.

You’d be correct on both counts. The boats on the beach of the harbour at Holy Island in Northumberland (already a familiar location to many) were the subject of a photo at the centre of a recent controversy. If you thought that the satellite map gives a particularly clear view of the individual boats, again, you’d be correct!

Holy Island Cobles

We’re pleased to say that we’ve been able to restore Google Maps to TPE on iOS 6.

As many of you know, with iOS 6, Google is no longer the default supplier of mapping data and imagery. However, using the Google Maps JavaScript API, we’ve been able to add Google maps back in as an option alongside Apple’s maps, Open Cycle Maps, MapQuest Open Street Map and Open Aerial.

A good number of you have been asking for this – particularly users in the UK, where, until recently Apple’s satellite imagery was in places very poor indeed. We should note that the Apple map imagery is today very much improved over what it was even a month ago, and we expect those improvements to continue. That said, Google Maps is hard to match when it comes to satellite imagery.

Google Terrain Maps

There’s an additional upside to the new web-based maps approach: we’re now able to offer Google Terrain maps in TPE for iOS, for both iOS 5 and iOS 6 users:

Elgol, Scotland

This is a huge benefit to landscape photographers as Google’s Terrain maps are beautifully detailed and shaded, as can be seen from the screenshot of the Isle of Skye, above.

Which Maps Can I Use?

With TPE for iOS 2.4, which we will be releasing early on Monday November 19, UK-time, iOS 6 users have the following map options:

  • Standard (Apple)
  • Satellite (Apple)
  • Hybrid (Apple)
  • Google Standard
  • Google Satellite
  • Google Hybrid
  • Google Terrain
  • OpenCycleMap Topographic †
  • MapQuest OpenStreetMap †
  • MapQuest OpenAerial †

† Available offline

iOS 5 users have the following options:

  • Standard (Google)
  • Satellite (Google)
  • Hybrid (Google)
  • Google Terrain
  • OpenCycleMap Topographic †
  • MapQuest OpenStreetMap †
  • MapQuest OpenAerial †

While we would love to be able to offer offline support for Google Maps this is expressly prohibited by their terms of use. For offline map use, you can choose from OpenCycleMap Topographic, OpenStreetMap and OpenAerial.

One important point, particularly worth making in light of the changes that occurred with iOS 6: all the map types available in TPE are subject to change. We rely upon services provided by third parties to make these maps available. Those third parties may withdraw or amend those services in the future. They may also change the legal or commercial terms and conditions in such a way that we are no longer able to offer the same maps.

Rest assured, we’ll always work to offer the best maps that we can, but remember – it’s the internet. Things change!

We Hope You Like It

We hope you enjoy having Google back in the mix on iOS 6!

(And if you left a negative review on account of the change to Apple maps in iOS 6, we’d love it if you would consider now revising it :-) )

This morning, I read a new review from a user in Germany, who awarded TPE for iOS two stars, saying:

This is really a great app for photo freaks. But unfortunately it is not compatible to older iOS versions. That nerves and is not fair to users of older hardware. So, sorry, but 2 stars are enough. Its often easy to stay compatible…if you really want… and if you are really interested on your customers!!!

In light of this, I thought it would be worthwhile clarifying our thinking on device and OS support.

Current Situation

At the time of writing, TPE for iOS requires iOS 5.1.1 or higher. That means that a number of older iOS devices can no longer upgrade to the latest version, including:

  • Original iPhone (discontinued July 2008)
  • iPhone 3G (discontinued June 2010)
  • 1st and 2nd Generation iPod Touch (discontinued September 2008 and September 2010 respectively)

Er, that’s it. Every other iOS device ever made remains supported by the current version of TPE.

The Costs of Supporting Older Hardware

In an ideal world, yes – we would maintain support for older hardware. However, it’s not an ideal world, and every device and OS version we support imposes real costs, primarily in terms of development and testing time. We’re not, as you might imagine, a large company with development teams at our disposal (in fact there’s just the two of us). As a result, we have to decide how best to use our time.

“It’s often easy to stay compatible”: yes, that’s potentially true. But to do it you face a choice: either entirely forego the benefits of advances made in the functionality of later versions of iOS (more on which below), or start using those features, but write your code in a way that only exposes them to users on later operating system versions.

Suppose we made the first choice and elected not to make use of new OS features in the app. (By features, I mean developer level APIs that can be used by apps to support new functionality, or to improve the implementation of an existing feature in terms of performance, reliability and so forth.)

Even with this choice, older device support imposes some real costs: each time Apple releases a new version of iOS, we need to check that older code still works on the new software. Sometimes it doesn’t and we’re forced to change things in any case. Even when it does, we have an ever expanding number of versions to test against.

If we make the second choice (use the new features, but only for users running the newer iOS versions), we have to litter the code base with conditional checks for the running OS version (or equivalent checks) and then write and test code for every combination. Over time, the code base sprawls and becomes much harder to manage. Reliability suffers. We end up needing to write multiple versions of documentation for users on different OS versions. User problems are harder to resolve.

Neither is remotely an attractive situation.

Benefits Foregone

The other side of the equation is that, to support older devices, we likely have to forego the benefits of technological advances available in later versions of iOS (or any other operating system).

One great example is ARC. Introduced in iOS 5, ARC (automatic reference counting) essentially takes away virtually all the worry of memory management.

Memory management is probably the trickiest aspect of iOS development, and as such, is responsible for a large number of crashes and bugs when implemented incorrectly. Removing that worry from the developer results in a more stable, better performing app for users and allows the developer to focus on implementing new features and improvements: the net effect is a better outcome for customers.

When I switched TPE over to ARC earlier this year, once we started to require iOS 5, we saw a 5-fold reduction in the crash rate for the app. Five fold. A real and quantifiable benefit to users.

Another example is Block Objects and Grand Central Dispatch introduced in iOS 4. Blocks enable much more concise and readable code. Grand Central Dispatch (GCD) makes writing multi-threaded code much, MUCH easier. I relied heavily on both technologies to add support for the offline maps in TPE for iOS 2.3.

Choosing to forego these technologies to keep supporting older devices is done directly at the expense of users on new devices.

So how do we decide?

With all that said, how then do we decide which versions to support and which to drop? Why do we only require iOS 5.1.1 now? Why not switch to iOS 6?

The answer is that, pace my friend above, we are really interested in our users and we take careful note of how they use TPE.

When we dropped support for iOS 4 earlier this year, we examined the installed base to see what versions of iOS our customers were using:

We saw that 98.6% of our users were either already on iOS 5 or had devices that could be upgraded to iOS 5. The decision was easy at that point: at the expense of only 1.4% of users, we could offer significant benefits to the vast majority by moving ahead and taking advantage of the new capabilities in iOS 5.

So what is the cut-off point? I think that is always going to be a subjective decision and doesn’t depend on the numbers alone. Anything over 5% still on iOS 4 would probably have been a red flag. Between 5% and 1.4%, it would depend on the upside of moving to iOS 5. In the case of ARC, the upside was very clear.

Remember also, users still on iOS 4 didn’t lose use of the app: they lost only the ability to continue to upgrade until such time as they update their hardware.

As of today, 5.2% of TPE for Android users are using Android 2.2. I don’t think we’re ready to drop support for 2.2 quite yet. And the benefits attainable by moving to 2.3 are not that significant.

The bottom line is that we will follow our users. If 50% of users were still on iOS 3, would we still be supporting it today? Almost certainly, yes – if we didn’t, we wouldn’t have much of a business. Are we making the right choices? I hope so. If you see it differently, please let us know via Twitter/FB/G+.


Back in July 2012, we released version 2.2 of TPE for iOS. Amongst the new features (shadow lengths, moon perigee/apogee, crescent moon visibility, help overlays) was one that has until now remained largely a secret: an app-specific URL scheme.

An app URL scheme allows you to cause the app to open and take a specific action. For example:


will open TPE on your iThing and set the red map pin to the summit of Ben Nevis, Scotland. ll denotes latitude/longitude, a decimal coordinate pair, separated by a comma (following Google’s style for Maps URLs).

Note: these links will only function on a device with TPE for iOS installed.

We can take things a little further and specify the map region we’d like to display. This is best thought of as the zoom level for the displayed map. For example:


shows the whole state of Colorado. Yes (and I hadn’t realised this until preparing this example), Colorado is 4° latitude by 7° longitude (although those straight state-lines of course hint strongly at a lawmaker with a ruler and map!). In this case spn denotes map region span in degrees.

Finally, we can optionally specify a date to display. For example:


takes us to Cairns in Queensland Australia for the 2012 total eclipse of the sun, or:


to Washington DC for the lighting of the US National Christmas Tree on December 6.

At the moment, you can’t specify a certain time of day, only the date – that’s something we plan to add in the future.

(One thing I noticed while writing this post is that occasionally on changing to a new location, the time zone will appear incorrectly, resulting in some mixed up data. It appears this is an intermittent bug: I’ve only seen it once, but we’ll need to do some digging to get it fixed. Still, I decided it was worth sharing the information nonetheless.)

Also, we’ll be using the URL scheme to add support to future versions of TPE to allow you to Tweet or share via FB your planned shots.

In the meantime, if you click these links while reading this post on an iDevice with TPE installed, you can see how the scheme works. And feel free to start sharing your own links straightaway! If you have any URL scheme support features you’d like to see added, drop us a line.

Here’s a reference on how the URL scheme works as of TPE for iOS 2.2:

Go to coordinates

URL: ephemeris://view?ll=[latitude,longitude]
Values: numeric latitude between +90 and -90 degrees; numeric longitude between +180 and -180 degrees (west is negative); comma separated

Go to coordinates and map region

URL: ephemeris://view?ll=[latitude,longitude]&spn=[height,width]
ll: as above
spn: numeric latitude span between 0 and 180 degrees; numeric longitude span between 0 and 360 degrees; comma separated

Go to coordinates and date

URL: ephemeris://view?ll=[latitude,longitude]&dt=[datetime]
ll: as above
dt: date/time in format yyyyMMddhhmmssZ, e.g. 20120921000000+0000. Time of day and time zone are reserved for future use, and should be set to midnight GMT (i.e. 000000+0000)

UPDATE (Nov 5): many thanks to everyone who signed up – we’ve had a good response and will be closing the sign-up survey for now. If further spots become available in the future, we’ll open it up again and will post on Twitter/FB/G+

We’re looking to expand our team of regular beta testers for TPE for iOS. If you’d be interested in helping, read on!

With a new generation of iOS devices on the market, and with the growing userbase, we’d like to improve our geographic and device coverage across the test team.

We’re looking for TPE for iOS users from a variety of backgrounds and locations who are willing to download test builds, try them out and provide feedback.

The upside for you? Early access to new versions of TPE and the opportunity to influence direction and features. The upside for us? More extensive testing, broader feedback and, hopefully, a better app.

How it works Website

Here’s how the beta testing works. We use a great service called TestFlightApp to distribute the beta versions.

  • Complete our Beta Trial survey (link below)
  • If we’re able to offer you a place, sign up to our beta testing distribution service (TestFlight)
  • Register your devices
  • Periodically, you’ll receive a notification that a new beta test build is available
  • Install the new build
  • Test it!
  • Provide feedback

What we ask

There are a couple of things we ask of testers.

If offered a place, you’ll be asked to accept our Beta Trial agreement. The main things it covers are: (i) it’s beta software and it might not work properly; (ii) you agree that we can act on any feedback or ideas you send us; (iii) it’s confidential – please don’t blog/tweet or post about the beta without getting the nod from us first; (iv) we don’t owe each other anything (beyond what’s in the agreement).

We only have a limited number of places in the beta trial (as there is a hard limit of 100 testing devices per year from Apple). Therefore, before you sign up, please be certain that you’re happy to take the time to install the test builds and to provide feedback.

How to sign up

If you've made it this far, you might be ready to sign up. Here’s a link to a short survey (honest – it really is short!):

We'll take a few days to gauge the level of interest and then, if we’re able to offer you a place, we’ll be back in touch via email.

If you have any other questions, please feel free to drop us a line (email address is on the support page). Thanks!


Poor resolution (lower right) Much improved

  1. Left: Missing tiles (Sunday)
  2. Centre: Poor resolution (Sunday)
  3. Right: Much better (Wednesday)

We’re seeing some major improvements in Apple Maps satellite coverage of the UK today.

We’ve checked a good few locations, including Shrewsbury, Bamburgh, south of Fort William, and per the screen shots above, Milton Keynes. These are all locations where we’d seen problems in the past including very poor resolution (Shrewsbury), black and white imagery (Bamburgh), mis-matched images (Fort William), and missing map tiles (Milton Keynes).

Looking at the images above, the first (left) is screenshot from Sunday morning, showing map tiles missing entirely within TPE. The same location in the Maps App had tiles, but they were low resolution (centre). Checking again today, the same location seems much improved (right).

You can click on the images to see them at 100% – the improvement in map resolution is marked.

If you’re seeing improvements in your area too, please let us know via Twitter/FB/G+.

← Older Newer →