How many GPS decimal places do I need?

More decimal places are better right?  Not necessarily.  I see people using six or eight decimal places for GPS with no understanding of what this means.  They’re storing and showing more precision than the iPhone has accuracy.  This is a bad user experience!  The iPhone user is being confused.  This is the old issue between accuracy and precision that can affect any kind of measurement.  Here’s the problem and have some code for a solution below too.

Accuracy vs. Precision

Accuracy for a GPS location is how close the GPS latitude and longitude are to the actual latitude and longitude you’re measuring.  Precision is how precisely you’re specifying that location.  The more decimal places, the more precision.  One problem case is when your accuracy is low and your precision is high.  That leads you to believe that you have more accuracy that you think.  The other case where your accuracy is high and your precision is low.  In that case you’ve measured your position better than you’re showing it!

GPS Accuracy

Your GPS accuracy is how close your GPS position is to your actual position.  But you don’t really know your accurate position, that’s why you’re using a GPS of course.  So your accuracy is going to be probabilistic.  The iPhone GPS (or any other GPS)  has a description of the horizontal error circle where your GPS reported position at the center of this circle and the actual position is within the circle for 95% of the measurements at that location.  (Actually it’s not a circle, it’s an ellipse but that’s another subject.)

This circle will be 5-10m in radius (15-30 feet) for most practical cases of best accuracy.

At the equator one degree of latitude or longitude is 110.8 km (68.848 statute miles or 59.827 nautical miles).  This Wikipedia article has as good section about the length of degree and table showing values.  I’m using the 110.8 km/degree value that’s a reasonable medium.  Lines of longitude get closer at the poles, so that distance for a degree of longitude gets smaller for more northern or southernly latitudes.  Also, the Earth isn’t quite as round (it’s an oblate spheroid, the poles are mashed together a bit), so lines of latitude get a bit larger at larger latitudes where the Earth is pushed down some.  But as the distance get smaller, accuracy improves, so the worst case for accuracy is at the equator.  This is for each decimal place at the equator:

1.00000000   110.8 km (68.848 miles)
1.10000000   11.08 km (6.8848 miles)
1.11000000   1.108 km (0.6884 miles)
1.11100000   110.8 m (363.51 ft)
1.11110000   11.08 m (36.35 ft)  - Common GPS accuracy
1.11111000   1.108 m (3.635 ft)  - Good GPS accuracy
1.11111100   11.08 cm (4.36 inches)
1.11111110   1.108 cm (~3/8 inch or 0.43 inch)
1.11111111   1.108 mm (~1/32 inch or 0.04 inch)

So showing 6 or 8 decimal places not only isn’t useful it can be confusing or even deceptive. Unless you’re using a $7,000 survey-quality differential GPS you’re not going to get near to that accuracy.  Your precision should show what your actual accuracy really is.

And unless you’re GPS is just starting up or has a difficult time getting a position, you’re accuracy will be to around 10 m.  So your precision should be generally be 4 decimal places.  To capture the most accurate positions you’d be using 5 places at most.


You don’t need a double float for this as you’re accurate to five places.  If you want to avoid rounding errors if you’re doing a lot of location-based calculation, then store six places.  Since a float variable is significant to about 7 decimal digits we’re completely covered!  Apple uses a double, but it’s overkill.

The User’s Experience

Through years of poor GPS device UI, people have become accustomed to seeing six or eight digits.  But shouldn’t the accuracy determine the precision shown?  That’s a better UI, it tells the user implicitly how good their location data is. In all current GPS systems the accuracy is also reported, but is not implicit in the location precision.

We can get the accuracy on the iPhone in our CLLocation value that the CLLocationManager sends us on a location update.  The accuracy will vary from CLLocation to CLLocation received.  There are actually two accuracy properties: horizontalAccuracy for our position and verticalAccuracy that is for altitude.

The code below uses is a utility routine that’s given the coordinate value and the horizontalAccuracy value and shows the right number of decimal places based on that.  Feel free to use or copy this, it’s my effort to improve the UI for location-based apps.  If you publish or use this, please also have an link to this post for attribution.

/*  Accuracy distances in meters to show correct levels of precision.
    See for detail. */

const float distance[] = {110800.0, 11080.0, 1108.0, 110.8, 11.08, 1.1};

