Saindo do OneSignal? 9 ferramentas para uma migração segura do SDK de push em apps grandes

Num app pequeno, a migração do SDK do OneSignal significa trocar 1 chamada de init e um click handler. Num app grande, o OneSignal está espalhado em dezenas de lugares: tags definidas no módulo de perfil, um external user ID na autenticação, click handlers na navegação, triggers de in-app em algum canto do checkout.

Esqueça 1 dessas chamadas e nada quebra. Os segmentos vão se desalinhando em silêncio, os deep links abrem a tela inicial e o push que trazia os usuários de volta para de chegar.

Este guia reúne 9 ferramentas que deixam a troca segura, agrupadas nas 5 etapas de uma migração: mapear, substituir, testar, liberar e monitorar. Num mercado Android-first como o Brasil, com mais de 85% dos aparelhos em Android, a etapa de teste e liberação no Google Play é a que mais pesa no resultado.

Para o lado do provedor, veja o nosso guia completo de migração do OneSignal para o Pushwoosh.

Por que migrações de SDK de push quebram em apps grandes

Um SDK de push toca mais partes do código do que a maioria das bibliotecas de terceiros. Normalmente, 4 coisas dão errado:

• Chamadas espalhadas. Tags, external user IDs e click handlers vivem em módulos diferentes, às vezes em repositórios diferentes. Uma busca de texto por “OneSignal” encontra as óbvias e deixa passar os wrappers.
• Dependências escondidas. Eventos de analytics, deep links e testes A/B costumam depender de callbacks do SDK. Remova o callback e algum dashboard lá na frente fica zerado.
• 2 SDKs, 1 build. 2 SDKs de push no mesmo app disputam os mesmos callbacks de notificação. É por isso que o guia de migração do Pushwoosh recomenda remover o SDK do OneSignal na mesma release que adiciona o novo.
• Falhas silenciosas. Um push não entregue não gera erro. Os relatórios de crash continuam limpos.

O fluxo de migração, passo a passo

Cada etapa tem o próprio jeito de dar errado e as próprias ferramentas.

9 ferramentas para uma migração segura do SDK do OneSignal

Etapa 1. Mapeie cada chamada do OneSignal

1. CodeAlive: melhor para mapear chamadas do SDK em codebases grandes e com vários repositórios

O CodeAlive dá aos agentes de IA de programação um contexto preciso de toda a codebase e reduz os tokens que eles gastam procurando por ele. É um context engine feito para codebases com mais de 1 milhão de linhas: busca semântica mais um grafo de relações entre arquivos, símbolos, chamadas, dependências e testes, servido via MCP e API.

O que ele faz na migração: antes de alguém editar código, você pergunta ao CodeAlive onde o OneSignal é usado e o que depende dele. O grafo de relações mostra chamadas além das óbvias: wrappers, callbacks dos quais o analytics depende, testes que fazem mock do SDK. O mesmo contexto vai para o agente de IA que faz a substituição.

Principais recursos:

• Recuperação híbrida: busca semântica, correspondência léxica e navegação no grafo em 1 consulta
• Índice atualizado a cada push, então o mapa continua em dia enquanto a branch da migração avança
• Ferramentas MCP, incluindo semantic_search, grep_search e chat, para Cursor, Claude Code, Codex, Windsurf, Zed, Continue e Cline
• Review de pull requests com IA que leva o sistema inteiro em conta
• Provedores Git: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea. IDEs: VS Code e JetBrains

Prós:

Etapa 2. Troque o SDK e migre a audiência

2. Pushwoosh: melhor plataforma de destino com importação da audiência

O Pushwoosh é uma plataforma de engajamento de clientes com push, in-app, email, SMS e WhatsApp. Numa migração, o time do Pushwoosh importa a sua audiência enquanto os seus devs publicam o novo SDK.

