React Native y tareas en segundo plano: lo que los tutoriales básicos nunca dicen

La mayoría de las guías de React Native se detienen cuando “funciona en el emulador”. El problema es que en producción — en un teléfono real, con iOS gestionando agresivamente la memoria y Android variando según el fabricante — tus tareas en segundo plano se detienen. Silenciosamente. Sin registro. Sin error visible.

Resultado: sincronización de datos que ya no ocurre, notificaciones que no llegan, fetch que falla después de 3 días de uso. Y un usuario que desinstala.

Esto es lo que 15 años construyendo aplicaciones web y móviles nos enseñaron — y lo que la documentación oficial no documenta suficientemente.

---

Por qué las tareas en segundo plano realmente fallan (y no es tu código)

El primer error que cometen la mayoría de los desarrolladores: buscar el bug en su código. A menudo, el código es correcto. Es el sistema operativo trabajando en tu contra.

iOS y Android tienen filosofías radicalmente opuestas sobre la gestión de procesos en segundo plano. iOS es draconiano: la aplicación no tiene ninguna garantía de ejecución fuera de las ventanas explícitamente concedidas por el sistema. Android es teóricamente más permisivo, pero las capas de los fabricantes (Samsung, Xiaomi, Huawei) añaden sus propias capas de optimización de batería que matan los procesos sin previo aviso.

Lo que vemos concretamente con nuestros clientes que desarrollan apps React Native:

• Una tarea BackgroundFetch que funciona en desarrollo, pero se detiene después de 72 horas en producción en iOS
• Un servicio de geolocalización en segundo plano que se detiene en cuanto un usuario Xiaomi activa el “modo ahorro de energía”
• Workers que funcionan perfectamente en un Pixel (Android puro), pero mueren en un Galaxy S24

La documentación de React Native menciona estas limitaciones. No te dice cómo sortearlas de forma robusta.

---

Los tres enfoques — y por qué dos te decepcionarán

BackgroundFetch: útil, pero limitado

react-native-background-fetch es la solución más documentada. Funciona en iOS y Android, es sencilla de configurar, y te dará falsas esperanzas.

En iOS, el intervalo mínimo es de 15 minutos — y eso es una sugerencia, no una garantía. El sistema decide cuándo ejecutar la tarea según el historial de uso de la app, el nivel de batería y la conexión de red. En la práctica, tus tareas se ejecutan entre 15 minutos y varias horas después de la hora prevista.

Esto no es un bug. Es el comportamiento documentado de iOS.

Para sincronizaciones no críticas (actualización de contenido, precarga de datos), es aceptable. Para todo lo que deba ser puntual — pagos, alertas, actualización de stock — es insuficiente.

Headless JS Tasks en Android: potentes, frágiles

Android permite mediante HeadlessJS ejecutar JavaScript incluso cuando la app está en segundo plano. Esto es más fiable que BackgroundFetch en dispositivos Android “puros”. El problema llega con las capas de los fabricantes.

Lo que nadie te dice: los teléfonos Xiaomi, Oppo y Huawei representan una parte significativa del mercado. Y todos estos fabricantes tienen sistemas de gestión de batería que matan los procesos en segundo plano, a menos que el usuario vaya manualmente a los ajustes a desmarcar “optimización de batería” para tu app.

¿Cuántos usuarios hacen eso? Muy pocos.

Las notificaciones push silenciosas: la solución real para el tiempo real

Si tu necesidad es desencadenar una acción precisa en un momento preciso, deja de luchar contra las limitaciones de las tareas en segundo plano. Usa notificaciones push silenciosas.

El principio: tu servidor envía una notificación push sin contenido visible (silent push notification). La app se despierta, ejecuta su tarea, se vuelve a dormir. iOS garantiza 30 segundos de ejecución. Android es más generoso.

Esta es la arquitectura que usan WhatsApp, Slack y la mayoría de las apps críticas. No porque sea elegante — porque funciona en producción.

---

El stack que realmente funciona en producción

Después de probar varios enfoques en proyectos reales, esto es lo que recomendamos según el caso de uso.

Para la sincronización periódica no crítica (actualización de contenido, estadísticas, logs): Usa react-native-background-fetch con una estrategia de reintento. Nunca asumas que la tarea se ejecutó. Verifica del lado del servidor, y re-sincroniza al abrir la app si es necesario.

Para las acciones desencadenadas por el servidor (notificaciones, actualizaciones de datos críticos): Notificaciones push silenciosas vía Firebase Cloud Messaging (FCM) en Android, APNs en iOS. Prueba imperativamente en dispositivos reales, no solo en simulador.

Para la geolocalización continua: react-native-background-geolocation de Transistor Software es la referencia. Es de pago (alrededor de 400$/año para una app comercial). También es la única lib que gestiona correctamente los casos límite de iOS/Android en producción. Si tu app depende de la geoloc, es una inversión, no un coste.

“La fiabilidad de una app móvil se mide por lo que ocurre cuando nadie mira — cuando la pantalla está apagada, la batería al 15%, y el usuario en zona de señal débil.” — Principio que aplicamos sistemáticamente en auditoría móvil

---

Los errores de configuración que cuestan caro

Aquí es donde se pone interesante — y donde la mayoría de los proyectos se descarrilan.