- (NSString *)coord:(double)data withAccuracy:(CLLocationAccuracy)accuracy  {
    for (int i  = 0; i < 6; i++)  {
       if (accuracy >= distance[i])
           return [NSString stringWithFormat:@"%0.*f", i, data];

    /*  Fell out of the loop.  This protects against some future iPhone where
        GPS accuracy is better than a meter! */
    return [NSString stringWithFormat:@"%0.6f", data];



Distributing iOS Applications

Looking to distribute an app?  Planning to use the app store?  That’s one way to get apps in people’s hands.  But we also put apps in peoples hands for development, testing, or possibly enterprise distribution.  I’ve been doing a lot of this lately so I thought I’d write it up while it’s all fresh.

Let’s take it step by step.  When you first write an application you’re working as a developer with a phone (or iDevices) setup for development.  You write and test with an iPhone (or device) in development mode.  But then you want to see if your work meets user’s standards.  So you recruit some test users and put your app on their phones using ad-hoc distribution.  Once they’re happy, you can submit to the app store, to the VPP app store, or do your own distribution in-house in a company or organization with enterprise distribution.  The process looks like this:

distribution flowchart

Each box in the chart is a type of distribution mode and has its own requirements and limits.  (Note that Apple refers to distribution as anything but development.)  This post describes those requirements and limits and what you can do with each mode.  This post is long enough so I’m generally leaving the procedures of how to do each one to future posts.

I use the Xcode organizer to read and upload information with a phone.  There are other ways to do some of this with IPCU (iPhone Configuration Utility), but here I’ll be focusing on Xcode and its Organizer window with the device tab active.  Also, I’m talking about Xcode 4.5 and 4.6 only.  If you have an older Xcode you should probably upgrade. (Use the Mac App store.)  In any case if you want to submit to the app store or VPP app store, you’ll have to use the latest production Xcode (4.5 at this writing, probably 4.6 within a few months).

Development mode

Devices used for development need to be set up for development. This lets you debug with them and gives you access to your application files on those devices.

To put a device into development mode you need to click the “Use for Development” button in Xcode’s Organizer when the device is plugged into your Mac.  (This only shows up when the device is not being used for development.)  You also need to list its UDID in your Devices list in the iOS Provisioning Portal.  Xcode automates part of that process.  But if you’re using a custom development provision profile you need to add that device to that profile.  Your development profile lists the device UDIDs that it can be used on.

With that done, you can now run in the debugger on that device.  In addition the crash logs and console, you can access your application’s files.  This includes custom log files your app has written out to the devices disk, cache files, SQL files, etc.  If you design your app with this in mind it can be a valuable debugging tool!

To access those application files:

  • Connect your development phone to your Mac and open Organizer in Xcode with the “Devices” tab active.  Wait until your phone shows a green dot next to it.
  • Click your “Applications” item under your phone, then on the right, click your application under development.
  • After a moment (as the files are downloaded), your applications files will show up in the bottom pane of the Organizer window.
  • You can use the “Download” button at the bottom to download your files from your iPhone to your Mac.  They’ll show up with a name like “com.YourCompany.YourApp 2012-12-30”.
  • To open this right click the file (control click or two-finder tap) and select “Show Package Contents” from the contextual menu.  This allows you to see your app’s saved files.

Ad-Hoc Distribution

Ad-hoc distribution is not development; it’s a distribution to a strictly limited set of devices for testing purposes only.  Ad-hoc uses the same 100-device list as developer mode does.

Ad-hoc distribution lets you install your app without going through the app store, but you’ll need to create an ad-hoc distribution profile for your app.  This profile must be installed on your device for the iPhone or device to accept that app.  Also, the device will have to be added to your device list just like with development mode above.  When you make your ad-hoc distribution profile, you’ll have to list the devices it will work with as you listed the development devices on your development profile.  The devices this profile will work on are listed in the profile, like the development profile.

Ad-hoc is designed for doing beta testing with only a small numbers of users.  Presumably these are users you’re working with and who will give you reports to you about the app and any shortcomings.  These are also users that will send you their UDID numbers.  You’ll need that to add them to the device list.  There are some free apps like “Ad-hoc helper“, ”UDID“, and “UDID Sender“ that your testers can download and use to send you their UDID information. Your users can also get that UDID from iTunes, but the apps are easiest and less error-prone.  Alternately if your beta testers are local, you can plug in their phones to your Mac and get their UDID yourself from Xcode’s Organizer like you did with your development devices.

Some good practices during ad-hoc (and development too) are to:

  • Install BugSense or Google Analytics for iOS (or some other crash logging system) in your app for crash logging.  (The first is better for crashes but doesn’t do analytics, the second is better for all-around analytics usage data but can get some crash data too.)
  • Sit down with (or Facetime or Skype) your beta testers and walk through the app.  Watch them, but don’t coach them.  See where they have problems.  Redesign and rewrite your app accordingly.

At this point, your ad-hoc users think your app is the greatest thing ever.  It’s time to distribute to the world!

The Development/Ad-Hoc Device List

First, an aside: The device list for your developer account has a few key points that are worth noting.  It’s limited, it’s updated yearly, and your developer ID has only one list.  Manage them well as it can be a scarce resource.

You can get another list of the same 100 size by setting up another developer ID for yourself, but it’s awkward and difficult to shift between the two developer IDs.  That works best for multiple development teams where each team primarily uses their own team ID.  Although if you’re doing contracting work it would be a good idea have your customer set up their own developer team ID which you would use for their work. If you set up too many under your own name (aka email address) Apple could think you’re trying to work outside the system and possibly even revoke your developer IDs.  (They’ll contact you first.)  Key points:

  • List size is 100 devices per developer ID (or developer team Apple ID).
  • This list is used for Ad-Hoc and Developer ONLY.  It does not apply to other distribution modes.
  • You can add and delete any time but deletions only become effective once per year on the anniversary of your developer ID creation.
  • If you max out, you’re out of luck.

So What Release Distribution Should I Use?

There are three ways to get your app into user’s hands.  The well-known way is the app store.  But if you are in a narrow market and  perhaps you’ve customized your app for one or a few customers, you can use VPP, the Volume Purchase Program.  (From the developer side it’s also called “B2B” for Business to Business.)  VPP is a specialized form of app store distribution.  This lets you allow only a set of customers you’ve selected to see your app.  You’ll need a different application ID for VPP than for any app store work, but you can do this on your current Apple ID (developer ID).

There’s also the Enterprise Distribution for in-house distribution at a company or organization.  This does not go through the app store process at all and you handle all details of distribution.  You have to get a special Apple ID (developer ID) for this in addition to a new application ID.

App Store Distribution

This is what most developers use since most of us want to reach a large audience.  To do this, you’ll need to go to “Provisioning” in the iOS Provisioning Portal and select the distribution tab.  There you’ll create a distribution certificate and profile and download and add them to Xcode. (The certificate gets added to Keychain Access.)

In Xcode, you’ll make your app with the “Archive” command and sign it as an ad-hoc.  This sets the stage for submitting it to the app store.  Next you’ll use iTunes Connect (from iOS Developer Center) to setup your new app data.  You’ll need the app title, version, description, copyright, app store categories, your website address, any review instructions, screenshots and your app icon in 1024×1025 size.  Walk through that process until you get to “Ready for Upload” status.

At that point you can go back to Xcode and select your app in the Archive, and click the distribution button.  Xcode will re-sign your app with your app store profile and upload it to the app store for review.

After an initial routine and automatic validation step, your app will be in the queue for review.  Lately I’ve seen a 5-8 day review cycle for my apps for both app store and VPP submissions.

VPP Distribution

VPP apps are submitted in a very similar way as above and also go through a review process.  Apple has asked me during review what customizations I’ve done for the app.  This is an incorrect question as customizations aren’t required; you can nicely point that out to Apple and they’ll approve your VPP anyway. (At least they did with us.)

The only difference between an app store and a VPP app store submission is that during the iTunes Connect setup for submittal, you tell iTunes Connect you’re submitting a B2B app.  You do this on the same page where you set your pricing and availability for your app by clicking the “Custom B2B App” checkbox.  Then, enter the Apple IDs of the customers you want to be able to see this product or release.

You use VPP when you have a customized app for a customer or set of customers, or when you have a limited set of known customers.  Note that you’ll need your customer’s Apple IDs that they wish to buy your app with.  If they have several Apple IDs then make sure they get you the right one!  Believe me, this solves problems later.

Enterprise Distribution

This is different since you’re not going through the app store at all!  There’s no review process.  And you can’t do this with your regular developer team ID that you use with the app store.  You’ll  need to make a new developer ID specifically for enterprise distribution (and a new application ID too).  Apple may call and talk to you.  They’re nice; they just want to make sure that you know this isn’t for distributing the same app you may already have in the app store.

With enterprise there’s no help in distributing to your users and installing on their iDevices either.  Users can’t go to the app store to get these!  You have to distribute yourself.  This is designed for using in-house in a corporation, or perhaps a large organization of some sort.  There’s no limit on the number distributed to, but it is up to you to control access and to limit distribution to your employees and subcontractors.  To do otherwise is to risk Apple revoking your developer ID and that’s a lousy way to shut down your development!

The reason this works for unlimited numbers is that each enterprise app is signed by you instead of by Apple.  You control which iDevices it’s distributed to, how it gets to them, and who gets to install it.  The enterprise profile does not list the devices it may be installed on and you are not limited by the 100 device limit as in ad-hoc and development.  (This is a source of confusion for many developers.)

When you do enterprise distribution, you distribute by choosing the “Save for Enterprise or Ad-Hoc Distribution” radio button in the distribute panel in Xcode Archive.  Then click the “Save for Enterprise Distribution” checkbox in the save file panel.  That opens up some fields which sets up an XML file you can use for OTA (Over-The-Air) distribution.  I’ll do another post about that later.

Or instead of OTA distribution, you can simply load the ipa file directly onto people’s phones with IPCU or Xcode.


Below is a quick reference to some of the features of the various distribution modes.  I hope this clarifies some of the confusion about ad-hoc, enterprise, and other ways of putting your app on iDevices.  I welcome your comments or questions.


New Year – New Start

Life happens, things change: The old One And Zeros blog is no more.  This new version will focus more on the “neat stuff” in the subtitle.  The emphasis will be on software, mostly iOS since that’s where a lot of my thought and time are going these days.  But there will be the odd post on things that catch my attention.  Mostly those are likely to be with some kind of hardware, or something with boats or airplanes.  But other subjects (like economics) may show up occasionally too.

In short, much of the same, but more technical article-oriented than the old blog.  I hope it’s useful for you!