O que ele faz na migração: os tokens de push de iOS, Android e Huawei são importados e continuam funcionando, porque os tokens pertencem ao seu app e às suas chaves. Assinantes de email e SMS também entram na importação. O external_user_id é mapeado para o User ID do Pushwoosh (peça essa coluna no export do OneSignal, ela não vem no export padrão), e as tags são recriadas a partir do seu export. O web push é a exceção: nenhum provedor consegue transferir inscrições do navegador, então o Web SDK do Pushwoosh reinscreve os visitantes de forma silenciosa.

Principais recursos:

• SDKs para iOS e Android, além de React Native, Flutter, Unity, Capacitor, Cordova, MAUI, Expo e outros
• Importação da audiência que roda em paralelo com a release do SDK, então os dispositivos ficam alcançáveis antes de os usuários atualizarem o app
• Dispositivos de teste para ver o push num aparelho real antes de enviar

Prós:

Preço: o plano só de push custa US$ 7 por 1.000 MAU, com os primeiros 1.000 MAU grátis. Compare com a sua conta atual na calculadora de custos do OneSignal.

Etapa 3. Teste o registro e a entrega

3. Apple Push Notifications Console: melhor para testar a entrega no iOS via APNs

O Push Notifications Console é a ferramenta web da Apple para enviar notificações de teste via APNs. É um jeito rápido de descartar o provedor quando um push no iOS não chega.

O que ele faz na migração: você envia um push direto para um device token e confere se o APNs aceitou e entregou. Se ele chega por aqui, mas não pelo novo provedor, comece checando a configuração do provedor.

Principais recursos:

• Notificações de teste para um dispositivo, com reenvio depois de alterar atributos
• Logs de entrega que mostram o caminho de uma notificação pelo APNs, no ambiente de desenvolvimento
• Validação de tokens para um ambiente e tipo de push específicos
• Métricas de entrega para notificações de teste e de produção

Prós:

4. Firebase Cloud Messaging: melhor para testar pushes no Android por token

Os pushes no Android em aparelhos com Google Play services passam pelo Firebase Cloud Messaging (aparelhos Huawei sem Google services usam o HMS Push Kit). O console do Firebase consegue enviar uma mensagem de teste para 1 registration token, o que faz dele um testador de notificações push simples para builds Android. Como a maior parte da sua base no Brasil está em Android, vale testar em mais de um aparelho, inclusive nos de entrada.

O que ele faz na migração: depois que o novo SDK registra um dispositivo, você cola o token FCM dele no console e envia um teste. Se chegar, o token e a configuração do Firebase estão certos.

Principais recursos:

• Envio de mensagem de teste para um registration token FCM específico, direto do console
• Sem código para uma checagem rápida, além de ler o token no dispositivo

Prós:

5. Proxyman: melhor para inspecionar o tráfego e os payloads do SDK

O Proxyman é um proxy de depuração HTTP para macOS, Windows e Linux. Ele mostra o que o SDK de push realmente envia: chamadas de registro, atualizações de user ID, requisições de tags.

O que ele faz na migração: você roda o app com o novo SDK e observa as requisições. Se uma tag nunca sai do dispositivo, você vê isso aqui, muito antes de um segmento aparecer vazio.

Principais recursos:

• Captura de tráfego HTTPS de apps em dispositivos, simuladores e emuladores
• Captura em um clique no iOS Simulator e no Android Emulator nos planos pagos
• Breakpoints e Map Local/Remote para editar requisições e respostas

Etapa 4. Libere em etapas

6. fastlane: melhor para automatizar releases em etapas

O fastlane é uma plataforma open source para automatizar o deploy de iOS e Android. Numa migração, o valor dele está em 2 parâmetros que você pode colocar no script da sua lane de release.

O que ele faz na migração: o upload_to_app_store aceita phased_release: true, que libera a atualização ao longo de 7 dias. O upload_to_play_store aceita um valor de rollout, a fração de usuários que recebe o build (0.1 para 10%; 1 conclui o rollout). A release da migração segue sempre o mesmo caminho em etapas, e ninguém esquece de marcar a opção.

Principais recursos:

• deliver / upload_to_app_store com phased_release
• supply / upload_to_play_store com rollout e release_status (incluindo halted)
• 1 lane para as duas lojas

