Notificaciones push silenciosas: cómo funcionan, configuración en iOS y Android y casos de uso

Casi todas las guías de notificaciones push hablan de los mensajes que el usuario ve. Las notificaciones push silenciosas son justo las que nunca verá, y hacen un trabajo completamente distinto.

Un push silencioso despierta tu app en segundo plano, ejecuta una tarea y la vuelve a dormir. Sin alerta, sin sonido, sin badge. El usuario abre la app y encuentra contenido fresco ya cargado. Ni se entera de que llegó un push. Y ese es justamente el punto.

En LATAM esto importa todavía más: con un parque de dispositivos Android dominante (más del 85% del mercado) y muchos equipos de gama media o entrada, mantener la app actualizada en segundo plano marca la diferencia entre una experiencia que se siente rápida y una que tarda en cargar con cada apertura. En esta guía verás cómo funcionan las notificaciones push silenciosas en iOS y Android, cómo se ve la implementación en código y cómo usarlas de forma estratégica dentro de la automatización del customer journey. De paso, verás cómo Pushwoosh gestiona la entrega multiplataforma de push silenciosos y los integra en flujos automatizados.

¿Qué son las notificaciones push silenciosas?

Las notificaciones push silenciosas son mensajes iniciados por el servidor que despiertan una app en segundo plano sin mostrarle nada al usuario. Sin alerta, sin sonido, sin badge. El sistema operativo recibe el push, activa la app brevemente, la app ejecuta su tarea en segundo plano y luego vuelve a dormir.

El contraste con un push estándar es simple: un push visible es un mensaje para el usuario; un push silencioso es una instrucción para la app.

¿Qué puede hacer una app en esos segundos en segundo plano?

• Traer contenido nuevo. Descargar los últimos artículos, el catálogo de productos actualizado o un feed refrescado para que esté listo cuando el usuario abra la app.
• Sincronizar datos. Actualizar el estado local con cambios que ocurrieron en el servidor o en otros canales: una compra hecha en el sitio web, un cambio de estado en un sistema de backend.
• Evaluar ubicación. Verificar si el usuario entró o salió de una geocerca sin necesidad de una notificación visible como disparador.
• Actualizar tags o datos de segmento. Devolver las señales de comportamiento más recientes al CDP para que la segmentación se mantenga precisa.
• Pre-cargar contenido para una notificación visible próxima. Preparar un mensaje in-app o un payload de rich push para que se renderice al instante cuando se dispare.

El valor práctico: los usuarios abren una app que ya está al día. Sin spinner de carga, sin datos obsoletos. Esa percepción de velocidad y frescura tiene un efecto medible en la retención, incluso cuando el usuario no sabría explicar por qué la app se siente bien.

Cómo funcionan las notificaciones push silenciosas

La cadena de entrega es la misma que la de un push normal: tu servidor envía un payload a APNs (iOS) o FCM (Android), el servicio lo entrega al dispositivo, el sistema operativo actúa. Lo que cambia es la estructura del payload y lo que hace el SO cuando llega.

El flujo de entrega

1. El servidor envía el payload. Tu backend o Pushwoosh envía un mensaje especialmente construido a APNs o FCM.
2. El servicio lo entrega al dispositivo. APNs o FCM enruta el payload al dispositivo correcto usando el device token almacenado.
3. El SO despierta la app. Al reconocer las marcas de push silencioso en el payload, el SO activa la app brevemente en segundo plano.
4. La app ejecuta la tarea en segundo plano. Tu código corre: trae datos, sincroniza estado, revisa ubicación, actualiza un tag.
5. La app indica que terminó. En iOS, la app llama a un completion handler. En Android, onMessageReceived() retorna. El SO vuelve a dormir la app.

La ventana de segundo plano es limitada. iOS da aproximadamente 30 segundos. En Android varía según el dispositivo y el estado de energía. Las tareas en segundo plano tienen que ser rápidas o estar diseñadas para funcionar dentro de esos límites.

Diferencias de payload: iOS vs. Android

