O Garfim foi enviado à App Store em 7 de outubro. No dia seguinte, veio a primeira negativa: a Apple pediu mais informações e uma demonstração do aplicativo funcionando em um iPhone.

O parecer se enquadrava em “Information Needed”, dentro da diretriz 2.1. A conta tinha pouco histórico de revisão, e a equipe queria conhecer melhor o produto antes de continuar a avaliação.

Ler esse retorno trouxe um trabalho diferente daquele de construir as telas: apresentar o funcionamento para alguém que não acompanhou nenhuma das decisões anteriores.

O status sozinho explica pouco

“Rejeitado” pode dar a impressão de um diagnóstico completo. O que orienta a próxima ação é o conteúdo do parecer.

Neste caso, o pedido não apontava uma tela quebrada ou uma compra recusada. Solicitava informações e evidências. A análise continuava pendente, e minha resposta precisava atender aos pontos levantados.

Essa leitura muda a preparação. Antes de mexer no produto, preciso entender o que a pessoa responsável pela revisão não conseguiu avaliar. Corrigir por suposição pode consumir tempo sem responder ao pedido.

A diretriz citada pela Apple serviu de referência para organizar essa conferência.

Um vídeo precisa mostrar as ligações entre as telas

A Apple pediu uma gravação em aparelho físico, com o sistema atualizado. O roteiro deveria começar na abertura e mostrar uso típico, cadastro, login, exclusão da conta e acesso aos recursos pagos.

Na assinatura, precisavam aparecer nome, duração, preço e links para termos e privacidade.

Preparar isso exige percorrer o produto como uma sequência. Uma captura mostra o estado de uma tela. A gravação revela como alguém chega até ela, o que precisa decidir e se consegue seguir adiante.

Para o Garfim, o percurso central é fotografar a refeição, conferir os alimentos e salvar. O revisor precisa encontrar esse caminho com as instruções entregues, sem depender de uma explicação minha ao lado.

Quem constrói já sabe coisas que precisa explicar

O pedido também incluía público, problema resolvido, serviços externos, diferenças entre regiões e o que pode ser comprado no aplicativo.

Essas informações parecem familiares depois de semanas dentro do projeto. Para quem o recebe pela primeira vez, são peças necessárias para entender o conjunto.

Ao organizar a resposta, preciso explicar a função de cada serviço e relacioná-la ao que acontece no app. Dizer que há IA, por exemplo, deixa em aberto onde ela entra, o que recebe e o que devolve à pessoa.

A mesma dificuldade aparece ao apresentar software a um cliente ou a uma nova equipe. Conhecer o funcionamento por dentro pode fazer a gente pular justamente a explicação que falta para o outro.

Preparar a resposta é revisar a apresentação do produto

Organizei a preparação em torno de uma conta de teste e de um roteiro que incluía a exclusão dessa conta. A gravação precisava mostrar o percurso real no aparelho, com as informações necessárias para que o revisor conseguisse repeti-lo.

Em 8 de outubro, essa resposta ainda estava em preparação. A primeira negativa acrescentou uma tarefa clara ao lançamento: tornar o funcionamento verificável por quem está chegando agora.

O exercício tem valor além da revisão. Se preciso de muitas explicações para alguém completar uma tarefa, vale olhar também para as instruções e para a própria interface. A forma de demonstrar um produto ajuda a perceber onde ele ainda exige conhecimento demais de quem usa.