
Uma assinatura estava ativa, mas pertencia a outra conta do Garfim. Na tela do iPhone, a mensagem dizia apenas: “A loja não confirmou o pagamento”.
Esse foi um dos problemas encontrados durante a preparação de uma demonstração do aplicativo. A frase juntava situações diferentes e deixava a pessoa sem saber como continuar.
O caso levou a ajustes que chegaram ao grupo interno do TestFlight em 9 de outubro. Também ajuda a explicar uma parte pouco visível das assinaturas: a compra na loja e a conta dentro do aplicativo precisam se encontrar corretamente.
Trocar de login não transfere a compra
Um mesmo aparelho pode ser usado com contas diferentes do Garfim. A assinatura, porém, precisa continuar vinculada à conta que a possui.
No episódio, os registros mostravam uma compra de teste ativa na conta anterior e nenhuma compra verificada na nova. Tentar restaurar naquela nova conta encontrava um conflito de titularidade.
A restauração serve para recuperar o acesso de uma compra existente. Transferi-la entre contas é outra operação, com outras consequências. Confundir as duas coisas pode entregar o acesso à pessoa errada ou fazer parecer que uma assinatura desapareceu.
Na versão 7, o Garfim passou a conferir compras ativas antes de iniciar uma nova tentativa e a explicar melhor os conflitos entre contas.
Uma espera sem fim também é um problema de interface
Durante a investigação, apareceram tentativas com a indicação de que já havia uma compra em andamento. Não foi possível estabelecer a causa da ausência da resposta inicial da loja.
Mesmo assim, havia uma decisão de interface a tomar: quanto tempo deixar alguém olhando para uma ação que não termina?
O novo fluxo encerra essa espera na tela após 60 segundos e orienta a restauração. Uma confirmação que chega mais tarde ainda pode ser verificada. O acesso só é liberado depois da conferência pelo servidor.
A diferença é importante: parar de exibir uma espera não significa concluir que a compra falhou. A interface precisa dar um próximo passo sem inventar uma resposta que ainda não recebeu.
Falha de comunicação não determina o estado da assinatura
Nos dias 11 e 12 de outubro, o trabalho continuou na verificação com a Apple. Acrescentei ao projeto uma nova tentativa limitada para determinadas falhas temporárias e um tratamento para consultas sem informações de uma assinatura já conhecida.
Nessa segunda situação, o sistema só aceita o encerramento quando o período anteriormente verificado já terminou. Uma resposta vazia não basta para retirar um acesso ainda válido.
Esse cuidado separa duas perguntas que às vezes se misturam: o serviço respondeu? E qual é a situação da compra? Uma falha na primeira não resolve a segunda.
Situação até 12 de outubro: a versão 7 havia chegado ao TestFlight, o ambiente de testes da Apple. O fluxo e os ajustes posteriores ainda exigiam validação no aparelho; isso não representava aprovação para lançamento público.
O que esse episódio mudou
Para mim, o aprendizado está na precisão do caminho oferecido à pessoa. “Restaurar”, “tentar novamente” e “entrar na conta correta” orientam ações distintas. Escolher a mensagem certa exige entender o que aconteceu por trás dela.
É uma parte do desenvolvimento que costuma caber em poucas palavras na tela. Para chegar a essas palavras, preciso acompanhar a compra, a conta, o tempo de resposta e a possibilidade de a confirmação chegar depois.
