Why an iPhone stops tracking a run in your pocket
Short answer
An iPhone does not stop recording because the screen is locked. Tracking stops when an app was never allowed to keep receiving location while it is in the background, when Low Power Mode is on, or when iOS terminated the app to reclaim memory, and the order you check those in matters more than any single toggle. An app that has declared the location background mode keeps recording a session you started under the While Using permission, so Always is not the setting a run tracker needs.
A locked screen does not stop a recording.
iOS has no rule that ends one when the display goes dark. You start the run, lock the screen, pocket the phone, and what comes back covers the first few minutes and then a straight line. The things that do stop a run are each fixable in Settings, or at least testable on a walk.
What actually stops a recording on iOS
Three mechanisms account for nearly every lost iPhone run. The app was suspended because it was never set up to keep receiving location in the background. Low Power Mode was on. Or iOS terminated the app to reclaim memory. Each leaves a different mark on the track.
Apple describes the baseline behaviour in Handling location updates in the background, fetched 2 August 2026.
For example, on iOS, iPadOS, and watchOS, the system suspends the execution of most apps shortly after they move to the background. In this suspended state, apps don't run and don't receive location updates from the system. Instead, the system enqueues location updates and delivers them when the app runs again, either in the foreground or background.
Apple Developer Documentation, Handling location updates in the background
That last sentence is the one that misleads people. A suspended app is not simply blind: positions gathered while it slept can arrive in a clump when it runs again, which is why a stalled track sometimes fills itself in the moment you open the app again.
| Shape of the damage | First thing to check |
|---|---|
| Recording stops seconds after you lock the screen | Whether the app may receive location in the background at all |
| A straight line, then normal recording resumes | Suspension with late delivery, or a blocked signal there |
| The run ends part way and never resumes | Termination, or a finish triggered by a mis-tap |
| No run at all when you reopen the app | When the app writes to storage, covered in the last section |
While Using is enough for a run you started
You do not need Always.
A run you start yourself records under While Using, as long as the app has enabled background location updates. Apple states the rule in Requesting authorization to use location services, fetched 2 August 2026.
If you enable background location updates, an app with When in Use authorization continues to run in the background when location services are active; if location services aren't running, the normal suspension rules apply.
Apple Developer Documentation, Requesting authorization to use location services
Two things follow. Start the run with the app on screen, because Apple's background guidance tells developers to create the location session while the app is in the foreground. Then check that the phone agrees the app is in use. Apple says that when Location Services is active for an app, a black or white arrow icon appears in the status bar or Control Center, and that an app counts as in use either when you are actively using it in the foreground or when it is using location in the background, in which case a blue pill shows in the status bar, per About privacy and Location Services, fetched 2 August 2026. Lock the screen, wake it without opening the app, and look.
No indicator, no recording.
One place holds the setting, and opening it once beats guessing. Go to Settings, then Privacy and Security, then Location Services, then tap the app, per Control the location information you share, fetched 2 August 2026. A run tracker set to Never cannot record at all. One set to Ask Next Time is worse in practice than it sounds, because Apple's guide says you are asked to allow it again the next time the app tries to use your location, and that is a prompt sitting on a screen you are not looking at.
What the Always permission is really for
Always is about being launched. With it, the system can deliver location when you are not using the app, including after it has been shut down, and Apple's authorization comparison gives the difference in one row. For When in Use, launching a terminated app automatically is "No. The user must launch the app." For Always it is "Yes for significant location change, visits, and region monitoring services; no for others."
Those three services are coarse by design, and none is the continuous stream a run tracker draws a map from. Always is not harmful, and it carries a visible cost: Apple states that when you allow background location use, the device reminds you from time to time and shows those locations on a map.
What it does not change is a session you started in the foreground while the app is alive.
Background App Refresh, Low Power Mode and Focus
Apple documents only one of the three as switching something off. Low Power Mode is that one. Its page, Use Low Power Mode to save battery life, fetched 2 August 2026, lists Auto-Lock at 30 seconds, reduced brightness, iCloud Photos paused, email fetch off, and background app refresh turned off. It also notes the mode ends once the device charges to 80 percent or higher.
Background App Refresh is not background location. Apple describes it as the mechanism by which suspended apps check for updates and new content, controlled in Settings, then General, then Background App Refresh, per Switch apps on your iPhone, fetched 2 August 2026. Two different mechanisms. Leave it on anyway, because it removes a variable.
Focus is the one runners blame that Apple does not implicate. Apple calls it a feature for concentrating by minimising distractions, used to temporarily silence notifications, in Set up a Focus on iPhone, fetched 2 August 2026. That is a statement about notifications.
It explains a missed alert, not a missing track.
Precise Location and what it changes for splits
Precise Location does not stop a recording. It changes what the app is allowed to see, and the damage shows up as wrong numbers rather than missing minutes. Apple's guide is plain: to allow an app to use your specific location, leave Precise Location on, and to share only your approximate location, turn it off. The toggle sits under Settings, Privacy and Security, Location Services, then the app, per Control the location information you share, fetched 2 August 2026.
The developer side is explicit. Apple documents that under reduced accuracy, setting a desired accuracy to anything other than the reduced constant has no effect on the location information, and the app cannot use region monitoring or beacon ranging, per CLLocationManager.accuracyAuthorization, fetched 2 August 2026.
An approximate position cannot tell an app which side of a kilometre boundary you are standing on, so splits, average pace and the drawn route degrade together while the run appears to record normally. Nobody warns runners about that one. If your numbers look wrong instead of missing, check this toggle. What a phone measures on its own is covered in running with only your phone.
When iOS terminates an app to reclaim memory
No setting prevents this one. Apple's background location documentation states that the system can terminate apps at any time to free up memory or other system resources.
Once the process is gone, nothing is recording until the app runs again.
The same page tells developers to restart the location APIs on launch, and says the system then resumes delivery of queued location updates. What it will not do is bring the app back by itself. Apple's authorization page is blunt: if the system terminates the app, it does not launch an app with When in Use authorization to deliver new updates, and it does launch an app with Always authorization for some types of location updates.
Two habits follow. Do not swipe the app out of the app switcher mid run, because Apple states an app quit that way might not be able to run before you open it again. And reopen the app when you stop, so the run is closed and saved while you watch.
A five minute test with the screen locked
Test on a walk. Not the long run you care about. Change one variable at a time.
- Start the recording with the app on screenOpen the app, start the run, wait until the numbers move. Starting from a widget is a different test, because the session is meant to be created in the foreground.
- Lock the screen and check the indicatorWake the screen without opening the app and look for the location indicator. If it is missing here, the problem is background location permission and nothing below will matter.
- Walk five minutes without touching the phonePocket it and walk. Do not open the app switcher, a map, or a video. You want a clean interval where the recorder is the only thing asking for your position.
- Reopen and read the shape of the trackContinuous means the setup works. A straight line across the pocketed stretch means suspension with late delivery. A track ending at the lock means it never had permission to continue. Nothing at all means termination.
- Repeat once with Low Power Mode onWalk the identical route with it enabled and compare. That is the only way to know whether it matters on your phone, since it changes several things at once.
What should still be recorded when it goes wrong
Whatever the app had already written to disk. You cannot make iOS promise never to terminate an app, so what a bad run costs you comes down to when the app writes down what it has already collected.
An app holding the whole track in memory until you press finish loses all of it when the process dies. An app appending each batch as it arrives loses only what the operating system had gathered but not yet handed over. That difference is the subject of why running apps lose runs.
Runflake writes every GPS point to the phone's database the moment it arrives, before the app does anything else with it. There is no save timer and no save at the end step for the raw track. If a database write fails, the points are kept in memory and retried on the next batch instead of being thrown away.
The visible half of that is the next launch. When the app restarts and finds an unfinished run, it asks whether to continue it. The card says "You have an unfinished run" with the line "Saved up to where it stopped", a Continue button, and a Hold to finish button that requires a long press, so a mis-tap cannot end a run you meant to keep. That prompt is not open ended: a run can be continued for 30 minutes after its last heartbeat, and past that it is closed at the next launch and saved. Runflake is built and is not yet published to the App Store or Google Play, so there is no download available today.
Settle permission and Low Power Mode before a race, not after one. Termination you cannot settle. The remaining defence is an app that already wrote down the part you ran.
Common questions
- Does locking the screen stop an iPhone from recording a run?
- No. Locking the screen is not what stops a recording. Apple documents that an app with When in Use authorization keeps running in the background while location services are active, provided the app has enabled background location updates. What stops a recording is the app being suspended or terminated, not the display going dark.
- Should I give my running app Always instead of While Using?
- Always is about being launched when you are not using the app. Apple's comparison table says a When in Use app is never launched automatically after termination, while an Always app is launched for significant location change, visits and region monitoring. For a run you start yourself with the app open, Apple documents that When in Use keeps receiving location in the background once the app has enabled background location updates, and it calls that level the preferred choice because it has better privacy and battery life implications.
- Does Low Power Mode stop GPS tracking on an iPhone?
- Apple's support page lists background app refresh as turned off under Low Power Mode, along with reduced display brightness, paused iCloud Photos and email fetch. It does not describe Low Power Mode as switching off location services. Treat it as a variable worth removing before a long run rather than as the certain cause, and settle it on your own phone by walking the same route twice, once with the mode on and once with it off.
- Does swiping the app away in the app switcher matter mid run?
- Yes. Apple states that an app quit from the app switcher might not be able to run or check for new content before you open it again. While the process is not alive there is no location recording at all, so that interval becomes a gap in the track which no app can fill in afterwards.