Como acompanhar falhas de uma aplicação móvel após o lançamento

Um bilhete que não abre vale mais do que um gráfico tranquilo

Uma passageira chega à entrada e tenta apresentar o bilhete no telemóvel. A aplicação fecha antes de mostrar o código. A equipa tinha testado o percurso, mas a pessoa continua sem conseguir passar. A fotografia ilustra uma situação possível; não é o relato de um incidente de um cliente da Appfyl.

Depois do lançamento, não basta perguntar quantas vezes a app fechou. A pergunta útil é: quem não conseguiu fazer o quê, em que versão, e quem tem autoridade para agir? O guia de lançamento cobre a preparação da publicação. Aqui importa perceber o que acontece quando a aplicação chega a dispositivos e hábitos reais.

Um encerramento não explica todos os problemas

Um encerramento inesperado tira a pessoa da app. No Android, um ANR significa que a aplicação deixa de responder, embora o ecrã possa continuar aberto. Há ainda a falha silenciosa: a reserva parece concluída, mas não consta do sistema. Se o acompanhamento se limitar aos encerramentos, o negócio pode falhar sem disparar um único aviso.

A Firebase explica a diferença entre utilizadores e sessões sem falhas fatais. São métricas de estabilidade, não de sucesso de todas as tarefas. Mesmo uma média excelente pode esconder uma avaria que impede um grupo pequeno de pagar ou entrar numa aula. Confirme sempre que está a olhar para a versão pública, não para compilações de teste.

Testar a medição antes de confiar num zero

Peça à equipa que provoque uma falha controlada numa compilação semelhante à de produção e encontre o respetivo relatório. O registo deve identificar versão, plataforma, dispositivo e uma descrição técnica legível. Sem os ficheiros de símbolos do iOS ou os ficheiros de correspondência do Android, a notificação pode chegar sem permitir descobrir depressa a causa. Repita o teste se o processo de compilação mudar.

Depois confirme quem lê o aviso. Quem substitui essa pessoa? Quem pode interromper a distribuição? A documentação da Firebase distingue alertas disponíveis de imediato de outros, como os de novas falhas fatais e ANR, que exigem configurar um canal. Um aviso perdido numa consola pouco visitada não protege os utilizadores.

Recolha apenas contexto seguro: versão, identificador anónimo do incidente e última ação não sensível. Palavras-passe, tokens, dados de saúde e detalhes de pagamento não devem entrar nos relatórios. Ao juntar um novo serviço, reveja a política de privacidade da aplicação.

Ligar os números ao que aconteceu no serviço

O Android vitals apresenta sinais de estabilidade observados pelo Google Play. O Crashlytics agrupa incidentes e ajuda a comparar versões. O Sentry pode ser uma alternativa se a equipa também precisar de analisar erros e desempenho noutros componentes. Nenhuma dessas ferramentas, sozinha, comprova que uma marcação foi guardada no servidor ou que um pagamento ficou concluído.

Para quem gere o produto, o essencial cabe num resumo curto: adoção da nova versão, problemas novos ou repetidos, pessoas afetadas e percurso interrompido. O Release Monitoring da Firebase mostra a versão recente em comparação com a anterior. Cruze-o com os eventos definidos no plano de análise da app para detetar uma quebra nos registos de entrada mesmo sem aumento de encerramentos.

Quando travar a distribuição

Num estúdio de treino, os alunos chegam para a aula. A app abre, mas a entrada não fica registada. A receção deixa as pessoas entrar e anota as presenças à mão. A prioridade é manter o acesso e conseguir reconstruir o registo; esperar por uma subida no gráfico de falhas seria a decisão errada.

Defina antes do lançamento quais são os motivos para uma decisão imediata: falhas novas e abrangentes, início de sessão ou pagamentos bloqueados, perda de registos, questões de segurança ou privacidade. Um pequeno defeito visual pode esperar. Pese o número de pessoas atingidas, a importância do percurso, a versão afetada e as alternativas existentes. Não há uma percentagem universal que sirva tanto para uma app de bilhetes como para uma app de leitura ocasional.

Com um lançamento gradual pode suspender a expansão enquanto desenvolvimento e apoio resolvem o problema. Isso não desfaz automaticamente alterações feitas na base de dados; a recuperação precisa de um plano próprio. Inclua depois o caso nas verificações do próximo lançamento.

As primeiras horas precisam de um responsável

Antes de publicar, registe quem acompanha a nova versão, onde chegam os avisos, que tarefas têm de funcionar e quem decide parar. Logo a seguir, confirme que há sessões da nova versão. Um gráfico vazio sem utilizadores não prova estabilidade. Compare com a versão anterior, execute uma ação importante num dispositivo real e confirme o resultado no servidor ou na análise do produto. Volte a verificar quando a adoção crescer e abranger outros telemóveis.

Quando surgir um incidente, anote a primeira versão afetada, o percurso, uma solução temporária, o responsável e a próxima hora de revisão. O apoio ao cliente precisa de saber o que dizer. Depois da correção, verifique a versão publicada e confirme que o problema deixou de ocorrer. É parte da manutenção contínua, não apenas da instalação de uma biblioteca.

Se outra equipa for assumir uma app instável, reúna as ligações às lojas, a versão, a tarefa que falha, pedidos de apoio e acesso aos relatórios. «Tornar a app estável» ainda não descreve um problema concreto. A Appfyl pode receber estes dados num breve questionário e, só depois da análise, distinguir uma correção pontual de uma intervenção maior.

Perguntas frequentes