A running route planning app has two jobs: draw the route, then record it.

Distance is a decision before it is a measurement

Ask a runner how far they want to go and the answer is a time. Forty minutes before work. An hour on Sunday. Distance falls out of pace, and pace is not a constant: the same person runs a minute a mile slower on trail than on tarmac, and slower again into a hill. So the first useful screen in a run route app is not a map at all. It is a conversion from the time somebody has into the distance that fits it.

The second constraint is geometry, and it is the one people miss. A loop of a given length cannot get far from where it starts. A perfect circle six miles round never reaches a full mile from its centre, and real routes are made of streets rather than circles, so the usable radius is smaller again. That is why route building in a dense grid feels easy and route building from a house at the end of a lane does not. There is not enough path inside the circle.

Then there is snapping. A route drawn as straight lines between taps under-reports distance on every bend, because the line you drew is shorter than the road you will run. Snapping each segment to the path underneath fixes the number and makes the route runnable, but it only works where the path exists in the map data. In a park crossed by unofficial trails, or on a new estate, snapping does more damage than a straight line. The general shape of the problem is the same for any route planning app, whatever is moving along the route.

What the phone will do while the screen is locked

This half decides whether the app is usable, and it is not up to you. Recording a track from a pocket means location updates in the background. On iOS that means enabling the location updates capability on the app target, which writes the keys your app needs into its configuration, and then creating a location session that asks for the authorization the user has actually granted. Both when in use and always are supported, and Apple says plainly that with always authorization you should tell the user that location updates arrive in the background.

There is a second detail that catches people out. The system suspends most apps shortly after they move to the background, and a suspended app does not run and does not receive location updates. The system enqueues those updates and delivers them when the app runs again, in the foreground or the background. If the app terminates, the location session has to be recreated immediately when it relaunches in the background. A recorder written as though the app is always awake produces a track with holes in it and no error message anywhere.

One thing we did not confirm: whether an app built with Newly holds a GPS track through a locked screen on a real handset. We have not watched that happen, so treat it as unverified rather than as a yes or a no. The test is not subtle. The background capability has to be present in the build, the app has to ask for and receive the right authorization, and then somebody has to lock a real phone, put it in a pocket and run for an hour. A simulator will not answer this, and neither will an AI that sounds confident about it.

Apple Developer, handling location updates in the background

The map under the route, and what its licence asks

A running map app wants two different things from a map: tiles to look at, and a network of ways to snap the route to. You can licence both from a commercial provider, or you can use OpenStreetMap, which is where a great many footpaths, park trails and canal towpaths are actually recorded, usually by the people who walk and run them.

Open does not mean unconditional. OpenStreetMap data is published under the Open Database License, and the terms are short enough to read in full. You are free to copy, distribute, transmit and adapt the data as long as you credit OpenStreetMap and its contributors, and if you alter or build upon the data you may distribute the result only under the same license. For an app that means a visible attribution notice, a link to the copyright page or the licence itself, and a clear head about which parts of your own data are derived from theirs.

Share-alike is worth thinking about before you build a feature rather than after. A route a user drew by snapping to OpenStreetMap ways is a different object from a raw track that user recorded with a phone, and if you plan to publish a browsable database of routes you want to know which side of that line you are standing on. The same question turns up wherever an app measures distance on borrowed geography, including a golf course gps app, where the distance that matters is a straight line to a pin rather than a line along a path.

OpenStreetMap copyright and licence

A saved route is more than a line

The line is the least useful field a route record holds. What brings people back is everything the line does not show: surface, lighting, how many road crossings break the rhythm, whether there is water at halfway, whether the gate at the far end is locked out of season, and whether the last mile is uphill.

Those fields are also the ones a global product cannot fill in, because the answers are local. A route library that knows the canal path floods after heavy rain, that the park gates close at dusk in winter, and that the hill by the school is the one everybody complains about, is worth more to twenty runners than ten million routes elsewhere.

The field people forget is who the route is for. Five miles is a warm up for one member and the longest run of the year for another. A route that carries a suggested pace band, or just a note saying which group runs it on Tuesday, stops being a map and becomes a plan. That is also the field that makes a route worth sharing, because it answers the question somebody was actually asking.