Devoria
Guideline 2.5.4: Apple rechaza un modo en segundo plano
Por Mehdi Azizi
Publicado el , 9 min
Guideline 2.5.4: Apple rechaza un modo en segundo plano sin función que lo use. Quita la clave o muéstrale al revisor el sonido, la ubicación o la llamada.
La guideline 2.5.4 limita los modos en segundo plano a su uso previsto: sonido, ubicación, llamadas VoIP, finalización de tareas, notificaciones locales. El rechazo llega cuando tu Info.plist declara uno de estos modos y el revisor no encuentra ninguna función que lo necesite. Quita la clave si nada la usa; si no, muéstrale la función al revisor en treinta segundos.
Publico mis propias apps iOS con Expo. Solys, mi despertador con minijuegos, declara el modo audio: lo quité y luego lo volví a poner por otra razón. Esta guía se basa en el texto de Apple, en rechazos publicados por otros desarrolladores y en mis proyectos. Para el panorama general de los motivos, lee por qué Apple rechaza una app.
¿Qué dice la guideline 2.5.4?
La regla cabe en una frase, en la sección 2 "Performance", apartado 2.5 "Software Requirements", de las App Review Guidelines: "Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc."
En pocas palabras: un servicio en segundo plano solo sirve para aquello para lo que existe. De ahí el título "Guideline 2.5.4 - Performance - Software Requirements".
Por defecto, una app que pasa a segundo plano queda suspendida. Para seguir funcionando, declara uno o varios modos en la clave UIBackgroundModes de su Info.plist. La documentación de Apple sobre los modos en segundo plano pide usarlos con moderación, por la batería, y preferir otra solución cuando exista. Cada modo declarado es una promesa que el revisor puede verificar.
Los modos en segundo plano y su uso previsto
| Modo | Clave | Uso previsto |
|---|---|---|
| Audio, AirPlay, PiP | audio | Sonido audible de fondo |
| Ubicación | location | Ubicación continua |
| Voz sobre IP | voip | Llamadas con CallKit |
| Obtención | fetch | Contenido de red periódico |
| Procesamiento | processing | Tareas programadas |
| Notificaciones remotas | remote-notification | Push de contenido nuevo |
Esta tabla resume la página de Apple. En los rechazos publicados en los foros, audio, location y voip son los que más aparecen.
¿Qué significa el mensaje de rechazo 2.5.4?
El mensaje nombra el modo en cuestión. Dos ejemplos publicados por desarrolladores en los foros de Apple:
- Audio: "Your app still declares support for audio in the UIBackgroundModes key in your Info.plist but did not include features that require persistent audio." Lo que sigue aclara que la clave
audioestá pensada para apps que reproducen contenido audible en segundo plano, como un reproductor de música. Propone dos salidas: agregar ese contenido o quitar la clave (hilo del foro). - Ubicación: en un hilo de diciembre de 2024, Apple no encontró ninguna función, aparte del seguimiento de empleados, que requiriera ubicación permanente, y escribió que ese uso por sí solo no es apropiado.
Mi lectura: el revisor no lee tu código, busca una función. Tiene que poder iniciarla, pasar la app a segundo plano y comprobar que sigue funcionando.
También existe el caso contrario. En un hilo de mayo de 2026, una app de lectura en voz alta, que usaba de verdad el modo audio, fue rechazada varias veces: el revisor no lograba activar el sonido. Otro desarrollador escribe ahí que, en su opinión, un video adjunto destrabó su caso. Es un testimonio, no una regla de Apple.
¿De dónde sale la clave si tú no la agregaste?
Con Expo, son los plugins de configuración los que llenan el Info.plist en el prebuild. Así que un modo en segundo plano puede entrar en tu binario sin que lo hayas decidido.
El plugin expo-audio, con su configuración por defecto
La documentación de expo-audio lo indica: la opción enableBackgroundPlayback vale true por defecto y, en iOS, agrega el modo audio. Basta con declarar el plugin en su forma corta, "expo-audio", para declarar el modo.
Eso fue lo que encontré al revisar TradaZen antes de su primer envío: sonidos cortos de interfaz en primer plano, pero un plugin declarado en forma corta. La corrección cabe en app.json:
{
"expo": {
"plugins": [["expo-audio", { "enableBackgroundPlayback": false }]]
}
}
Otros paquetes agregan un modo a su manera. La opción isIosBackgroundLocationEnabled de expo-location agrega location solo si la activas. expo-background-task, en cambio, agrega processing en el prebuild en cuanto se instala.
La carpeta ios/ que conserva la clave antigua
Segunda trampa, vivida con Solys en julio de 2026. Había quitado audio de app.json, pero la clave seguía en ios/Solys/Info.plist, generado antes. Un prebuild sin --clean modifica ese proyecto en lugar de recrearlo, y el plugin agrega la clave sin quitarla nunca. Un build local la habría incluido. Un build de EAS en la nube parte de un prebuild nuevo cuando ios/ está ignorado por git, que era mi caso.
Antes de cada build, verifico lo que realmente se va a enviar:
npx expo config --type introspect --json | grep -o '"UIBackgroundModes":\[[^]]*\]'
npx expo prebuild --clean --platform ios
El primero lista los modos que el prebuild escribirá en el Info.plist. El segundo recrea el proyecto nativo para un build local, borrando la carpeta ios/. En Solys, el primero muestra "UIBackgroundModes":["audio"]; en TradaZen, nada: ambos resultados son intencionales.
Agregar o quitar un modo modifica el Info.plist, y por lo tanto el binario: necesitas un build nuevo, una actualización remota no basta. La documentación de EAS Update clasifica estos cambios entre los que requieren un binario nuevo, igual que con ITMS-90683.
Solys: un modo audio declarado, con una razón real
Solys es un despertador, pero el modo audio no sirve para hacer sonar la alarma: el timbre pasa por AlarmKit, el servicio de alarmas de Apple disponible desde iOS 26 (documentación de AlarmKit). Es el sistema el que suena, incluso en modo silencio, no la app.
La historia de la clave, porque el razonamiento importa más que la línea:
- A finales de julio de 2026, la quito. Nada reproducía sonido en segundo plano: los efectos de sonido de los minijuegos se quedan en primer plano, y la alarma no depende de la app.
- Dos días después, la vuelvo a poner, con la escucha nocturna. Esta opción graba los ruidos de tu noche con el micrófono y los analiza en el iPhone. La grabación tiene que continuar con la pantalla bloqueada, y la documentación de expo-audio indica que la opción de grabación en segundo plano también agrega el modo
audio.
La justificación cambió de naturaleza: el modo sirve para grabar, no para reproducir. Tres salvaguardas, visibles en la app:
- la escucha es una opción desactivada por defecto, que se activa desde los ajustes o desde la rutina de la noche;
- tiene su propia pantalla de consentimiento, como exige la regla 2.5.14 para toda grabación, y nada sale del teléfono;
- el micrófono se cierra diez minutos antes de la alarma, para que la escucha y el timbre nunca se estorben.
No puedo garantizar que un revisor siempre acepte esta declaración. Sí sé decir, para cada elemento, para qué sirve y dónde verlo.
Los despertadores que mantenían la app despierta
Antes de AlarmKit, una app de despertador de terceros no podía sonar como la alarma de Apple. Por eso algunas bibliotecas mantenían la app despierta: la documentación del paquete de Flutter alarm2 describe un reproductor de audio silencioso que funciona hasta la alarma. Pero un sonido mudo no hace oír nada. Desde iOS 26, AlarmKit vuelve innecesario ese rodeo.
Mantener o quitar el modo: la tabla de decisión
| Tu situación | Qué hacer |
|---|---|
| Sonidos cortos en primer plano | Quitar audio |
| Música o audiolibro | Mantenerlo, mostrarlo |
| Grabación larga | Mantenerlo + consentimiento |
| Despertador o temporizador | AlarmKit (iOS 26) |
| Ubicación de vez en cuando | Cambios significativos |
| Sincronización sin urgencia | fetch o processing |
| Llamadas de audio o video | voip con CallKit |
Para la ubicación, la página de Apple menciona el servicio de cambios significativos como alternativa al modo location.
Los otros apartados de la 2.5: 2.5.1 y 2.5.2
2.5.1: API públicas y frameworks en su lugar
"Apps may only use public APIs and must run on the currently shipping OS." La app usa solo API públicas, funciona en la versión actual del sistema y abandona lo que está obsoleto. Igual que con la 2.5.4, cada framework sirve para su uso previsto, mencionado en la descripción: HealthKit para la salud, HomeKit para la casa conectada. Si una biblioteca llama a una API privada, es tu app la que carga con el rechazo.
2.5.2: nada de código descargado que cambie la app
La app sigue siendo autónoma dentro de su paquete. No puede "download, install, or execute code which introduces or changes features or functionality of the app". Solo las apps educativas que enseñan a programar tienen una excepción limitada, con un código totalmente visible y editable por el usuario.
Con Expo, esto afecta a EAS Update, cuya documentación recuerda que las actualizaciones deben respetar las reglas del App Store. Usa las actualizaciones remotas para corregir, nunca para entregar una función que el revisor no vio. Una corrección relacionada con la revisión pasa por un build nuevo, como explico en la guía de la guideline 2.1.
¿Cómo responder a un rechazo 2.5.4?
La conversación ocurre en la sección App Review de tu app, donde respondes al mensaje de App Review. Dos casos:
- El modo no sirve para nada: quítalo, haz un build nuevo, verifica la introspección y responde en dos frases.
- El modo sirve a una función real: responde con la ruta exacta y un video corto, y luego repite ese texto en las notas de revisión de cada versión.
La plantilla que yo usaría, para adaptar (quita la frase sobre la alarma si tu app no tiene una):
Hello,
The "audio" background mode is used only by [feature], an
optional feature that [records / plays] audio while the
device is locked. It is off by default.
How to test:
1. Open [screen] and turn on [feature].
2. Accept the microphone permission if asked.
3. Tap [button], then lock the device.
[What the reviewer will hear or see.]
Our alarm does not use this mode: it is scheduled with
AlarmKit and rings through the system.
Attached: a short screen recording of these steps.
Best regards,
La checklist 2.5.4 antes del envío
- La introspección de Expo muestra solo los modos que quieres, y sabes nombrar la función de cada uno.
- Ningún plugin está declarado en forma corta si agrega un modo por defecto, como expo-audio.
- Tu carpeta
ios/local no conserva ninguna clave antigua, o compilas desde un prebuild limpio. - La función se activa rápido, sin ajustes ocultos, y las notas de revisión dicen qué modo sirve para qué y cómo probarlo.
- Toda grabación pide un consentimiento explícito y muestra un indicador visible. Las reglas sobre las solicitudes de permisos están en la guía de la guideline 5.1.1.
- Para un despertador, el timbre pasa por AlarmKit, no por un sonido reproducido desde la app.
Revisar tu proyecto antes del envío
El Review Kit reúne mi checklist previa al envío, plantillas de notas para el revisor y skills de Claude Code que revisan tu proyecto. Si quieres una mirada humana, reserva una hora conmigo: leemos juntos el mensaje de Apple y tu Info.plist, por videollamada. El proceso completo está en la página app rechazada por Apple.
¿Estás preparando tu primer lanzamiento? Haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist contra los rechazos de Apple.
Nadie puede garantizar que Apple aceptará tu app. Un modo en segundo plano bien justificado, en cambio, se defiende en treinta segundos.
Preguntas frecuentes
¿Qué significa "Guideline 2.5.4 - Performance - Software Requirements"?
Es el título del rechazo cuando Apple considera que un modo en segundo plano de tu Info.plist no se usa para su fin previsto. El mensaje nombra el modo y propone mostrar la función que lo usa o quitar la clave.
¿Hace falta un build nuevo después de un rechazo 2.5.4?
Si quitas o modificas un modo, sí: la clave está en el Info.plist, y por lo tanto en el binario. Si el modo está justificado, puede bastar una respuesta con la ruta exacta y un video.
¿Se puede mantener el modo audio para algunos sonidos de interfaz?
No. Los sonidos cortos reproducidos en primer plano no lo necesitan. Con Expo, configura enableBackgroundPlayback en false en el plugin expo-audio.
¿Una app de despertador necesita el modo audio?
No para sonar, si se apoya en AlarmKit, disponible desde iOS 26: es el sistema el que reproduce la alarma. En Solys, el modo audio sirve para la escucha nocturna, que graba con la pantalla bloqueada.
¿Por qué Apple menciona la 2.5.4 si yo no declaré nada?
Puede que un plugin lo haya hecho por ti: expo-audio agrega el modo audio por defecto, y una carpeta ios/ antigua puede conservar una clave que quitaste de tu configuración. Verifícalo con npx expo config --type introspect.
