Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageWhat 2.5.4 says
Guideline 2.5.4 lets multitasking apps use background services only for their intended purposes: VoIP, audio playback, location, task completion, local notifications and similar. Apple compares the UIBackgroundModes entry in your Info.plist (in Xcode: the Background Modes capability under Signing & Capabilities) with what the app does. A mode that is declared but unused is a rejection. A mode used for something else, such as playing silent audio to keep the app alive, is worse.
The neighboring rule 2.5.1 covers permissions and purpose strings; our guide to unused permissions handles those. This page is about the background modes themselves.
What the rejection message usually says
The wording is specific: the app declares support for a mode (audio, location, voip, fetch or processing) in UIBackgroundModes, but the reviewer found no feature that requires it, or could not get the feature to keep working while the app was in the background. You are asked to either add the feature or remove the key. For location, the note often adds that the app must make clear why it needs location while it is not in use.
Background modes a web-wrapped app might declare
| Background mode (Xcode label) | Legitimate use in a WebViewGold app | What the reviewer checks | Remove it if |
|---|---|---|---|
| Audio, AirPlay, and Picture in Picture | Podcast, radio, music, audiobook or meditation audio via the HTML Background Audio API; Picture in Picture video via startnativevideo:// | Starts playback, leaves the app, locks the phone, listens | The app has only short sounds, embedded YouTube videos or no audio |
| Location updates | Run or ride tracking, delivery driver tracking, check-ins at job sites, with backgroundlocation set to true | Looks for a feature that needs location while the app is closed and reads the purpose text | You only need location while the app is open ("near me", store finder) |
| Remote notifications | Push via OneSignal, Firebase or Pushwoosh | That push exists | You do not use push at all |
| Background fetch, Background processing | Rarely needed; the docs mention Background Processing only for some background location setups | Which task runs in the background | No feature schedules background work |
| Voice over IP | Native calling apps built on CallKit, not web apps with WebRTC calls | Whether calls arrive with the app closed | Almost always, in a web-wrapped app |
Great way of converting your web app to a native app! Fast turn-around, and a great way to get your apps into the app stores without the need to develop a full native app!
Clean up the declared modes
Do this in Xcode first; most 2.5.4 rejections end here.
Open Signing & Capabilities
Select the WebViewGold target, find the Background Modes capability and note every checked box. Then open Info.plist and look at "Required background modes" (
UIBackgroundModes); it should list the same items.Map each mode to a feature you can demonstrate
Audio needs a player that keeps playing when the phone is locked. Location updates needs
backgroundlocationand a feature that uses it. Remote notifications needs a push provider. Anything without a feature goes.Uncheck the rest
Clear the boxes, or delete the capability if nothing remains. Push and location tutorials sometimes leave extra boxes checked; that is the most common source of an unexplained 2.5.4.
Remove the matching purpose strings
Without Location updates, delete the "Always" location usage description too and keep only "When In Use" if your web app still calls the geolocation API. Keep the tracking usage description in every case; the WebViewGold docs mark it as required.
Rebuild and bump the build number
Capabilities live in the binary, so this always needs a new upload. List the removed modes in your Resolution Center reply.
Background audio for podcasts, radio and audio courses
An audio app is one of the strongest cases for a web-wrapped app: the content lives on your server and the native shell adds background playback. The HTML Background Audio API (a short setup video in the docs) keeps HTML audio playing when users switch apps or lock the screen. The reviewer tests exactly that, so the player in your web app has to cooperate.
Three web-app bugs cause most audio rejections: the player pauses itself on visibilitychange or pagehide; a single-page app unmounts the player component on route changes, so navigating stops the sound; or playback depends on autoplay instead of a tap. Fix them in the web app (code below) and test on a real device with the screen locked for a full minute.
The HTML Background Audio API is documented for iOS. For video, the Native Video API plays a stream in the system player with Picture in Picture, which also relies on the Audio, AirPlay, and Picture in Picture mode. The Android project has a native video player with Picture in Picture as well.
Make the web player survive the background
Typical fixes for a React, Vue or plain JavaScript player. Keep one audio element alive for the whole session.
javascript
// 1) Remove auto-pausing like this from your player component:
// document.addEventListener("visibilitychange", () => { if (document.hidden) audio.pause(); });
// 2) Keep ONE audio element outside your routes (e.g., in the root layout)
const audio = document.getElementById("global-player"); // <audio id="global-player" preload="none">
// 3) Start playback from a user tap, never from autoplay
playButton.addEventListener("click", () => {
audio.src = episode.url; // direct MP3, AAC or HLS URL
audio.play();
});
// 4) Optional: lock screen metadata (test it on your build; support depends on the iOS version)
if ("mediaSession" in navigator) {
navigator.mediaSession.metadata = new MediaMetadata({
title: episode.title,
artist: show.name,
artwork: [{ src: show.cover, sizes: "512x512", type: "image/png" }]
});
}Background location: when it is justified and how to show it
Background location passes when users clearly benefit while the app is closed: recording a run, sharing a driver's position with waiting customers, checking in when a technician arrives at a site. In WebViewGold you set backgroundlocation to true in Config.swift and add Location updates under Background Modes. Depending on your web app, you may also need Background Processing, with your bundle ID under "Permitted background task scheduler identifiers" in Info.plist. The geolocation docs point out that this needs a clear justification during review.
Reviewers cannot go for a run during review, so make the feature visible: an explicit "Start tracking" button, an indicator while tracking runs, a stop button, and a short screen recording in the review notes that shows points arriving while the app is in the background. Explain in your own UI, before the system dialog appears, why the app needs location while it is closed, and use the same words in the purpose string. Test it yourself on a real device and confirm on your server that the points arrive.
If a "near me" search is all you need, drop background location entirely; the When In Use permission covers it. The geolocation feature page shows the foreground setup.
Resolution Center reply template
Either you removed the mode, or you explain how to test it. Do not mix the two for the same mode.
Reply in Resolution Center (choose option A or B)
Hello App Review team, Thank you for reviewing [App name] [version] ([build]). [Option A: mode removed] We removed the [audio / location / fetch / processing / voip] background mode. It was declared by mistake and no feature depends on it. The new build [number] declares only: [remaining modes, e.g. remote-notification for push notifications]. [Option B: mode in use] The app uses the [audio] background mode for [continuous podcast playback]. To test: 1. Log in with the demo account from App Review Information. 2. Open [Library] and tap Play on any episode. 3. Lock the device or switch to another app. Playback continues. [Location: 1. Tap Start tracking on the [Track] tab. 2. Put the app in the background. 3. The route keeps recording. A screen recording is attached to the review notes.] Best regards, [Name], [email], [phone]
Checklist
- Every checked background mode maps to a feature you can demonstrate in under a minute.
UIBackgroundModesin Info.plist matches the capability, with no leftovers.- Audio keeps playing with the screen locked and while navigating inside the app.
- Background location only with
backgroundlocationset to true, a start and stop control and a purpose string that names the feature. - Unused location purpose strings removed; the tracking usage description kept.
- The review notes explain how to test each mode, with a screen recording for anything that cannot be reproduced at a desk.
- A new build uploaded with a higher build number (see TestFlight testing).
Frequently asked questions
Do I need a background mode for push notifications to arrive?
Notifications are delivered by iOS whether your app runs or not. The Remote notifications mode lets the app be woken in the background, and push providers such as OneSignal ask you to enable it during setup. Keep it when push is on; remove it when you do not use push.
My app plays video. Do I need the audio mode?
Only if the video or its sound should keep playing while the app is in the background, or if you use Picture in Picture. Video that stops when the user leaves the app needs no background mode.
Can I play silent audio to keep my web app running in the background?
No. Using the audio mode for anything other than audible playback is exactly what 2.5.4 forbids, and reviewers treat it as misuse. Use push notifications to bring users back instead.
Does Google Play have the same rule?
Not as a review guideline, but Android has its own hurdles: background location needs a separate permission and a declaration in Play Console, and foreground services must declare their type. The principle is the same: declare only what a visible feature needs.
Will removing a background mode break the app for existing users?
Only the feature that depended on it. If no feature used the mode, nobody notices. If you add background audio or tracking later, add the mode back in that update and describe it in the review notes.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Cloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.