Guideline 2.5.4: background modes

A Guideline 2.5.4 rejection means your app declares a background mode that the reviewer could not match to a feature. Almost always it is audio or location in the Info.plist, and almost always the honest answer is that the entitlement is there to keep the app running rather than to play anything or navigate anywhere.

If that is your situation, remove the entitlement. There is no wording that makes an unused background mode acceptable.

How it is usually worded

The header arrives as Guideline 2.5.4 - Performance - Software Requirements, and the body is normally close to:

• "Your app declares support for audio in the UIBackgroundModes key in your Info.plist but does not include features that require persistent audio."
• "Your app declares support for location in the UIBackgroundModes key but we were unable to find any features that require persistent location."

The reviewer read your Info.plist, looked for the matching feature, and did not find it.

What it actually means

The guideline says multitasking apps may only use background services for their intended purposes, and lists them: VoIP, audio playback, location, task completion, local notifications and so on. It also asks that apps using the location background mode include a reminder that doing so may decrease battery life.

The key word is "intended". Background modes are not general-purpose permission to keep executing. Each one exists for a specific user-visible behaviour, and reviewers check for that behaviour rather than for your reason.

Where the declaration lives

Two places to look, and they are the same setting seen from different angles.

• Xcode: your target, Signing and Capabilities, Background Modes. The tick boxes.
• Info.plist: the UIBackgroundModes array. Values include audio, location, voip, fetch, remote-notification, processing, bluetooth-central, bluetooth-peripheral, external-accessory, nearby-interaction.

If you use Expo, React Native or Flutter, check the generated Info.plist in the build, not just your config file. Plugins add entries you never wrote.

Why it triggers

• Silent audio as a keep-alive. Playing an empty or near-silent track so iOS keeps the process alive for a timer, a tracker, a sync, or a socket. Reviewers know this pattern well, and it is the single most common cause of a 2.5.4.
• Background audio for a video app that pauses on backgrounding. Perfectly reasonable engineering, but if nothing keeps playing when the app leaves the foreground, the declaration does not match the app.
• A plugin you did not audit. An audio, calling or maps library that ticks a background box in its podspec or config plugin.
• fetch or processing where the work is not user-visible. Background fetch is rarely rejected on its own, but combined with an app that shows no updated content it invites the question.
• The feature exists but the reviewer never saw it. Behind a login, a paywall, a device pairing step, or a tab you did not mention. The entitlement is legitimate and the rejection is still yours to answer.

How to fix it, in order

1. Read your shipped Info.plist, not your source config. Unzip the .ipa, or check the built app in ~/Library/Developer/Xcode/DerivedData. List every value in UIBackgroundModes and be honest about which feature uses each one.
2. Delete every entitlement you cannot point at a feature for. Untick it in Xcode, confirm it is gone from the built plist, and rebuild. This is the whole fix for most of these rejections.
3. Replace a keep-alive with the right API. If silent audio was finishing work for you, use BGProcessingTaskRequest or BGAppRefreshTaskRequest from BackgroundTasks, or beginBackgroundTask for a short handover, and accept that iOS decides when it runs. Work that truly cannot be deferred belongs on a server.
4. If a background mode is real, make it obvious in review. Put the feature one or two taps from launch, or describe the exact path in Review Notes with working credentials. "Tap Play on any episode, then press the home button; audio continues and the Now Playing controls appear on the Lock Screen" is the shape of a useful note.
5. Add the battery reminder for background location. A line on the screen that starts tracking, and in the purpose string. It is explicitly requested by the guideline.
6. Support the platform behaviours that go with the mode. Background audio should register with MPRemoteCommandCenter and populate MPNowPlayingInfoCenter; without Lock Screen controls it looks like a keep-alive.
7. Audit plugins after every dependency bump. Add a check on your shipped plist to CI or to your release checklist so a library cannot reintroduce an entitlement quietly.

What to send back

If you removed the entitlement, say which and why:

Thank you for the review. We have removed audio from the UIBackgroundModes key. It had been added to keep a sync task alive, which was the wrong approach, and that work now uses BGProcessingTaskRequest from the BackgroundTasks framework. Build 118 declares no background modes at all, and we have confirmed this in the shipped Info.plist rather than in our project configuration.

If the feature is real and the reviewer missed it:

Thank you for the review. The audio background mode supports continuous podcast playback, which is the app's main purpose. To reproduce: launch the app, tap any episode in the Latest list, tap Play, then return to the Home Screen or lock the device. Playback continues and the Lock Screen shows episode artwork with play, pause and skip controls, provided by MPNowPlayingInfoCenter and MPRemoteCommandCenter. No account or payment is required to play the first episode in the list.

That reply works because it gives a reproducible path and names the platform integrations that prove the feature is real, which beats any assertion about intent.

When it is really a different guideline

• A location purpose string that does not explain the use is 5.1.5.
• Using background execution to run downloaded code is 2.5.2.
• An entitlement declared for a feature that is not in the build at all edges into 2.3.1, hidden or undocumented features.

AppSubmit lists the background modes found in the uploaded build next to your release notes, so a plugin cannot add one quietly. plutil -p on your shipped plist gets the same answer free.

Source: Apple, App Store Review Guidelines, 2.5.4 (https://developer.apple.com/app-store/review/guidelines/#software-requirements)

Related: apple-guideline-5-1-5-location-services, apple-guideline-2-5-2-executable-code, apple-guideline-2-3-1-hidden-features