Silent Push — esencia, tareas en segundo plano y configuración de entrega

Qué es Silent Push — esencia y propósito

Silent Push es un mecanismo de iOS que entrega datos al dispositivo sin ninguna notificación visual al usuario. A diferencia de un push estándar que muestra un banner, reproduce un sonido y aparece en el Centro de Notificaciones, un silent push “despierta” la aplicación en segundo plano y le pasa datos para procesarlos. El usuario nunca sabe de la entrega de dicha notificación — el resultado es contenido actualizado la próxima vez que abra la aplicación.

Diferencia de las notificaciones push normales

La diferencia clave radica en el payload JSON: un silent push contiene el indicador content-available: 1 y NO contiene alert, sound ni badge. Una notificación estándar con alert siempre se muestra al usuario, independientemente de content-available. Silent push solo funciona con content-available: 1 y sin alert — si añades alert, el sistema mostrará la notificación incluso con el indicador de entrega en segundo plano.

Cuándo usar Silent Push

Las notificaciones silenciosas son indispensables para escenarios donde los datos deben estar actualizados cuando el usuario abre la aplicación, pero sin distraerlo. Ejemplos: actualizar el feed de noticias en segundo plano, sincronizar suscripciones, descargar nuevo contenido para acceso sin conexión, actualizar widgets, invalidar caché. Silent Push también se usa para “calentar” la aplicación antes de una acción esperada del usuario.

Cómo funciona la entrega de notificaciones silenciosas

La entrega de Silent Push difiere significativamente de las notificaciones normales y sigue reglas de optimización de energía. El sistema iOS recibe la solicitud push de APNS, determina que es un silent push (content-available: 1) y decide si entregarlo basándose en múltiples factores: nivel de batería, modo de ahorro de energía, frecuencia de silent pushes anteriores, actividad de la aplicación y carga actual de CPU.

El rol de Power Nap y los modos en segundo plano

En dispositivos con chip Apple M y iOS 15+, el silent push se integra con el mecanismo Power Nap, que activa periódicamente el dispositivo para tareas en segundo plano. Power Nap consolida varios silent pushes en un período de actividad, reduciendo el consumo general de energía. El desarrollador no puede controlar Power Nap directamente — el sistema toma decisiones automáticamente según el comportamiento del usuario y el historial de uso de la aplicación.

La ventana de procesamiento de 30 segundos

Cuando el sistema entrega un silent push, la aplicación recibe la llamada a application(_:didReceiveRemoteNotification:fetchCompletionHandler:) en AppDelegate. El desarrollador debe llamar al completion handler en 30 segundos, pasando el resultado correcto (UIBackgroundFetchResult). Si el procesamiento no se completa a tiempo, el sistema puede limitar la frecuencia de silent pushes para esta aplicación o dejar de entregarlos por completo.

// Procesamiento de Silent Push en AppDelegate
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

Intervalos entre entregas

Apple no publica intervalos exactos entre silent pushes, pero según pruebas y documentación, se recomienda enviar no más de 2–3 notificaciones silenciosas por hora por dispositivo. Si se envían con más frecuencia, el sistema comienza a ignorar los silent pushes y los datos dejan de entregarse. Si se requiere sincronización más frecuente, considere usar URLSession con configuración en segundo plano o VoIP push.

Casos de uso de Silent Push

Silent Push se utiliza en una amplia gama de tareas donde los datos deben estar actualizados sin la participación activa del usuario. Veamos los casos de uso más efectivos de este mecanismo en aplicaciones iOS reales.

Actualización de contenido para acceso sin conexión

Las aplicaciones de noticias, lectores y viajes usan Silent Push para descargar nuevo contenido en segundo plano. Cuando el usuario abre la aplicación, los datos ya están cargados y disponibles incluso sin conexión a internet. Este enfoque mejora drásticamente la experiencia del usuario — las pantallas de carga vacías desaparecen y el contenido se muestra al instante. El servidor envía un silent push cuando aparecen nuevos artículos y la aplicación los descarga en segundo plano para lectura sin conexión.

Sincronización del estado de widgets

iOS WidgetKit actualiza los widgets según un horario, pero para actualizaciones instantáneas después de cambios en el servidor, se usa Silent Push. La aplicación en segundo plano procesa el silent push, actualiza el almacenamiento local de datos para widgets y actualiza forzosamente la timeline mediante WidgetCenter. El usuario ve información actualizada en el widget sin abrir la aplicación — tipos de cambio, pronóstico del tiempo, estado de entrega.

Invalidación de caché y limpieza de datos obsoletos

