Silent Push — essência, tarefas em segundo plano e configuração de entrega

O que é Silent Push — essência e propósito

Silent Push é um mecanismo do iOS que entrega dados ao dispositivo sem qualquer notificação visual ao usuário. Ao contrário de um push padrão que mostra um banner, reproduz um som e aparece na Central de Notificações, um silent push “acorda” o aplicativo em segundo plano e passa dados para processamento. O usuário nunca sabe sobre a entrega de tal notificação — o resultado é conteúdo atualizado na próxima vez que abrir o aplicativo.

Diferença das notificações push regulares

A diferença chave está no payload JSON: um silent push contém o sinalizador content-available: 1 e NÃO contém alert, sound ou badge. Uma notificação padrão com alert é sempre exibida ao usuário, independentemente de content-available. Silent push funciona apenas com content-available: 1 e sem alert — se você adicionar alert, o sistema exibirá a notificação mesmo com o sinalizador de entrega em segundo plano.

Quando usar Silent Push

Notificações silenciosas são indispensáveis para cenários onde os dados precisam estar frescos quando o usuário abre o aplicativo, mas o usuário não deve ser distraído. Exemplos: atualizar o feed de notícias em segundo plano, sincronizar assinaturas, baixar novo conteúdo para acesso offline, atualizar widgets, invalidar cache. Silent Push também é usado para “aquecer” o aplicativo antes de uma ação esperada do usuário.

Como funciona a entrega de notificações silenciosas

A entrega de Silent Push difere significativamente das notificações regulares e segue regras de otimização de energia. O sistema iOS recebe a solicitação push da APNS, determina que é um silent push (content-available: 1) e decide se deve entregá-lo com base em múltiplos fatores: nível da bateria, modo de economia de energia, frequência de silent pushes anteriores, atividade do aplicativo e carga atual da CPU.

O papel do Power Nap e dos modos em segundo plano

Em dispositivos com chip Apple M e iOS 15+, o silent push integra-se com o mecanismo Power Nap, que desperta periodicamente o dispositivo para tarefas em segundo plano. Power Nap consolida vários silent pushes em um período de atividade, reduzindo o consumo geral de energia. O desenvolvedor não pode controlar o Power Nap diretamente — o sistema toma decisões automaticamente com base no comportamento do usuário e no histórico de uso do aplicativo.

A janela de processamento de 30 segundos

Quando o sistema entrega um silent push, o aplicativo recebe uma chamada para application(_:didReceiveRemoteNotification:fetchCompletionHandler:) no AppDelegate. O desenvolvedor deve chamar o completion handler dentro de 30 segundos, passando o resultado correto (UIBackgroundFetchResult). Se o processamento não for concluído a tempo, o sistema pode limitar a frequência de silent pushes para este aplicativo ou parar de entregá-los completamente.

// Processamento de Silent Push no 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

A Apple não publica intervalos exatos entre silent pushes, mas com base em testes e documentação, recomenda-se enviar no máximo 2–3 notificações silenciosas por hora por dispositivo. Se enviadas com mais frequência, o sistema começa a ignorar silent pushes e os dados param de ser entregues. Se for necessária sincronização mais frequente, considere usar URLSession com configuração em segundo plano ou VoIP push.

Casos de uso do Silent Push

Silent Push é usado em uma ampla gama de tarefas onde os dados precisam estar atualizados sem a participação ativa do usuário. Vamos ver os casos de uso mais eficazes deste mecanismo em aplicativos iOS reais.

Atualização de conteúdo para acesso offline

Aplicativos de notícias, leitores e aplicativos de viagem usam Silent Push para baixar novo conteúdo em segundo plano. Quando o usuário abre o aplicativo, os dados já estão carregados e disponíveis mesmo sem conexão com a internet. Esta abordagem melhora drasticamente a experiência do usuário — telas de carregamento vazias desaparecem e o conteúdo é exibido instantaneamente. O servidor envia um silent push quando novos artigos aparecem e o aplicativo os baixa em segundo plano para leitura offline.

Sincronização de estado de widgets

O iOS WidgetKit atualiza widgets em um cronograma, mas para atualizações instantâneas após mudanças de dados no servidor, Silent Push é usado. O aplicativo em segundo plano processa o silent push, atualiza o armazenamento local de dados para widgets e atualiza forçadamente a timeline via WidgetCenter. O usuário vê informações atualizadas no widget sem abrir o aplicativo — taxas de câmbio, previsão do tempo, status de entrega.

Invalidação de cache e limpeza de dados obsoletos