El error más común en iOS es olvidar configurar apns-priority: 5 junto con apns-push-type: background. Si la prioridad queda en 10 (el valor por defecto de los push visibles), Apple puede rechazar el mensaje o mostrarlo visualmente aunque no tenga cuerpo de alerta. La prioridad baja es lo que le indica a APNs que esto es una tarea en segundo plano, no una notificación urgente.

En Android la regla crítica es más simple: nada de objeto notification en el payload de FCM. Si hay un objeto notification, Android lo trata como un push normal y lo muestra. Push silencioso = solo data.

Implementación en iOS

Configuración en Xcode

Activa Background Modes en Xcode antes de escribir una sola línea de código:

1. Abre tu proyecto y selecciona el target de tu app.
2. Ve a ‘Signing & Capabilities’ y haz clic en ’+ Capability’.
3. Agrega ‘Background Modes’ y marca ‘Remote Notifications’.

Tu App ID en el Apple Developer Portal debe tener Push Notifications habilitado. Regenera tus provisioning profiles después de hacer este cambio.

Registro para notificaciones remotas

Los push silenciosos siguen requiriendo el registro del dispositivo con APNs. Maneja esto en el AppDelegate:

import UIKit
import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions:
            [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        UNUserNotificationCenter.current().delegate = self
        UNUserNotificationCenter.current().requestAuthorization(
            options: [.badge, .sound, .alert]
        ) { granted, _ in
            if granted {
                DispatchQueue.main.async {
                    application.registerForRemoteNotifications()
                }
            }
        }
        return true
    }

    func application(_ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        let token = deviceToken.map {
            String(format: "%02.2hhx", $0) }.joined()
        // El SDK de iOS de Pushwoosh envía el token automáticamente
    }
}

Manejo del push silencioso

Este es el método que iOS llama cuando llega un push silencioso:

extension AppDelegate {

    func application(_ application: UIApplication,
        didReceiveRemoteNotification userInfo: [AnyHashable: Any],
        fetchCompletionHandler completionHandler:
            @escaping (UIBackgroundFetchResult) -> Void) {

        guard let aps = userInfo["aps"] as? [String: AnyObject],
              aps["content-available"] as? Int == 1 else {
            completionHandler(.noData)
            return
        }

        // Ejecuta aquí tu tarea en segundo plano
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

Llama siempre a completionHandler antes de que se cierre la ventana de 30 segundos. Si no lo haces, iOS puede terminar la app y limitar los próximos push silenciosos. Pasa .newData si trajiste algo, .noData si nada cambió, .failed si la tarea falló.

Payload de APNs para push silencioso

{
    "aps": {
        "content-available": 1
    },
    "update_type": "content_refresh",
    "content_id": "latest_feed"
}

Headers de APNs obligatorios junto con este payload:

• apns-push-type: background
• apns-priority: 5

Implementación en Android

Android es el sistema dominante en LATAM, así que aquí es donde se gana o se pierde gran parte de la experiencia. Vale la pena prestarle atención extra.

Configuración de FCM y manifest

Agrega el FirebaseMessagingService a tu AndroidManifest.xml:

<service
    android:name=".MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

Manejo de mensajes de data en Kotlin

Extiende FirebaseMessagingService e implementa onMessageReceived:

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // El SDK de Android de Pushwoosh envía el token automáticamente
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // Push silencioso = solo payload de data, sin objeto notification
        if (remoteMessage.data.isNotEmpty()
            && remoteMessage.notification == null) {
            handleSilentPush(remoteMessage.data)
        }
    }

    private fun handleSilentPush(data: Map<String, String>) {
        when (data["update_type"]) {
            "content_refresh" -> {
                // Trae contenido nuevo desde tu servidor
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // Envía los tags actualizados a Pushwoosh
                syncUserSegmentData()
            }
            "location_check" -> {
                // Evalúa el estado actual de la geocerca
                evaluateGeofences()
            }
        }
    }
}

Payload de FCM para push silencioso

El payload debe contener un objeto data y ningún objeto notification:

{
    "to": "DEVICE_TOKEN",
    "data": {
        "update_type": "content_refresh",
        "content_id": "latest_news_feed"
    }
}

Pon priority en ‘high’ solo para tareas urgentes en segundo plano. La prioridad estándar es suficiente para la mayoría de los casos de refresco de contenido y evita un impacto innecesario en la batería, algo crítico en los dispositivos de gama media tan comunes en la región.

