Rechazo en App Store
Un rechazo por la 2.5.4 significa que tu app declara un modo en segundo plano, como Audio o Location updates, y el revisor no encontró ninguna función que lo necesite. O quitas el modo, o haces que la función funcione y sea fácil de probar. En las apps web empaquetadas el arreglo suele ser diez minutos en Xcode, más un fallo en tu reproductor de audio.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
La Directriz 2.5.4 permite que las apps multitarea usen servicios en segundo plano solo para sus fines previstos: VoIP, reproducción de audio, ubicación, finalización de tareas, notificaciones locales y similares. Apple compara la entrada UIBackgroundModes de tu Info.plist (en Xcode: la capacidad Background Modes en Signing & Capabilities) con lo que hace la app. Un modo declarado pero sin usar es un rechazo. Un modo usado para otra cosa, como reproducir audio en silencio para mantener viva la app, es peor.
La regla vecina, la 2.5.1, trata los permisos y los textos de propósito; nuestra guía sobre permisos sin usar se ocupa de eso. Esta página trata de los propios modos en segundo plano.
La redacción es concreta: la app declara compatibilidad con un modo (audio, location, voip, fetch o processing) en UIBackgroundModes, pero el revisor no encontró ninguna función que lo requiera, o no consiguió que la función siguiera funcionando con la app en segundo plano. Te piden que añadas la función o que quites la clave. En el caso de la ubicación, la nota suele añadir que la app debe dejar claro por qué necesita la ubicación mientras no está en uso.
| Modo en segundo plano (nombre en Xcode) | Uso legítimo en una app de WebViewGold | Qué comprueba el revisor | Quítalo si |
|---|---|---|---|
| Audio, AirPlay, and Picture in Picture | Audio de podcast, radio, música, audiolibro o meditación con la HTML Background Audio API; vídeo en Picture in Picture con startnativevideo:// | Inicia la reproducción, sale de la app, bloquea el teléfono y escucha | La app solo tiene sonidos cortos, vídeos de YouTube incrustados o nada de audio |
| Location updates | Registro de carreras o rutas en bici, seguimiento de repartidores, fichajes en obras, con backgroundlocation en true | Busca una función que necesite la ubicación con la app cerrada y lee el texto de propósito | Solo necesitas la ubicación con la app abierta ("cerca de mí", buscador de tiendas) |
| Remote notifications | Push con OneSignal, Firebase o Pushwoosh | Que existan notificaciones push | No usas push en absoluto |
| Background fetch, Background processing | Rara vez hace falta; la documentación menciona Background Processing solo para algunas configuraciones de ubicación en segundo plano | Qué tarea se ejecuta en segundo plano | Ninguna función programa trabajo en segundo plano |
| Voice over IP | Apps de llamadas nativas basadas en CallKit, no apps web con llamadas por WebRTC | Si las llamadas llegan con la app cerrada | Casi siempre, en una app web empaquetada |
¡Una forma estupenda de convertir tu web app en una app nativa! Entrega rápida y una manera genial de llevar tus apps a las tiendas sin tener que desarrollar una app nativa completa.
Hazlo primero en Xcode; la mayoría de los rechazos 2.5.4 terminan aquí.
Selecciona el target de WebViewGold, busca la capacidad Background Modes y anota cada casilla marcada. Después abre Info.plist y mira "Required background modes" (UIBackgroundModes); debería listar los mismos elementos.
Audio necesita un reproductor que siga sonando con el teléfono bloqueado. Location updates necesita backgroundlocation y una función que lo use. Remote notifications necesita un proveedor de push. Todo lo que no tenga función, fuera.
Quita las marcas, o elimina la capacidad si no queda nada. Los tutoriales de push y de ubicación a veces dejan casillas de más marcadas; es la causa más habitual de un 2.5.4 inexplicable.
Sin Location updates, borra también la descripción de uso de ubicación "Always" y conserva solo "When In Use" si tu app web sigue llamando a la API de geolocalización. Conserva en todos los casos la descripción de uso de rastreo; la documentación de WebViewGold la marca como obligatoria.
Las capacidades están en el binario, así que esto siempre requiere subir una compilación nueva. Enumera los modos eliminados en tu respuesta en el Centro de resolución.
Una app de audio es uno de los casos más sólidos para una app web empaquetada: el contenido vive en tu servidor y el contenedor nativo añade la reproducción en segundo plano. La HTML Background Audio API (con un breve vídeo de configuración en la documentación) mantiene el audio HTML sonando cuando los usuarios cambian de app o bloquean la pantalla. El revisor prueba justo eso, así que el reproductor de tu app web tiene que colaborar.
Tres fallos de la app web causan la mayoría de los rechazos de audio: el reproductor se pausa solo con visibilitychange o pagehide; una single-page app desmonta el componente del reproductor al cambiar de ruta, así que navegar detiene el sonido; o la reproducción depende del autoplay en lugar de un toque. Arréglalos en la app web (código más abajo) y prueba en un dispositivo real con la pantalla bloqueada durante un minuto entero.
La HTML Background Audio API está documentada para iOS. Para vídeo, la Native Video API reproduce un stream en el reproductor del sistema con Picture in Picture, que también depende del modo Audio, AirPlay, and Picture in Picture. El proyecto de Android también tiene un reproductor de vídeo nativo con Picture in Picture.
Arreglos típicos para un reproductor en React, Vue o JavaScript puro. Mantén vivo un único elemento de audio durante toda la sesión.
// 1) Elimina de tu componente de reproductor las pausas automáticas como esta:
// document.addEventListener("visibilitychange", () => { if (document.hidden) audio.pause(); });
// 2) Mantén UN solo elemento de audio fuera de tus rutas (p. ej., en el layout raíz)
const audio = document.getElementById("global-player"); // <audio id="global-player" preload="none">
// 3) Inicia la reproducción con un toque del usuario, nunca con autoplay
playButton.addEventListener("click", () => {
audio.src = episode.url; // URL directa de MP3, AAC o HLS
audio.play();
});
// 4) Opcional: metadatos en la pantalla de bloqueo (pruébalo en tu compilación; la compatibilidad depende de la versión de iOS)
if ("mediaSession" in navigator) {
navigator.mediaSession.metadata = new MediaMetadata({
title: episode.title,
artist: show.name,
artwork: [{ src: show.cover, sizes: "512x512", type: "image/png" }]
});
}La ubicación en segundo plano pasa la revisión cuando los usuarios se benefician claramente con la app cerrada: al registrar una carrera, al compartir la posición de un repartidor con los clientes que esperan o al fichar cuando un técnico llega a una obra. En WebViewGold pones backgroundlocation en true en Config.swift y añades Location updates en Background Modes. Según tu app web, puede que también necesites Background Processing, con tu bundle ID en "Permitted background task scheduler identifiers" en Info.plist. La documentación de geolocalización advierte de que esto necesita una justificación clara durante la revisión.
Los revisores no pueden salir a correr durante la revisión, así que haz visible la función: un botón explícito de "Iniciar seguimiento", un indicador mientras el seguimiento está activo, un botón para detenerlo y una breve grabación de pantalla en las notas de revisión que muestre cómo llegan los puntos con la app en segundo plano. Explica en tu propia interfaz, antes de que aparezca el diálogo del sistema, por qué la app necesita la ubicación con la app cerrada, y usa las mismas palabras en el texto de propósito. Pruébalo tú en un dispositivo real y confirma en tu servidor que llegan los puntos.
Si lo único que necesitas es una búsqueda "cerca de mí", olvídate de la ubicación en segundo plano; el permiso When In Use lo cubre. La página de la función de geolocalización muestra la configuración en primer plano.
O quitaste el modo, o explicas cómo probarlo. No mezcles las dos cosas para el mismo modo. La plantilla se queda en inglés porque App Review lee en inglés.
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]
UIBackgroundModes en Info.plist coincide con la capacidad, sin restos.backgroundlocation en true, un control para iniciar y detener y un texto de propósito que nombre la función.iOS entrega las notificaciones tanto si tu app se está ejecutando como si no. El modo Remote notifications permite despertar la app en segundo plano, y proveedores de push como OneSignal te piden activarlo durante la configuración. Mantenlo si usas push; quítalo si no.
Solo si el vídeo o su sonido deben seguir reproduciéndose con la app en segundo plano, o si usas Picture in Picture. Un vídeo que se detiene cuando el usuario sale de la app no necesita ningún modo en segundo plano.
No. Usar el modo de audio para algo distinto de una reproducción audible es justo lo que prohíbe la 2.5.4, y los revisores lo tratan como un uso indebido. Usa notificaciones push para que los usuarios vuelvan.
No como directriz de revisión, pero Android tiene sus propios obstáculos: la ubicación en segundo plano necesita un permiso aparte y una declaración en Play Console, y los servicios en primer plano deben declarar su tipo. El principio es el mismo: declara solo lo que necesita una función visible.
Solo la función que dependía de él. Si ninguna función usaba el modo, nadie lo nota. Si más adelante añades audio o seguimiento en segundo plano, vuelve a añadir el modo en esa actualización y descríbelo en las notas de revisión.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.