How to Fix App Store Guideline 2.5.4 Background Modes Rejection
Remove an unused UIBackgroundModes declaration or prove the reviewer-visible audio, location, VoIP, accessory, or task-completion feature that requires it.
Direct answer
Inspect the exact archived build and list every value under UIBackgroundModes. Remove any mode that the shipped app does not need for its user-facing purpose, including values inherited from a framework or target capability, then upload a corrected build. If a mode is essential, make the feature work from a clean install, give App Review the shortest path to start it, and show the expected behavior after the app moves to the background. Do not keep background audio, location, VoIP, external-accessory, or processing declarations merely to prevent suspension or run general work: Apple requires background services to be used for their intended purposes, and its background-task documentation points developers to the strategy suited to the actual task.
Match the wording in your rejection
The app declares background audio, but App Review cannot find persistent audible content
Either remove the audio mode from the submitted target or give the reviewer a working, numbered path that starts genuine user-requested audio and continues it while the app is backgrounded.
The app declares background location without a feature that needs continuous updates
Remove the location mode or demonstrate the specific active workflow that depends on background location. Do not justify continuous updates with a generic reminder, analytics, or marketing use case.
A VoIP or external-accessory mode appears even though the product has no matching service
Audit the built Info.plist, target capabilities, extensions, SDKs, and configuration plugins. Remove stale declarations unless the signed release contains the corresponding reviewer-verifiable functionality and required configuration.
The reviewer cannot locate a legitimate background feature
Treat this as a review-path problem only after reproducing the feature in the exact submitted build. Supply prerequisites, credentials, content, device steps, and a short recording rather than a general explanation.
What this rejection usually means
A 2.5.4 rejection is usually a mismatch between what the signed binary declares and what App Review can verify. Enabling a Background Modes capability writes values into the app's Info.plist, and build settings, extensions, dependencies, or generated configuration can make the archived result differ from the file you inspected in source control. The other common failure is legitimate functionality that is gated by an account, empty demo data, a permission state, downloaded media, paired hardware, or an undocumented start action. The recovery decision therefore starts with the distributed artifact, not a screenshot of an Xcode setting or a promise that background work exists.
Likely rejection signals
- The rejection names audio, location, VoIP, external-accessory, fetch, processing, or another UIBackgroundModes value
- The mode is enabled in one target or configuration but the corresponding feature was removed or never shipped
- A cross-platform plugin or SDK adds a background capability to the generated iOS project
- The feature works for a developer account but the review account has no playable content, route, trip, paired accessory, or required entitlement
- The foreground flow works, but the intended behavior stops, becomes silent, or cannot be controlled after backgrounding
- Review Notes describe the purpose without telling the reviewer how to start and observe it in the submitted build
Recovery plan
- Preserve the full rejection message and record the app version, build number, review device and OS when supplied, and the exact UIBackgroundModes value Apple cited. Do not change several unrelated capabilities before you can explain the mismatch.
- Inspect the archived app that corresponds to the submission. Read its built Info.plist and enumerate every UIBackgroundModes value across the main app and relevant extensions. Compare the Release configuration, target capabilities, generated project files, dependency manifests, and configuration plugins so an inherited value is not missed.
- Map each declared mode to one concrete user-facing feature and to the Apple framework or background strategy it actually uses. Record the user action that starts the work, what remains active after backgrounding, how the user observes or controls it, and when it stops. A mode with no defensible mapping should be removed.
- For an unused mode, disable the matching Background Modes capability or remove the generated Info.plist entry at its real source. Clean and archive again, then verify the signed product rather than only the editable plist. Confirm no other target or dependency reintroduces the value.
- For a real feature, test from a clean install using the review account and production-like backend. Cover permission grant and denial, empty and populated account state, foreground-to-background transition, interruption, relaunch, and termination. For audio, make playable content immediately available; for location, expose the active workflow; for accessories, document setup and any hardware requirement.
- If the work is not tied to an eligible continuous mode, select the documented background strategy that fits its timing and resource needs. Use system-scheduled background tasks for deferrable refresh or processing instead of mislabeling general execution as audio, location, or another continuous service.
- Update App Review information with numbered taps from launch to the feature, all prerequisites, a working account, representative content, and the observable background result. Attach a short recording when navigation, timing, or hardware setup could otherwise be ambiguous.
- Upload one corrected build when the binary or packaged configuration changed. In the reply, name the removed or retained mode, the exact build, the completed correction, and the verification path. If no binary change was needed, reply in the existing App Review conversation with evidence and request a retest.
- Escalate to an App Review Board appeal only when the same reviewed build demonstrably uses the declared mode for its intended purpose and a precise clarification did not resolve the factual dispute. Do not appeal to defend a mode that is unused or merely convenient for general background execution.
Evidence to prepare
- Full rejection text, app version, build number, and cited background mode
- UIBackgroundModes values extracted from the exact archived main app and relevant extensions
- Target-capability and dependency audit showing where each retained or removed value originates
- Feature map connecting every retained mode to a user action, intended purpose, observable background behavior, and stop condition
- Clean-install test results for the review account, required content, permissions, device state, background transition, interruption, and relaunch
- Short recording that shows the complete foreground start and the reviewer-verifiable background result
- Numbered Review Notes with working credentials, prerequisites, build number, and any accessory or content setup
Appeal or fix first?
Clarify or appeal when the exact submitted build already uses the cited mode for the intended purpose, the feature works under review conditions, and you can prove the complete path and background result. Start with a factual reply and request a retest; use a formal appeal only if Apple maintains a finding contradicted by release-specific evidence.
Fix and resubmit when the cited mode is unused, inherited accidentally, mapped to deferrable general work, or unsupported by the shipped user experience; also fix when the feature fails, lacks required content, or cannot be reached with the review account. Remove the smallest unnecessary declaration or repair the real workflow, then verify the new archive.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the app version, build number, and exact UIBackgroundModes value cited.
- State whether the value was removed or retained and name only changes present in the submitted build.
- For a retained mode, explain its intended user-facing purpose and provide numbered steps to start and observe it in the background.
- Provide working credentials, content, permissions, and hardware prerequisites without exposing secrets.
- Attach the shortest useful recording or artifact and ask for review of the corrected build or a retest of the documented behavior.
Frequently asked questions
Why is Apple citing UIBackgroundModes when my source Info.plist looks correct?
App Review evaluates the submitted binary. Target capabilities, Release configuration, extensions, SDKs, cross-platform plugins, and generated settings can change the built plist, so inspect the exact archived product.
Can I keep the audio background mode just to keep my app running?
No. Guideline 2.5.4 limits background services to their intended purposes. Keep the audio mode only for genuine user-requested audible content that requires background playback, not as a general execution workaround.
Should I remove background location if my app sometimes needs location?
Not automatically. First determine whether the user-facing feature truly needs continuous background location. If occasional, region-based, or another documented strategy meets the product requirement, remove the continuous mode and use the narrower approach.
Do I need a new build after removing a background mode?
Yes when the UIBackgroundModes value or implementation in the binary changes. Archive and upload the corrected build, then identify its build number in the reply.
When should I appeal a Guideline 2.5.4 rejection?
Appeal only when the exact reviewed build already uses the declared mode for its intended purpose and a precise reply with a working path and evidence did not resolve the factual disagreement. Otherwise, correct the declaration or feature and resubmit.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Apple App Review Guidelines — 2.5.4 Background Services. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.