Quando o servidor atualiza dados críticos (por exemplo, regras de precificação, recursos disponíveis para usuários premium), Silent Push permite invalidar instantaneamente o cache local. Na próxima abertura, o aplicativo carregará dados frescos do servidor em vez de usar cache obsoleto. Isso é especialmente relevante para aplicativos com conteúdo pago ou assinaturas.

Atualização de badge sem notificação visível

Em alguns cenários, o badge no ícone do aplicativo precisa ser atualizado sem mostrar uma notificação. Um Silent Push com o campo badge no payload permite definir o valor desejado do contador sem incomodar o usuário com um banner. Por exemplo, um aplicativo de chat pode atualizar o badge com o número de mensagens não lidas sem mostrar cada nova mensagem como uma notificação se o usuário já estiver no aplicativo.

Configuração do Silent Push: payload e capacidades

Para o funcionamento correto do Silent Push, é necessária configuração em três níveis: o projeto Xcode, o payload JSON no servidor e o código de processamento no aplicativo. Cada nível é crítico: pular qualquer etapa fará com que a notificação seja entregue como normal ou não seja entregue.

Configuração de capacidades no Xcode

No Xcode, você precisa ativar a capacidade Push Notifications e Background Modes com a caixa Remote notifications marcada. Push Notifications gera um certificado para APNS, enquanto Remote notifications em Background Modes permite que o sistema acorde o aplicativo ao receber um silent push. Sem Remote notifications, o silent push será entregue, mas o aplicativo não será ativado em segundo plano e os dados não serão processados.

Estrutura do payload JSON

Um payload de Silent Push deve conter a chave aps com content-available: 1 e NÃO deve conter alert, sound ou badge. Campos personalizados são passados no mesmo nível que aps e contêm dados para processamento: tipo de operação, identificadores de objetos, metadados. Um payload sem content-available será tratado como notificação normal; com alert, será normal mesmo com content-available.

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

Processamento do lado do cliente

Ao receber um silent push, o iOS chama application(_:didReceiveRemoteNotification:fetchCompletionHandler:) antes que o aplicativo se torne visível. Neste método, você precisa analisar userInfo, realizar o trabalho necessário (requisições de rede, gravações em Core Data, atualizações de cache) e sempre chamar o completionHandler com o resultado correto dentro de 30 segundos. Não chamar o completionHandler é considerado um erro pelo sistema e afeta a frequência de futuros silent pushes.

Limitações e melhores práticas

Silent Push não é um canal confiável de entrega de dados para operações críticas — é um mecanismo de otimização, não uma sincronização garantida. O desenvolvedor deve entender as limitações e projetar o sistema para que o aplicativo funcione corretamente tanto com silent push quanto sem ele.

Limitações de entrega

O iOS não garante a entrega de cada silent push. O sistema pode atrasar ou cancelar a entrega quando a bateria está baixa (abaixo de 20%), no modo de baixo consumo, após silent pushes frequentes ou se o aplicativo não for usado por muito tempo. Estatísticas médias de entrega segundo a Apple: cerca de 70–80% dos silent pushes são entregues dentro de 5 minutos, o restante pode ser atrasado ou perdido.

Recomendações da Apple sobre Silent Push

A Apple recomenda seguir várias regras para o uso eficaz de silent push. Não envie mais de 2–3 silent pushes por hora por dispositivo — exceder o limite resulta em bloqueio. Use um payload compacto: o tamanho mínimo do payload acelera o processamento e reduz a carga na rede. Chame sempre o completionHandler o mais rápido possível: quanto mais tempo o processamento levar, maior a probabilidade de o sistema restringir silent pushes no futuro.

Alternativas ao Silent Push

Para cenários que requerem entrega garantida ou mais tempo de processamento, considere alternativas. VoIP push (PushKit) garante a entrega e dá mais tempo, mas é destinado apenas a aplicativos VoIP. Background fetch (UIApplication background fetch) é iniciado pelo sistema em um cronograma, mas não pode ser iniciado pelo servidor. WebSocket mantém uma conexão persistente, mas consome mais bateria e não é adequado para todos os tipos de aplicativos.

Monitoramento e depuração

Para depurar Silent Push, use Console.app no Mac e filtre pelo nome do aplicativo. O sistema registra cada silent push com o rótulo “background task” e indica se o processamento foi bem-sucedido. Em um dispositivo, verifique através de Settings → Developer → Background Modes Logging. O rastreamento do lado do servidor é feito através do APNS Feedback Service para identificar notificações não entregues.