Rejeições de metadados na App Store: como resolver 2.3.x, 2.3.7, 4.3 e 5.2.1
Você acabou de receber o e-mail. O status virou Metadata Rejected, e a nota do Resolution Center cita um número de diretriz que você teve que ir pesquisar. A boa notícia é que uma rejeição de metadados é uma das mais rápidas de resolver: você não está reenviando um build, está editando o registro da versão e reenviando.
A primeira coisa a checar é o número da diretriz na mensagem do Resolution Center, porque isso indica exatamente qual campo corrigir. Este post cobre as quatro que você tem mais chance de encontrar numa rejeição de ficha. Os números das diretrizes mudam com o tempo, então os aqui usados refletem as App Store Review Guidelines atuais.
Primeiro, o mecanismo: o que "Metadata Rejected" realmente significa
Um status Metadata Rejected aponta para a sua ficha na loja — nome do app, subtítulo, palavras-chave, descrição, capturas de tela, prévias, URLs — não para o app compilado. Como o sinalizador está nos metadados, você não precisa de um novo binário. Você edita o campo citado no App Store Connect, mantém o build existente vinculado à versão e reenvia.
Vale destacar duas ressalvas com clareza. Primeiro, reenviar ainda coloca você de volta na fila de revisão, então é sem novo build, mas não sem revisão — uma pessoa ou uma checagem automatizada vai olhar de novo. Segundo, corrigir o único campo que a Apple citou não imuniza o resto da sua ficha. Os revisores podem sinalizar uma diretriz diferente na próxima passagem. Aproveite para ajustar a ficha inteira enquanto você está nela, não só a frase que foi citada de volta para você.
Diretriz 2.3.3 — as capturas de tela precisam mostrar o app em uso
O que dispara isso. Suas capturas de tela não mostram o app cumprindo sua função. A versão clássica é um primeiro slot que é uma tela de abertura, uma página de login ou uma arte de título com um slogan e nenhuma interface real. Também dispara quando uma captura de tela mostra um recurso que o app não tem, ou faz referência a um dispositivo ou interface de outra plataforma.
Antes: o slot um é o seu logo centralizado num gradiente com a frase "a forma mais inteligente de planejar sua semana", sem nenhuma interface do app à vista.
Depois: o slot um é uma tela real de um fluxo principal — uma visão semanal com compromissos de verdade preenchidos — com uma legenda curta nomeando o benefício acima do dispositivo. Os revisores (e os usuários) conseguem ver o que o app faz a partir da miniatura. Mantenha legendas de marketing e molduras de dispositivo, mas garanta que a interface do app por trás seja genuína e atual.
Essa é uma mudança de metadados: troque as imagens no registro da versão, reenvie, sem novo build.
Diretriz 2.3.7 — palavras-chave precisam descrever seu app, não caça a buscas de jogos
O que dispara isso. Essa é a diretriz sobre uso indevido de palavras-chave. Ela dispara quando seus metadados estão inflados com termos que não descrevem seu app: termos registrados que não pertencem a você, nomes de apps maiores ou mais populares, linguagem de preço no campo errado, nomes de celebridades ou figuras públicas colocados para alcance, ou frases genéricas amontoadas para capturar buscas. O campo de palavras-chave com limite de 100 caracteres costuma ser o culpado, mas o subtítulo e o nome também são sinalizados. Nomes de apps têm limite de 30 caracteres, e linguagem de preço ou promocional não pertence ao nome, ao subtítulo ou às capturas de tela.
Antes (campo de palavras-chave): uma lista que inclui os nomes de três apps maiores na sua categoria, o nome de um criador conhecido e algumas palavras em alta sem relação nenhuma, nenhuma das quais descreve um recurso que você entregou.
Depois: palavras-chave que correspondem ao que um usuário realmente buscaria para encontrar sua função — as tarefas que ela executa, o problema que resolve, os substantivos das suas próprias telas. Cada termo deve apontar para algo que o app genuinamente faz.
Antes (subtítulo): uma linha de comparação posicionando você contra um app rival nomeado.
Depois: um subtítulo que declara o resultado que seu app entrega em termos simples, sem o nome de outra marca nele. O subtítulo serve para dar contexto sobre seu app, não é um lugar para pegar carona no tráfego de outra pessoa.
Diretriz 4.3 — spam e apps quase idênticos
O que dispara isso. A 4.3 é sobre semelhança. Ela dispara quando você lança vários apps quase idênticos sob bundle IDs separados (um build separado por cidade, por equipe, por cliente, em vez de um único app com essas variações internas), ou quando um envio é difícil de distinguir de algo já amplamente disponível. Muitas vezes é um problema de conceito, mas é a ficha que torna a duplicação visível — descrições e capturas de tela idênticas entre os seus próprios apps são um forte indício.
Antes: cinco apps na sua conta com o mesmo layout, a mesma lista de recursos, e um texto que difere apenas por trocar o nome de uma cidade ou equipe.
Depois: um único app que carrega essas variações como opções ou compras internas, com uma ficha que descreve o que ele genuinamente faz de diferente. Se você realmente tem produtos separados, faça cada ficha mostrar o que é de fato diferente nas capturas de tela e na descrição, não apenas uma troca de nome próprio.
A 4.3 pode exigir mais do que uma edição de metadados se o app subjacente for realmente uma reskin superficial. Mas quando o problema é que suas fichas parecem clones umas das outras, diferenciar o texto e as capturas de tela é uma correção de metadados.
Diretriz 5.2.1 — propriedade intelectual de terceiros nos seus metadados
O que dispara isso. Usar material protegido de terceiros sem ter direitos sobre ele — marcas registradas, obras protegidas por direitos autorais, nomes que imitam outros — em qualquer lugar do seu bundle, nome de desenvolvedor ou metadados. Uma variante comum é uma incompatibilidade entre o app ou a marca na ficha e a entidade que de fato o enviou, o que faz a Apple perguntar quem é o dono do nome.
Antes: um nome de marca ou plataforma que não é seu presente no título, subtítulo ou campo de palavras-chave do seu app para capturar o tráfego de busca dele.
Depois: o nome do seu próprio produto no título, subtítulo e palavras-chave. Se você realmente integra com uma plataforma de terceiros e precisa dizer isso, mantenha qualquer menção factual de compatibilidade na descrição, onde é permitido, e fora do nome e do subtítulo. Se você desenvolveu o app para um cliente que é dono da marca, envie a partir da conta da entidade que a possui, ou peça para ser adicionado à equipe dela, para que o nome do vendedor e a marca coincidam.
A parte sem novo build, revisitada
Nas quatro diretrizes, se a correção está no registro da versão — texto e imagens —, você a resolve no App Store Connect e reenvia o mesmo binário. Não é preciso aumentar o número do build nem esperar o processamento. Essa é a via rápida que uma rejeição de metadados proporciona. A contrapartida é que você volta a passar pela revisão, então vale ler a ficha inteira contra essas quatro diretrizes antes de reenviar, em vez de resolvê-las uma rejeição de cada vez.
Onde o Mokbi ajuda (e onde não ajuda)
A maior parte dos problemas de 2.3.7 começa na etapa de escrita, quando um campo de palavras-chave ou subtítulo é inflado para buscar alcance. A IA do Mokbi redige o texto da sua ficha — nome, subtítulo, palavras-chave, descrição — a partir do que seu app realmente faz, o que te afasta dos hábitos de excesso e de pegar carona em marcas alheias que geram uma rejeição por palavra-chave em primeiro lugar. Depois, ele localiza esse texto para 50 idiomas, então você não precisa escrever à mão um campo de palavras-chave novo para cada mercado e reintroduzir a mesma armadilha em cada um.
Seja realista quanto ao limite disso. Isso reduz as suas chances de um sinalizador de 2.3.x ou 5.2.1 no texto; não pode prometer aprovação, e não decide o que está dentro do seu build. A revisão é decisão da Apple. O que um texto em conformidade e fiel ao app faz é eliminar os motivos fáceis e autoinfligidos de rejeição. O Mokbi não publica automaticamente na sua ficha — ele produz o texto e as capturas de tela; você revisa e envia.