Depois de testar a compressão, conferir o salvamento dos vídeos, exercitar compras e gravar uma demonstração no iPhone, recebi outra negativa da Apple. O motivo estava em uma frase curta da página do aplicativo: o subtítulo em inglês continha a palavra “iPhone”.
O ClipLeve é um aplicativo para iPhone. Por isso, a frase parecia uma descrição natural do produto. Mas aquele campo da loja tem regras próprias, e a Apple apontou o uso do termo pela diretriz 5.2.5. No português, o subtítulo era “Reduza seus maiores vídeos”. No inglês, “Shrink big videos on iPhone”.
A correção coube em uma linha. O aprendizado ocupou bem mais espaço.
Hoje, com o ClipLeve aprovado e lançado, vale voltar a essa etapa. Houve dois pedidos diferentes no caminho, e entender exatamente o que cada um exigia foi parte do trabalho.
Primeiro, eu precisava mostrar o aplicativo funcionando
No primeiro texto sobre o ClipLeve, contei algumas decisões sobre qualidade da imagem, preservação do original e acessibilidade. A preparação técnica já envolvia bastante coisa que não aparece quando alguém vê apenas um botão para diminuir um vídeo.
Em 13 de outubro, a Apple respondeu à submissão com um pedido de informações adicionais, associado à diretriz 2.1. A mensagem citava o histórico ainda limitado da conta de desenvolvedor e pedia uma demonstração gravada em um aparelho físico.
Também era necessário explicar a finalidade do aplicativo, o público, o acesso aos recursos, as ferramentas externas utilizadas, o funcionamento entre regiões e o que cada compra liberava. Os recursos pagos precisavam aparecer de forma compreensível, com as informações da oferta e os links de termos e privacidade.
A mensagem não apontava uma falha específica na compressão ou no salvamento. Ler essa diferença com atenção evitava começar a mexer em partes do aplicativo que não tinham sido questionadas. O que faltava naquele momento era entregar à revisão uma explicação acompanhada de evidência.
Quem desenvolve conhece os caminhos da própria interface. Sabe onde ficam os planos, o que a versão gratuita permite e por que determinado botão ainda não apareceu. A pessoa que recebe o aplicativo para revisar precisa encontrar tudo isso a partir do material enviado. Cada dependência que eu deixasse implícita poderia dificultar a avaliação.
Uma gravação curta exigiu uma jornada inteira
Gravei a demonstração pela captura de tela do próprio iPhone. O percurso começava na abertura do ClipLeve, passava pela apresentação dos planos e por uma assinatura no ambiente de testes da Apple, e seguia até a criação e o salvamento de uma versão leve.
Usei vídeos sintéticos, preparados para a verificação. Assim, podia mostrar a jornada e conferir o resultado sem usar lembranças pessoais como material de teste.
A gravação enviada tinha 77 segundos. Nela, um vídeo de 42,4 MB gerou uma cópia de 7,5 MB, com o original preservado. Esse resultado dizia respeito àquele arquivo. A redução depende da gravação e da opção escolhida; transformar um exemplo em promessa para todos os vídeos seria esconder uma parte importante da experiência.
O trecho mais útil da demonstração era a continuidade. Dava para acompanhar a entrada no app, entender a oferta, ver o acesso Pro ativo e chegar à cópia salva. A compra mostrada era de teste, sem cobrança real.
Em 15 de outubro, a gravação e as sete respostas foram incluídas nas notas da versão e na conversa com a Apple. Reenviei o mesmo pacote do aplicativo. A versão, a assinatura anual, o acesso vitalício e o grupo de assinatura voltaram a aguardar revisão.
Preparar esse material me fez olhar para o produto de fora. Uma sequência que precisa de muita explicação pode estar escondendo uma dúvida da interface. Mesmo quando o percurso está claro, registrar os passos ajuda a conferir se a descrição comercial corresponde ao que a pessoa realmente consegue fazer.
A experiência do Garfim deveria ter entrado antes
Eu já havia recebido um pedido semelhante na revisão do Garfim. A demonstração em aparelho físico e os esclarecimentos sobre o produto não eram uma surpresa completa.
Ainda assim, esse contexto não entrou a tempo na preparação inicial do ClipLeve. Houve retrabalho que poderia ter sido antecipado.
Essa foi uma das lições mais úteis do processo. Trabalhar em mais de um produto só gera aprendizado acumulado quando uma experiência muda a preparação do próximo. Deixar a resposta resolvida em uma conversa antiga não garante que ela será lembrada no momento de um novo envio.
Passei a tratar o material de revisão como parte da entrega: o caminho demonstrável, as explicações sobre compras, os arquivos de exemplo e as informações que permitem entender o produto. É o tipo de trabalho que fica fácil adiar enquanto há um problema de código mais visível para resolver.
No entanto, ele também determina se o aplicativo consegue chegar às pessoas.
A segunda negativa estava no subtítulo em inglês
Em 17 de outubro, veio outra resposta. Dessa vez, o ponto registrado era o uso de “iPhone” no subtítulo em inglês, pela diretriz 5.2.5, de propriedade intelectual.
Troquei “Shrink big videos on iPhone” por “Shrink your biggest videos”. A nova frase manteve a ideia central: reduzir os vídeos que mais ocupam espaço. O subtítulo em português já seguia essa direção.
Conferi o campo salvo, respondi à Apple e reenviei os itens para revisão. Não houve alteração de código, recompilação ou novo envio de binário nessa correção. O aplicativo continuava sendo a versão 1.0.0, build 1.
A palavra ocupava pouco espaço, mas fazia parte do material submetido. Nome, subtítulo, imagens, descrição e informações de compra também entram na avaliação. As diretrizes de revisão da Apple tratam desse conjunto.
O cuidado aqui é entender o motivo concreto da mensagem. O caso não significa que a compatibilidade com o iPhone deixou de poder ser explicada. O apontamento foi sobre aquele uso no subtítulo, e foi ali que a correção aconteceu.
Cada idioma precisa de uma revisão própria
Uma tradução pode soar natural e, ainda assim, criar uma pendência que não existia no texto original. Foi exatamente o que aconteceu: o português descrevia o benefício, enquanto o inglês acrescentava o nome do aparelho.
Isso mudou a forma como passei a olhar para a localização da página. Conferir o português não encerrava a revisão do inglês. Também precisava comparar o sentido das promessas, os campos utilizados e a correspondência com os recursos entregues.
O mesmo cuidado vale para as imagens da loja. Uma arte legível no arquivo original pode perder informação no corte da prévia. Durante a preparação do ClipLeve, as artes de cabeçalho e de busca precisaram de composições diferentes porque o texto não se comportava da mesma forma nos dois espaços.
Esses detalhes têm uma consequência muito concreta: o visitante conhece o aplicativo pelo que a loja mostra. Se a informação fica cortada, ambígua ou diferente entre idiomas, essa dificuldade chega antes mesmo da instalação.
O que ficou para o próximo envio
Eu saí dessa etapa com uma ideia mais precisa do que significa estar pronto para submeter um aplicativo.
Os testes precisam mostrar o que foi exercitado. A apresentação precisa corresponder ao produto. As notas de revisão precisam permitir que outra pessoa percorra os recursos. E cada idioma precisa ser conferido dentro dos campos em que será publicado.
Também aprendi a responder a uma negativa com uma sequência mais objetiva: ler o apontamento inteiro, localizar a informação ou o comportamento mencionado, corrigir, conferir o resultado e explicar o que mudou. No segundo retorno do ClipLeve, essa sequência levou a uma alteração pequena e verificável.
A aprovação veio depois. A história do lançamento está no próximo capítulo. Mas eu quis registrar essa passagem porque ela ajuda a dimensionar o trabalho de colocar um produto no mundo: às vezes, depois de resolver problemas difíceis de mídia, compras e segurança dos arquivos, ainda falta revisar uma única linha.