I’ve spent hundreds of hours testing all sorts of running apps over the past year. As the co-founder of Smashrun and a daily runner, knowing my way around running apps and GPS devices comes with the territory.
It used to be that running apps, essentially, served the same purpose as a spreadsheet and a stop watch. They tracked basic metrics like time, distance, average pace and speed.
It didn’t take long for many apps to start offering features that recorded heart rate, and cadence or offer training recommendations that popularized workouts like speedwork and threshold runs.
Now, you search for running apps and you’ve got options that range from “live tracking” to escaping zombies!
This blog post is everything you could ever want to know about choosing a running app and the long detailed version of what’s over here, but reading this for its entirety can help make a difference in the development of future running apps.
What You Might Not Know About Popular Apps
I’ve tried all of the popular running apps across many different platforms. For the past nine months, I’ve been looking over their GPX and/or TCX exports to evaluate data integrity. I doubt that all runners wonder about pause detection, distance calculations, or data resampling before choosing an app, but it’s something to think about.
A friend of mine who’s been a veteran Garmin user for almost a decade never knew that Garmin’s distance calculation didn’t account for altitude change. Some of the runners that have emailed us at Smashrun about their run data from Runtastic never realized that their exported data is resampled.
Popular running apps like Endomondo and Strava don’t encode pauses in their data and SportsTracker uses local time instead of UTC when recording your runs.
There are many different degrees of problems when it comes to the nuances in reporting standards. For the most part, running apps should follow one of two schemas for data exports: Garmin’s schema for TCX files and the official GPX schema. Every app interprets both differently.
Pause Detection Can Make or Break Your Data
You might ask why pauses should matter or why any apps should bother trying to detect it. Pausing is perfectly fine, but it doesn’t transfer so well between platforms unless your app encodes it.
Strava has pause detection built in to their web platform. RunMeter has pause detection built in to their mobile app. SmartRunner encodes pauses in their data export, but SportsTracker, Runtastic, and Endomondo do not. All of these matter because it maintains the integrity of your data when you move it from one platform to another.
Pauses are a big deal because they can shorten your calculated distance, which affects your average pace, speed, and maybe even elevation gain or loss. It’s why incorrect pause detection frustrates a lot of people.
Imagine recording a 10km PR with Runtastic only to find that Strava says you actually ran 9.8km because you paused.
When you run with a GPS device (whether it’s your phone or Garmin), it records trackpoints, which at the very least consists of lattitude and longitude.
Every trackpoint has a time stamp and, depending on your GPS device, it will record a trackpoint at set intervals, the best scenario being one trackpoint per second and the worst could be something like one trackpoint every 30 to 40 seconds.
If it takes 30 seconds to grab your next position, that means if you sprint as fast as you can up and down a hill as many times as you want and get back to your starting point before the next trackpoint, your app will say that you never left that spot. How disappointing would that be?
Pause detection algorithms evaluate long gaps between time stamps and consider the possibility that it’s a pause. At Smashrun, we look at every detail your GPX or TCX file provides to figure out whether or not you paused, including cadence, heart rate, and speed among other things.
When you export your runs and pauses are not clearly delineated, you’re leaving third parties to guess where the pauses took place. Of course, if you never pause, then you have other things to worry about … like whether or not your app resamples your data.
Resampling is the Worst Thing Running Apps Can Do
If you have any intention of ever moving your run data between platforms or if you have any plans to analyze your splits in the future, make sure that the app you’re using does not resample your data when you export it.
Resampling is a process that removes trackpoints in order to reduce file size and/or simplify the process of creating a map for a given run. It is inherently destructive. The simplest and probably the most popular resampling algorithm is Douglas-Peucker.
You can download this recent study on the Douglas-Peucker algorithm, which has some great examples on how simplification algorithms work.
The basic idea is this: let’s say you ran a straight line that was 3km long, trackpoint A is where you started the 3km run and trackpoint Z is where 3km ended and you turned left, thereby breaking your straight route.
If you resample that run using Douglas-Peucker, trackpoints B – Y will be deleted because you can easily draw a straight line from A to Z without the trackpoints in between.
That’s really bad.
You can no longer accurately calculate your splits without those trackpoints. It’s like they never existed. What’s more is that you now have this huge gap in time stamps between trackpoint A and trackpoint Z, which could look like a pause.
Luckily, some web platforms are smart enough to turn off pause detection for apps that resample run data. Although, that doesn’t change the fact that you can never move your original data.
Of Course, There’s Also Bad Files
There are a lot of ways a GPX or TCX file can go wrong. I’ve come across files that suggest it’s possible to run backwards through time because the time stamps are in reverse order. I’ve looked at GPX files with zeros and negative values for time stamps – there’s not much anyone can do with that unless they re-label all of the time stamps.
There are running apps, like SportsTracker, that record your runs in local time instead of UTC, but that doesn’t make sense because local time can always change depending on time zones – that’s why we have something called “coordinated universal time”.
Then, there’s the lax reporting convention. Running apps don’t necessarily identify themselves in their data exports, and closed tracks or track segments are not necessarily used to represent breaks in a contiguous track.
Although, let’s assume that pauses are properly encoded, resampling doesn’t take place, and there’s nothing buggy about your data export. There’s one more thing that can throw a wrench into your summary details, which might not affect your choice of apps but is important, nonetheless, and that’s total distance.
Everyone Calculates Total Distance Differently
It’s the number one accuracy-related issue that pops up in almost every running app forum. Total distance is different between apps. You might track a run using MapMyRun and then import your GPX file into Strava. Chances are pretty high that the total distance, along with your average pace and speed, will slightly differ between the two because of their distance formulas.
Every distance formula relies on a coordinate frame that is a representation of the globe so that we can say point A to point B equals x-meters (sometimes referred to as a geodetic calculation). The many different representations of the globe is one of the reasons why it’s tough to match the exact distance between apps, because we don’t know which representation of the globe an app is using .
Let’s presume that every running app uses the same current standard coordinate frame used in geodetic calculations. Now we have to figure out what distance formula is being used.
Some apps offset their distance calculations to improve accuracy but they usually start with either Haversine or Vincenty’s formula (above), the latter being the most accurate down to half a millimeter. Beyond these two, there’s a multitude of other formulas that can be applied to calculate the distance between two points.
Is one formula more accurate than another? It depends. If you want to account for altitude change in your total distance then the formula matters, because you can calculate total distance projected on a flat surface vs. a sphere.
You might have noticed that some web platforms always match the total distance when you import a TCX file. That’s usually because they just add up the total distance noted for each lap as opposed to calculating your summary details based on the individual trackpoints.
So how do you go about choosing the best running app?
Your Running App Should Match Your Running Goals
On Smashrun, I wrote a section called Run Tracking 101 where I mention that there are three things you should consider before committing to an app or device:
- The purpose of your training
- What you intend to do with your data
- How you would prefer to access it
For casual runners and beginners, it makes sense to choose a running app that helps build momentum through social accountability so that you’re more likely to stick with it. Try an app like Endomondo or MapMyRun.
For intermediate and long-term runners, it’s usually better to run with a GPS watch since you’re more likely to dig into the underlying data. You’ll need a device that’s dedicated to your running as opposed to being at the mercy of your phone’s GPS capabilities. That said, apps like RunMeter, iSmoothRun, and RunKeeper can sometimes work just as well.
Of course, what you intend to do with your data will affect your decision. Remember that your data is only as good as what you can do with it. If you can’t export it, then you’re stuck with the same platform. If you can export it, but it’s bad data, then you can’t do much with it.
I looked over every list of top free running apps published over the last two years. Then, I tested every app and looked at all of their data exports and evaluated each one based on six categories:
- Pause detection
- Ability to export via email
- Data ownership
- Export file type
- Data resampling
- Data consistency
You can find the list of apps here. I also tested a bunch of running apps that don’t perform GPS tracking, lack data export functionality, and/or it’s not free, which included Fitocracy, Roadbud, Adidas MiCoach Running, and Ghost Race Lite.
I also ran with the Nike+ GPS app, which was one of the very first running apps I had ever used. I would only recommend it if you don’t ever pause during a run, because it’s not encoded and it’s impossible to detect. However, if you don’t pause and you’re okay with never being able to export your data in GPX or TCX format, then you have nothing to worry about.
This brings me to my final point of data portability. It’s not uncommon to move data between platforms, especially if one is better at analyzing it than another. Some runners don’t really care about in-depth analysis, but some are more than inclined to crunch numbers.
If you’re in the latter group, you should keep in mind the different pitfalls I mentioned earlier, especially pauses and data resampling. Chances are pretty good that if you find a data issue while importing your old runs to a new platform, it’s not the new platform’s fault. Your old running app might be to blame.
Where does that leave us?
Choosing a running app isn’t just about going with what’s most popular. It’s worth your while to know what goes into building a good app. It protects you in the long run from choosing apps that don’t allow you to export your data or, worse, an app that resamples your original data.
Apps are a great way to get started with running and I’m a huge proponent of running apps that keep runners motivated. Unfortunately, as developers continue to push the boundaries of what’s possible, they also inadvertantly carry over legacy issues that make it difficult to transfer your run data between platforms.
Download running apps that give you the freedom to move your original data and that follow due diligence when it comes to reporting standards. You can help make a difference and maybe one day, the not-so-good apps will change the way they record your run data.