O que você pode mudar sem uma nova versão do app: Apple vs Google
Antes de mexer em uma listagem de loja, vale responder uma pergunta: essa edição vai me custar um envio completo, ou pode sair sem alarde? Errar aqui significa ficar preso em uma fila de revisão que você não previu, ou assumir que uma mudança está no ar quando ainda está esperando aprovação. As duas lojas respondem essa pergunta de formas opostas, e essa diferença é o motivo de manter as listagens sincronizadas entre as duas ser tão chato.
Aqui vai a versão honesta, campo a campo — começando pela matriz, depois o raciocínio por trás das regras de cada loja, para você prever os casos que essa tabela não cobre.
A matriz
Cada campo comum de listagem, e o que cada loja exige quando você o altera. "Nova versão / release" significa que a loja trata a edição como parte de um envio que você precisa enviar; "revisado" significa que uma checagem humana ou automatizada roda antes de entrar no ar.
| Ícone do app | O ícone principal vai dentro do binário — mudá-lo exige um novo build. Revisado junto com esse build. | O ícone da loja é um recurso de listagem. Sem novo release. Revisado. |
Duas coisas chamam a atenção. A Apple direciona quase tudo por meio de um registro de versão. O Google deixa a listagem inteira se mover sozinha. Nenhuma das duas pula a revisão nos recursos que importam — a palavra "revisado" aparece em quase todas as células. Então a pergunta real raramente é "isso vai ser revisado", e sim "essa edição arrasta um envio junto com ela".
Apple: um novo registro de versão não é o mesmo que um novo build
Essa é a distinção que confunde as pessoas. Na App Store, editar suas capturas de tela, nome, subtítulo, campo de palavras-chave ou descrição cria uma nova versão da sua listagem. Parece que isso deveria te forçar de volta ao Xcode. Não força. A Apple carrega automaticamente seus metadados atuais para a nova versão, e uma mudança só de metadados não exige código novo — você anexa um build (o App Store Connect ainda exige um na versão) e não muda nada sobre o que o app faz. Você edita os campos na fila, envia, e um único ciclo de revisão cobre todos eles.
Então "sem código novo, mas ainda revisado" é a forma correta de guardar isso na cabeça. Nenhuma etapa de compilação e nenhum recurso novo — mas a edição ainda entra na App Review e espera sua vez antes de ficar pública. Agrupe suas mudanças: como um único registro de versão pode conter capturas de tela novas, uma descrição reescrita, um subtítulo novo e palavras-chave atualizadas, tudo de uma vez, não há razão para gastar um ciclo de revisão separado para cada uma.
O ícone do app é a exceção que realmente exige um build. Seu ícone principal está embutido no binário e é extraído dele, então um ícone genuinamente novo significa um build novo. O mesmo vale para ícones alternativos — eles precisam estar empacotados no app para serem usáveis, então adicionar um é um build, não uma edição de listagem.
As duas rotas de escape da Apple
Texto promocional. Esse é o único campo que você pode mudar sem versão e sem revisão. São 170 caracteres, fica acima da descrição, e atualiza sempre que você quiser — útil para uma promoção, um aviso de lançamento ou um texto sensível ao tempo. Não afeta o ranking de busca e não faz parte de nenhum envio, o que é exatamente o motivo de ser a coisa mais rápida de mudar na loja. Se você precisa de algo no ar hoje, é esse o campo que resolve.
Product Page Optimization. O PPO permite testar até três variações das suas capturas de tela, App Previews e ícone contra sua página de produto ao vivo — sem enviar uma nova versão do app. É o mais próximo que a Apple chega de mudar elementos visuais fora de um envio normal. Duas ressalvas mantêm isso honesto: os metadados da variação ainda precisam ser aprovados antes que o teste rode (ou seja, é revisado, não instantâneo), e qualquer ícone que você queira testar já precisa fazer parte do binário atual do app. O PPO muda o que os visitantes veem; não pula a revisão.
Google Play: publique a listagem sem um release
O Play funciona ao contrário. Sua listagem de loja — título, descrição curta, descrição completa, capturas de tela, gráfico de destaque, ícone, vídeo promocional — é editável e publicável por si só, sem nenhum novo release do app anexado. Você faz as edições, e elas aparecem na visão geral de Publishing como mudanças prontas para enviar para revisão. Você as envia, elas passam pela revisão do Google, e entram no ar independentemente de qualquer build.
Algumas coisas para manter precisas, para você não exagerar. As mudanças ainda são revisadas — a revisão do Play também roda em edições de listagem, e elementos como o nome do app e o ícone são checados, então não é uma troca instantânea e silenciosa. E a listagem não pode flutuar livre de um app publicado — o Play precisa que o app já tenha um release anterior para existir uma listagem pública a editar. Você não pode publicar uma página de loja avulsa para algo que nunca foi lançado. A publicação gerenciada acrescenta mais uma nuance importante — se estiver ativada, as mudanças aprovadas esperam até você publicá-las ativamente, o que é um recurso, não um atraso, uma vez que você já espera por isso.
A assimetria, e por que ela custa seu tempo
Alinhe os dois modelos e a divisão fica clara. A Apple amarra quase toda edição de texto e imagem a um registro de versão e a um ciclo de revisão, com o texto promocional e o PPO como as únicas formas de contornar isso. O Google desacopla a listagem do release por completo, revisa as edições e as publica no próprio ritmo, desde que o app já exista.
Essa assimetria custa caro, discretamente, quando você opera nas duas lojas. A mesma atualização de capturas de tela é um envio de registro de versão em uma loja e uma atualização de listagem avulsa na outra. Uma reescrita de descrição é uma versão revisada na Apple e uma mudança de listagem revisada no Google. O conteúdo é o mesmo; a mecânica não é, então uma mudança que é uma única ação no Play vira uma ação diferente na App Store — e é fácil publicar em uma e esquecer a outra, ou assumir que algo já está no ar na Apple quando ainda está em revisão.
Onde o Mokbi entra
Essa assimetria entre lojas é o motivo pelo qual uma ferramenta de publicação se justifica. O Mokbi começou como um editor de capturas de tela, mas uma listagem é texto e imagem juntos — então ele projeta o conjunto de capturas de tela e redige o texto da listagem para as duas lojas em um só lugar: nome, subtítulo, campo de palavras-chave e descrição para a App Store; título, descrição curta e descrição completa para o Play. Você recebe os campos que cada loja de fato indexa, moldados para aquela loja, em vez de um bloco de texto único que você cola duas vezes.
Depois ele traduz a listagem inteira — capturas de tela e texto — para 50 idiomas, então uma mudança feita uma vez cai no campo certo em cada mercado, em vez de continuar em inglês em uma listagem que está localizada em todo o resto. E ele publica: o Mokbi envia a listagem finalizada direto para o Google Play via Play Developer API, e a deixa pronta no App Store Connect para envio — a Apple ainda exige o Submit final e a revisão do próprio lado, o que é uma regra da Apple e exatamente a assimetria entre lojas que este post inteiro explica. Essa última revisão é também onde os relógios deste post começam a contar.