Cuando el servidor actualiza datos críticos (por ejemplo, reglas de tarificación, funciones disponibles para usuarios premium), Silent Push permite invalidar instantáneamente la caché local. Al abrir la aplicación, esta cargará datos frescos del servidor en lugar de usar la caché obsoleta. Esto es especialmente relevante para aplicaciones con contenido de pago o suscripciones.

Actualización de badge sin notificación visible

En algunos escenarios, el badge del icono de la aplicación debe actualizarse sin mostrar una notificación. Un Silent Push con el campo badge en el payload permite establecer el valor deseado del contador sin molestar al usuario con un banner. Por ejemplo, una aplicación de chat puede actualizar el badge con el número de mensajes no leídos sin mostrar cada nuevo mensaje como notificación si el usuario ya está en la aplicación.

Configuración de Silent Push: payload y capacidades

Para el funcionamiento correcto de Silent Push se requiere configuración en tres niveles: el proyecto de Xcode, el payload JSON en el servidor y el código de procesamiento en la aplicación. Cada nivel es crítico: saltarse cualquier paso hará que la notificación se entregue como normal o no se entregue en absoluto.

Configuración de capacidades en Xcode

En Xcode, debe activar la capacidad Push Notifications y Background Modes con la casilla Remote notifications marcada. Push Notifications genera un certificado para APNS, mientras que Remote notifications en Background Modes permite al sistema activar la aplicación al recibir un silent push. Sin Remote notifications, el silent push se entregará, pero la aplicación no se activará en segundo plano y los datos no se procesarán.

Estructura del payload JSON

Un payload de Silent Push debe contener la clave aps con content-available: 1 y NO debe contener alert, sound ni badge. Los campos personalizados se pasan al mismo nivel que aps y contienen datos para procesar: tipo de operación, identificadores de objetos, metadatos. Un payload sin content-available se tratará como notificación normal; con alert, será normal incluso con content-available.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

Procesamiento del lado del cliente

Al recibir un silent push, iOS llama a application(_:didReceiveRemoteNotification:fetchCompletionHandler:) antes de que la aplicación se vuelva visible. En este método, debe analizar userInfo, realizar el trabajo necesario (solicitudes de red, escrituras en Core Data, actualizaciones de caché) y siempre llamar al completionHandler con el resultado correcto en 30 segundos. No llamar al completionHandler es considerado un error por el sistema y afecta la frecuencia de futuros silent pushes.

Limitaciones y mejores prácticas

Silent Push no es un canal confiable de entrega de datos para operaciones críticas — es un mecanismo de optimización, no una sincronización garantizada. El desarrollador debe entender las limitaciones y diseñar el sistema para que la aplicación funcione correctamente tanto con silent push como sin él.

Limitaciones de entrega

iOS no garantiza la entrega de cada silent push. El sistema puede retrasar o cancelar la entrega cuando la batería está baja (menos del 20%), en modo de bajo consumo, después de silent pushes frecuentes o si la aplicación no se ha usado durante mucho tiempo. Estadísticas promedio de entrega según Apple: aproximadamente el 70–80% de los silent pushes se entregan en 5 minutos, el resto puede retrasarse o perderse.

Recomendaciones de Apple sobre Silent Push

Apple recomienda seguir varias reglas para un uso efectivo de silent push. No envíe más de 2–3 silent pushes por hora por dispositivo — superar el límite resulta en bloqueo. Use un payload compacto: el tamaño mínimo del payload acelera el procesamiento y reduce la carga de red. Llame siempre al completionHandler lo más rápido posible: cuanto más tarde el procesamiento, mayor la probabilidad de que el sistema restrinja los silent pushes en el futuro.

Alternativas a Silent Push

Para escenarios que requieren entrega garantizada o más tiempo de procesamiento, considere alternativas. VoIP push (PushKit) garantiza la entrega y da más tiempo, pero está destinado solo a aplicaciones VoIP. Background fetch (UIApplication background fetch) se inicia por el sistema según un horario, pero no puede ser iniciado por el servidor. WebSocket mantiene una conexión persistente pero consume más batería y no es adecuado para todos los tipos de aplicaciones.

Monitoreo y depuración

Para depurar Silent Push, use Console.app en Mac y filtre por el nombre de la aplicación. El sistema registra cada silent push con la etiqueta “background task” e indica si el procesamiento fue exitoso. En un dispositivo, verifique a través de Settings → Developer → Background Modes Logging. El seguimiento del lado del servidor se realiza mediante APNS Feedback Service para identificar notificaciones no entregadas.