Crashes em produção: como descobrir o que quebrou no celular do cliente

Avaliações como "fecha sozinho" ou "não abre" são o pior jeito de descobrir problemas. Sem monitoramento, você não sabe em quais aparelhos, versões ou telas o erro acontece — e não consegue reproduzir.

O que um bom monitoramento captura

• Crashes nativos e erros de JavaScript.
• Rastro do erro com o código original (com mapas de código fonte configurados).
• Contexto: modelo do aparelho, sistema, versão do app, tela, ações anteriores.
• Frequência e usuários afetados.

Ferramentas como Sentry e Firebase Crashlytics fazem isso.

Priorize pelo impacto

Um erro que afeta 5% dos usuários na tela de pagamento é mais urgente que um erro raro numa tela secundária. Acompanhe a porcentagem de sessões sem crash como métrica principal de estabilidade.

Cuidados com privacidade

O relatório pode capturar dados da tela ou de requisições. Configure para não enviar informações pessoais (Logs sem dados sensíveis: o vazamento que ninguém percebe).

Antes de liberar para todos

1. 1.Liberação gradual na loja e nas atualizações OTA (Atualizações OTA: corrigir o app sem esperar a loja).
2. 2.Monitorar as primeiras horas depois de cada versão.
3. 3.Reverter rápido se a taxa de crash subir.

Erros que não são crashes

Telas em branco, requisições que falham e lentidão também importam — e entram na observabilidade geral do sistema (Observabilidade para quem não é SRE: métricas, logs e traces). Testes em aparelhos reais evitam muitos deles (Testar em dispositivos reais: por que o emulador engana).

A We Codex mantém apps monitorados em produção. Veja aplicativos nativos ou fale com a gente.