Guideline 2.5.4 is the rule that catches apps running background location they do not actually need. Background modes exist for genuine use cases, navigation, fitness tracking, location-based reminders, but Apple rejects apps that keep location running in the background without a clear, user-facing reason. If your app declares the location background mode and a reviewer cannot see why it needs it, that is a 2.5.4 rejection. Here is what the guideline requires, when background location is justified, and how to fix a rejection.
Short answer
Guideline 2.5.4 states that multitasking apps may only use background services for their intended purposes, such as VoIP, audio playback, and location. Per Apple's software requirements guideline, running location in the background without a genuine, user-facing need is a rejection, because the background mode must serve a real feature. To fix it, only declare the location background mode if a core feature requires continuous background location, explain that need in your purpose strings and review notes, and use the least aggressive location option that works. If background location is not essential, remove the background mode and request location only while the app is in use.
What you should know
- Background modes need a real purpose: 2.5.4 limits them to intended uses.
- Location is one allowed purpose: but only when a feature genuinely needs it.
- Unnecessary background location is rejected: no clear reason means no approval.
- Explain the need: purpose strings and review notes should justify it.
- Use the least aggressive option: prefer in-use access or coarse updates when possible.
What does Guideline 2.5.4 require?
That every background mode your app declares maps to a legitimate, intended purpose. The guideline lists acceptable background services, including VoIP, audio playback, location, task completion, and local notifications, and the requirement is that you use them only for those purposes. For location specifically, that means the background location mode is justified when your app delivers a feature that genuinely needs location while backgrounded, like turn-by-turn navigation or continuous fitness tracking. What the rule targets is an app that enables background location without such a feature, often to collect data rather than to serve the user. So the test a reviewer applies is whether the background location supports something the user can see and benefit from.
When is background location justified versus not?
The distinction is whether a user-facing feature depends on it. The table illustrates.
| Use case | Background location justified? |
|---|---|
| Turn-by-turn navigation while the screen is off | Yes, the feature needs it |
| Continuous fitness or run tracking | Yes, core to the feature |
| Geofenced reminders the user set up | Yes, with appropriate APIs |
| Collecting location for analytics or ads | No, not a user-facing need |
| Background location with no related feature | No, rejected under 2.5.4 |
The justified cases share a visible feature that cannot work without background location, while the rejected ones use background location for something other than serving the user. If you cannot point to a feature that needs it, the background mode does not belong in your app.
How do you fix a 2.5.4 background location rejection?
Tie the background mode to a real feature, or remove it. First, decide whether a core feature genuinely requires continuous background location; if it does not, remove the location background mode and request location only while the app is in use, which usually clears the rejection. If a feature does need it, write a clear purpose string that explains why, and add review notes describing the feature and how to reach it so the reviewer sees the need. Use the least aggressive location option that satisfies the feature, such as significant-change updates or region monitoring instead of continuous high-accuracy tracking, since requesting more than you need invites scrutiny. The aim is that your location usage visibly matches a feature.
What to watch out for
The first trap is leaving the location background mode enabled from a template or library when no feature uses it, which is exactly the unnecessary-background-location pattern 2.5.4 catches. The second is a vague purpose string that does not explain why background location is needed, since the reviewer relies on it. The third is requesting always-on, high-accuracy location when a lighter option would serve the feature. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the declared background modes, location entitlements, and purpose strings in your build, so you can confirm you are not declaring background location you do not use before review flags it. Aligning the declaration with a real feature is the fix.
What to take away
- Guideline 2.5.4 limits background services to intended purposes, so background location must serve a genuine, user-facing feature.
- Running background location without a clear feature behind it, such as for analytics or ads, is a rejection.
- Fix it by tying the background mode to a real feature with a clear purpose string and review notes, or removing it and requesting location only while in use.
- Use the least aggressive location option, and use a pre-submission scan such as PTKD.com to confirm your build does not declare background location it does not need.