Prós:

7. Phased release da App Store e staged rollouts do Google Play: melhor para limitar o raio de impacto

As duas lojas permitem enviar uma atualização primeiro para uma parte dos usuários. Seja qual for a ferramenta de release que você usa, essa é a rede de segurança para a troca de um SDK de push.

O que ele faz na migração: o novo build com o Pushwoosh chega a uma pequena parte dos usuários. Se as entregas ou a taxa de crashes parecerem erradas, você interrompe o rollout antes que ele chegue a todo mundo. Enquanto isso, o OneSignal continua enviando para quem ainda não atualizou, então ninguém perde uma campanha.

Principais recursos:

• App Store: libera ao longo de 7 dias para 1%, 2%, 5%, 10%, 20%, 50% e depois 100% dos usuários com atualizações automáticas. Você pode pausar por até 30 dias no total ou liberar para todos a qualquer momento
• Google Play: você define a porcentagem e aumenta manualmente. É possível interromper e retomar o rollout, e quem já atualizou fica com o build
• Amostragem aleatória de usuários nas duas lojas

Prós:

Etapa 5. Monitore crashes e entregas

8. Firebase Crashlytics: melhor para pegar crashes depois da troca

O Firebase Crashlytics reporta crashes e erros não fatais de apps Android, Apple, Flutter e Unity. Deixe-o rodando durante todo o rollout e compare o novo build com o anterior.

O que ele faz na migração: um crash num notification handler ou durante o init do SDK aparece aqui primeiro. Os eventos não fatais ajudam com os problemas mais silenciosos: registre um erro não fatal quando o registro de push falhar e você vai vê-lo por build.

Principais recursos:

• Relatórios de crash agrupados em issues, filtráveis por build
• Eventos não fatais, registrados no dispositivo e enviados na próxima abertura do app
• SDKs oficiais para Android, Apple, Flutter e Unity

9. Estatísticas de mensagens do Pushwoosh: melhor para identificar quedas silenciosas de entrega

Os relatórios de crash não vão avisar que os pushes pararam de chegar. As estatísticas de push do Pushwoosh vão.

O que elas fazem na migração: para cada push, você vê o funil da audiência até o envio, as entregas e as aberturas, por plataforma, além de uma aba separada de erros. Compare as primeiras campanhas depois da troca com os números do OneSignal de antes. Se as entregas no iOS ficarem atrás das do Android, confira as credenciais antes de mexer no código.

Um plano de migração em 5 passos para apps grandes

Faça o inventário de cada chamada do OneSignal antes de mexer no código

Liste cada chamada do SDK, wrapper, callback e teste, em todos os repositórios. Essa lista vira o checklist da substituição e do code review.

Coloque o push atrás de 1 interface interna

Faça toda chamada de push passar por um único serviço interno: login, logout, tags, tratamento de notificações. Assim, a migração muda 1 implementação em vez de 50 pontos de chamada, e a próxima troca de provedor também fica mais fácil.

protocol PushService {
    func login(userId: String)
    func setTags(_ tags: [String: Any])
    func handleNotificationOpen(_ payload: [AnyHashable: Any])
}

Troque os SDKs em 1 release

Adicione o SDK do Pushwoosh e remova o SDK do OneSignal no mesmo build. 2 SDKs de push no mesmo app disputam os callbacks de notificação. Enquanto o novo build é liberado, continue enviando pelo OneSignal para os usuários da versão antiga.

Libere em etapas e compare as métricas de entrega

Comece com uma pequena parte dos usuários via phased release ou staged rollout. Acompanhe os crashes no Crashlytics e as entregas nas estatísticas do Pushwoosh, depois amplie o rollout.

Pare os envios do OneSignal só depois de confirmar a entrega

Enquanto você não parar de enviar pelo OneSignal, fazer rollback significa continuar enviando pelo OneSignal. Corte quando a entrega pelo Pushwoosh e a importação da audiência estiverem confirmadas.

Perguntas frequentes