Olvidar las capabilities de iOS

En iOS, cada tipo de tarea en segundo plano debe declararse en Info.plist y activarse en las Capabilities de Xcode. Background Fetch, Remote Notifications, Background Processing — si olvidas uno de estos flags, la tarea se ejecuta en desarrollo (donde las restricciones son más laxas) y falla en producción.

Esta es una de las causas más frecuentes de “funcionaba antes de pasar a producción”.

Ignorar el Doze Mode y App Standby en Android

Android 6+ introduce el “Doze Mode”: cuando el dispositivo está inactivo, los jobs en segundo plano se agrupan y difieren. Android 8+ añade restricciones aún más severas sobre los servicios en segundo plano.

La solución oficial: usar WorkManager a través de una lib nativa. react-native-background-fetch lo hace por debajo desde su versión 4. Si usas una versión anterior o una lib no mantenida, estás expuesto.

Verifica tus dependencias. Un rápido npm outdated puede revelar sorpresas.

No gestionar los timeouts

iOS te da 30 segundos. Android es variable. Si tu tarea supera este límite — fetch de red lento, procesamiento pesado, base de datos SQLite que va lenta — el sistema la mata. Sin excepción. Sin log limpio.

La regla: toda tarea en segundo plano debe tener un timeout explícito. Si no ha terminado en 25 segundos, debe terminar limpiamente por sí sola, guardar su estado, y reanudar en el próximo ciclo.

---

Probar en condiciones reales: el protocolo que usamos

Los emuladores no reproducen los comportamientos en segundo plano. Punto. Debes probar en dispositivos reales, con restricciones reales.

Nuestro protocolo mínimo antes de lanzar una funcionalidad de background processing:

Dispositivo 1 — Android puro: Un Pixel o un dispositivo Android One. Valida que tu código funciona sin capa de fabricante.

Dispositivo 2 — Samsung Galaxy: Prueba el comportamiento con la capa Samsung, que es la más extendida.

Dispositivo 3 — iPhone con iOS reciente: Valida las restricciones de Apple, que evolucionan con cada versión mayor.

Para cada dispositivo, el escenario de prueba:

1. Lanzar la app, ponerla en segundo plano
2. Apagar la pantalla, esperar 30 minutos
3. Verificar si la tarea se ejecutó
4. Repetir con batería por debajo del 20%
5. Repetir con el modo ahorro de energía activado

Es tedioso. Es lo que separa una app que aguanta en producción de una app que genera tickets de soporte a las 3 de la madrugada.

---

La estrategia de resiliencia: nunca asumir que la tarea se ejecutó

Aquí está el cambio de mentalidad más importante: diseña tu app como si las tareas en segundo plano pudieran no ejecutarse nunca.

Esto implica:

Una sincronización en primer plano como fallback. En cada apertura de la app, verifica si hay datos que sincronizar. Si la tarea en segundo plano falló, el primer plano recupera el retraso.

Un timestamp de última ejecución. Almacena localmente cuándo se ejecutó la tarea por última vez. Si el retraso es anormal, desencadena una resincronización inmediata.

Indicadores del lado del servidor. No confíes únicamente en el cliente. Tu servidor debe saber si un dispositivo está “atrasado” y adaptar sus respuestas en consecuencia.

Esto no es sobre-ingeniería. Es lo que hacen todas las apps móviles críticas. Gmail, Notion, Slack — todos tienen una lógica de recuperación en primer plano porque todos saben que el background processing no es 100% fiable.

“Un sistema robusto no es el que nunca falla. Es el que se recupera solo.”

---

Lo que esto cambia concretamente para tu proyecto

Si desarrollas una app React Native con necesidades en segundo plano, aquí están los tres puntos accionables que recordar:

1. Elige tu stack según tu caso de uso real, no según el primer tutorial de Medium que leíste. BackgroundFetch para lo no crítico, silent push para el tiempo real, libs especializadas para la geoloc.

2. Prueba en dispositivos reales, con restricciones reales. Emulador = falsa seguridad. Un Samsung en modo ahorro de energía te revelará más bugs en 30 minutos que 10 horas en simulador.

3. Diseña para el fallo. Tu tarea en segundo plano va a fallar. No siempre, no en todos los dispositivos, pero va a fallar. Tu arquitectura debe anticiparlo.

---

Conclusión: la fiabilidad se construye, no se supone

El background processing en React Native no es un problema de código. Es un problema de arquitectura, configuración y pruebas en condiciones reales.

Los tutoriales básicos te muestran cómo ejecutar una tarea. No te muestran cómo ejecutar una tarea de forma fiable, en todos los dispositivos, durante 18 meses de producción. Ahí es donde se marca la diferencia entre una app que los usuarios conservan y una app que desinstalan.

En GDM-Pixel, cuando intervenimos en una auditoría de una app móvil que “ya no funciona como antes”, las tareas en segundo plano están entre las tres primeras cosas que verificamos. Porque sabemos que es ahí donde viven los bugs silenciosos.

¿Tu app React Native tiene comportamientos erráticos en producción? Hacemos auditorías técnicas móviles — diagnóstico honesto, recomendaciones accionables, sin venderte una reescritura si no es necesario. Contáctanos para hablarlo.