Push silencioso multiplataforma con Pushwoosh

Gestionar push silenciosos a mano en iOS y Android significa mantener dos formatos de payload distintos, dos sets de headers de entrega y dos integraciones de SDK. Pushwoosh abstrae todo eso.

Cuando disparas un push silencioso a través de Pushwoosh —desde la UI o la API— la plataforma genera el payload correcto para cada plataforma de destino automáticamente. APNs recibe content-available: 1 con los headers correctos. FCM recibe un mensaje data-only. Configuras la campaña una sola vez.

La gestión de device tokens está centralizada. Los tokens de iOS, los de Android y las suscripciones de web push se almacenan y actualizan en un solo lugar. Cuando un token cambia (reinstalación, actualización de SO), Pushwoosh se encarga del refresco.

Para quienes no son del área técnica, Pushwoosh ofrece una UI para programar y disparar push silenciosos sin escribir un payload. Eso hace práctico integrar los push silenciosos en flujos del Customer Journey Builder junto con notificaciones visibles y mensajes in-app.

Casos de uso estratégicos

Las notificaciones push silenciosas son más valiosas justo cuando la visibilidad jugaría en tu contra. Estos son los escenarios donde encajan mejor que un push estándar.

Pre-fetch de contenido para apps de noticias y medios

Una app de medios que envía una alerta de última hora se beneficia de un push silencioso enviado 30 segundos antes. El push silencioso despierta la app, que trae el artículo y lo cachea localmente. Cuando se dispara la alerta visible, tocarla abre el artículo al instante. Sin esperar a que la nota cargue: algo especialmente valioso en LATAM, donde las conexiones móviles intermitentes y los planes de datos limitados hacen que una carga lenta cueste lectores.

Para apps con feeds personalizados, un push silencioso en las horas típicas de despertar pre-carga el contenido de la mañana antes de que el usuario abra la app. La app se siente rápida porque lo es: los datos ya están ahí.

Evaluación de geocerca sin un disparador visible

Un usuario pasa cerca de una tienda. El enfoque estándar: enviar una notificación push basada en ubicación. El problema: el usuario tiene que haber dado opt-in, el timing puede fallar y puede sentirse vigilado.

El enfoque con push silencioso: el servidor envía un push silencioso cuando el usuario está dentro de una región. La app verifica la geocerca exacta del lado del cliente. Si las condiciones coinciden, la app activa un mensaje in-app o una notificación local en el momento justo. La comunicación visible solo ocurre si la lógica pasa, no como disparador en sí. Útil, por ejemplo, para una cadena retail con sucursales físicas durante el Buen Fin o el Hot Sale, cuando el tráfico en tienda se dispara.

Mantener los datos de segmento precisos tras actividad fuera de la app

Un usuario hace una compra en tu sitio web —pongamos, desde un marketplace tipo MercadoLibre integrado a tu ecosistema—. Su segmento RFM debería actualizarse de inmediato. Pero la app no se entera hasta que el usuario la abre.

Un push silencioso enviado después de la compra web despierta la app en segundo plano, que sincroniza el último evento de compra con Pushwoosh. El usuario entra al segmento RFM correcto en tiempo real. Una campaña de seguimiento —recompensa de fidelización, cross-sell, secuencia de agradecimiento— se dispara con datos precisos. Para apps FinTech, ese mismo patrón mantiene actualizado el estado de un usuario tras una transacción sin obligarlo a reabrir la app.

Pre-carga de contenido para mensajes in-app

Los mensajes in-app que requieren un fetch al servidor para renderizarse pueden tener un lag perceptible. Un push silencioso enviado antes de que el usuario active el mensaje in-app pre-carga el contenido y lo guarda localmente. Cuando el mensaje se dispara, se muestra de inmediato.

Este patrón funciona bien para flujos de onboarding, anuncios de funciones y overlays promocionales donde el contenido es personalizado y no puede quedar hardcodeado en el binario de la app.

Mejores prácticas

Respeta los límites de throttling del SO

iOS limita los push silenciosos que llegan demasiado seguido. La guía de Apple es de aproximadamente 2-3 por hora, o como mucho uno cada 21 minutos. Las apps que superan esto pueden encontrar sus push silenciosos demorados o descartados sin ningún error.

