Removi o anonimato do meu app, e foi a decisao certa

Passei semanas a construir um sistema de autenticação anónima que permitia usar o TAMSIV sem uma conta. Era elegante, funcionava bem e eu estava orgulhoso. Esta semana, apaguei tudo. Eis o porquê de ter sido a decisão certa.

Porque é que removi a autenticação anónima

Quando lancei o TAMSIV em alpha, o registo preguiçoso era óbvio. De acordo com a AppsFlyer, 40 a 60% dos utilizadores desistem no momento do registo. Ao remover esta fricção, pensei que maximizaria a retenção. E funcionou, por um tempo.

Mas em produção, a realidade é diferente. As contas anónimas acumulavam-se na base de dados. Dezenas de contas sem e-mail, sem forma de contacto, sem possibilidade de recuperação. As métricas do painel de administração tornaram-se ilegíveis: impossível distinguir um utilizador real de um curioso que abriu a aplicação por 30 segundos.

O problema de segurança era ainda mais concreto. Uma conta anónima é uma conta com um UUID e dados, mas sem identidade verificável. Se alguém perdesse o seu telefone, as suas tarefas e notas desapareceriam com ele. Sem e-mail para recuperação. Sem palavra-passe para proteção. Apenas um token efémero num dispositivo.

Como esta decisão simplificou o código?

[EXPERIÊNCIA PESSOAL] Ao remover as sessões anónimas, eliminei um número surpreendente de caminhos condicionais no código. Não há mais if (isAnonymous) nos serviços. Não há mais lógica de migração de anónimo para conta real. Não há mais limpeza automática de contas "zombie" após 30 dias.

O commit 7a0101d afetou todo o fluxo de autenticação. No primeiro lançamento, o utilizador agora chega a um ecrã de registo ou login. É mais simples, mais previsível e garante que cada pessoa que usa a aplicação fez uma escolha deliberada.

Isto corre o risco de fazer perder utilizadores no momento do registo? Provavelmente alguns, sim. Mas aqueles que se registam são utilizadores comprometidos. E é exatamente este o tipo de métrica que queremos acompanhar em produção.

O bug do modal flash que ninguém tinha notado

Ao testar a nova autenticação, descobri um bug vicioso. A cada lançamento da aplicação, o modal dos termos e condições de uso aparecia por uma fração de segundo antes de desaparecer. Um flash rápido, quase subliminar. O tipo de coisa que tu não notas conscientemente, mas que dá uma impressão de falta de polimento.

[DADOS ORIGINAIS] O problema vinha do timing. A aplicação carregava o perfil do utilizador do Supabase, e durante esse carregamento, o campo terms_accepted estava temporariamente null. O componente do modal interpretava este null como "o utilizador não aceitou os Termos e Condições" e exibia-se. Alguns milissegundos depois, o perfil chegava com terms_accepted: true, e o modal desaparecia.

A solução no commit 8979543: esperar pelo perfil fresco da base de dados antes de avaliar o estado do modal. Sem perfil carregado = sem decisão = sem flash. Simples, mas era preciso encontrá-lo. Este tipo de bug não se reproduz em testes automatizados porque os mocks retornam o perfil instantaneamente.

Porquê aumentar uma versão para "apenas" 3 commits?

[INSIGHT ÚNICO] Ao construir em público, a tentação é grande de agrupar muitas mudanças numa única versão para que pareça impressionante. Eu fiz o contrário. O salto para a versão 1.04 (commit d900d21, versionCode 39) contém apenas estas três mudanças. E é intencional.

Uma mudança de autenticação é o tipo de modificação que pode quebrar coisas de forma subtil. Um utilizador que tinha uma conta anónima, o que acontece quando ele atualiza a aplicação? Os tokens são inválidos? O perfil é acessível? Ao isolar esta mudança numa versão dedicada, a depuração é simples: se algo quebrar, eu sei exatamente onde procurar.

Pequenas versões frequentes são melhores do que grandes versões raras. É um princípio que aplico desde o início do TAMSIV, e que me evitou muitas noites sem dormir. Cada build é um snapshot testável. Cada versão implementada tem um âmbito claro.

O que isto muda para os utilizadores

Na prática, a mudança é mínima para alguém que já usava o TAMSIV com uma conta. Nada muda. As tarefas, os memorandos, os grupos, tudo permanece no lugar.

Para os novos utilizadores, a experiência é diferente, mas não necessariamente pior. Em vez de entrarem diretamente na aplicação, eles passam por um ecrã de registo. E-mail, palavra-passe, está feito. E a partir daí, os seus dados estão seguros, sincronizáveis em vários dispositivos e recuperáveis em caso de perda do telefone.

O sistema de autenticação por código QR para a aplicação web agora funciona para 100% dos utilizadores, não apenas para aqueles que tiveram tempo de criar uma conta. É um ganho concreto em UX para a versão desktop.

As lições de um desenvolvedor solo que muda de ideias

Mudar de ideias sobre uma decisão técnica é desconfortável. Escrevi um artigo inteiro sobre os benefícios do registo preguiçoso. E hoje estou a fazer o contrário. É embaraçoso? Um pouco. Mas também é a realidade do desenvolvimento: o que é ótimo em alpha não é necessariamente ótimo em produção.

Em alpha, com 12 testadores recrutados, o anonimato reduzia a fricção. Em produção, com utilizadores reais que esperam que os seus dados estejam seguros, o registo é o mínimo. O contexto mudou, então a decisão muda.

Se tu estás a construir um produto e hesitas entre estas duas abordagens, a minha recomendação é simples. No pré-lançamento, o registo preguiçoso é ótimo para validar o teu produto. Em produção, o registo obrigatório é mais sensato. Tu podes sempre oferecer um teste gratuito generoso para compensar a fricção.

FAQ

Os utilizadores anónimos existentes perdem os seus dados?

As contas anónimas que foram migradas para contas reais (com e-mail) não são afetadas. Apenas as contas que permaneceram puramente anónimas, sem e-mail associado, não podem mais fazer login. Uma limpeza dessas contas órfãs está planeada.

O registo demora muito?

Dois campos: e-mail e palavra-passe. Sem verificação por SMS, sem captcha, sem formulário extenso. O objetivo é ficar abaixo dos 30 segundos entre a abertura da aplicação e a primeira utilização.

O bug do modal flash afetava a segurança?

Não. Era um problema puramente visual. O modal dos Termos e Condições aparecia brevemente e depois desaparecia. Nenhum dado foi exposto e as condições permaneceram aceites na base de dados. Era uma falha de polimento, não de segurança.