El Doze mode y App Standby de Android restringen la ejecución en segundo plano cuando el dispositivo está inactivo. Los mensajes FCM de prioridad alta pueden despertar la app durante Doze, pero deben usarse con criterio. Los mensajes de prioridad estándar se posponen hasta que el dispositivo sale de Doze.

La regla práctica: envía push silenciosos solo cuando la tarea en segundo plano sea genuinamente urgente. Pre-cargar contenido una vez con una cadencia natural (en la mañana, o tras una actualización del lado del servidor) está bien. Enviar cada 10 minutos para mantener los datos frescos, no.

Mantén los payloads pequeños y las tareas rápidas

El payload del push silencioso debe ser una señal, no una transferencia de datos. Envía lo mínimo necesario para decirle a la app qué traer y de dónde. El fetch real de datos ocurre dentro de la app después de que llega el push.

Las tareas en segundo plano deben completarse con buen margen dentro del límite de tiempo. Si una tarea requiere más de unos segundos, diséñala para que sea interrumpible: guarda el progreso, llama al completion handler y retoma en la siguiente oportunidad. Las tareas largas en segundo plano arriesgan que el SO las termine y pueden afectar la batería lo suficiente como para que el usuario lo note.

Prueba en distintos estados de energía y variantes de OEM

El comportamiento del push silencioso varía muchísimo entre los OEM de Android, y esto pega más fuerte en LATAM, donde los dispositivos Xiaomi, Motorola, Samsung de gama de entrada y otras marcas asequibles dominan el mercado. Xiaomi, Huawei y OnePlus tienen optimizaciones de batería agresivas que pueden impedir por completo la ejecución en segundo plano de apps que no estén en la whitelist. Prueba en dispositivos reales de estos fabricantes, no solo en emuladores de Android stock.

En iOS, prueba en modo de bajo consumo y con la app forzada a cerrar. La entrega de push silenciosos en esos estados es menos confiable, y tu lógica de segundo plano debería manejar el caso en que la tarea no corrió antes de que el usuario abra la app.

Mide la efectividad a través de eventos posteriores

Los push silenciosos no producen métricas de clic. Mide su efectividad a través de los eventos que se supone deben disparar: content_refreshed, segment_updated, geofence_evaluated. Si esos eventos dejan de dispararse al ritmo esperado tras una campaña de push silencioso, la entrega está siendo limitada o el handler de segundo plano está fallando.

Pushwoosh Analytics muestra los eventos de la app junto a los datos de campaña. Mapea tus eventos de finalización de tarea en segundo plano contra los envíos de push silencioso para confirmar que el pipeline funciona.

Intégralos en la automatización de journeys, no en envíos sueltos

Un push silencioso enviado en aislamiento es una operación técnica. Un push silencioso embebido en un Customer Journey es una operación estratégica. Los patrones más útiles usan los push silenciosos como un paso que habilita una mejor interacción visible más adelante: actualizar el segmento antes del push promocional, pre-cargar el contenido antes del mensaje in-app, evaluar la geocerca antes de la alerta basada en ubicación.

El Customer Journey Builder de Pushwoosh soporta push silenciosos como pasos del journey junto con notificaciones visibles y mensajes in-app.

Mejora la frescura de tu app y la precisión de tus campañas con Pushwoosh

Las notificaciones push silenciosas son la capa de infraestructura debajo de mejores experiencias de usuario. Contenido fresco al abrir, datos de segmento precisos, interacciones disparadas por geocerca sin fricción: nada de esto funciona de forma confiable sin actualizaciones de la app en segundo plano.

Pushwoosh gestiona la entrega multiplataforma de push silenciosos, el formateo de payloads, la administración de tokens y la integración con el Customer Journey. Los desarrolladores obtienen abstracciones de SDK limpias; los equipos de marketing obtienen el push silencioso como un paso de primera clase en sus flujos automatizados. Con certificación SOC 2 Type I e ISO 27001:2022, y cumplimiento GDPR y HIPAA, es una base en la que los equipos de e-commerce y FinTech de LATAM pueden confiar.