Publicar na App Store: todas as tuas perguntas respondidas no nosso AMA no Reddit

As capturas de ecrã têm duas funções ao mesmo tempo: convencer alguém a descarregar a tua app e ajudar a Apple a perceber o que ela faz durante a revisão. Destaca as funcionalidades principais e o valor que trazem, em vez de mostrar ecrãs aleatórios — se a tua app tem algo que a torna diferente, um workflow único, uma funcionalidade de comunidade, um caso de uso específico, garante que isso fica visível.

Um pormenor que apanha mais gente do que seria de esperar: as tuas capturas de ecrã têm de corresponder à versão da app que estás mesmo a submeter. É surpreendentemente comum redesenhar parte de uma app, submeter um novo build e esquecer-se de atualizar as capturas de ecrã da App Store — e uma discrepância significativa entre o que é mostrado e o que está a ser revisto pode levantar dúvidas durante a App Review. A Apple também disponibiliza molduras de produto oficiais para apresentares as tuas capturas de forma limpa e coerente, vale a pena usá-las se ainda não o fazes. Um último ponto assinalado pelos nossos engenheiros iOS: capturas de ecrã que mostram o produto ou serviço de um concorrente já causaram problemas na revisão, por isso o melhor é evitá-las por completo.

Só precisas de um número D-U-N-S se quiseres inscrever-te no Apple Developer Program como Organização. Se publicares como individual, não precisas de todo.

Para obter uma conta de Organização, primeiro tens de registar a tua entidade na Dun & Bradstreet (ou num parceiro local) — obter o número D-U-N-S demora normalmente cerca de duas semanas, e a Apple pode pedir informação adicional durante a inscrição. Em troca, uma conta de Organização traz vantagens reais: a tua organização aparece como programador na App Store em vez do teu nome pessoal, encaixa-se geralmente melhor em empresas e equipas (sobretudo se a titularidade mudar ao longo do tempo), facilita demonstrar a titularidade da tua marca e conteúdo durante a revisão, e em alguns países pode tornar-te elegível para uma isenção da taxa do Apple Developer Program. Se és um developer independente que publica as suas próprias apps, por outro lado, uma conta Individual é perfeitamente válida e livra-te totalmente do requisito do D-U-N-S.

Uma fonte de confusão recorrente: os erros crípticos do Transporter ao enviar um build. Três dos mais comuns, explicados:

• "No suitable application records were found" → provavelmente o registo da app ainda não existe no App Store Connect.
• "Potential loss of keychain" → normalmente é só um aviso, que surge quando a app foi transferida entre contas de programador Apple.
• "Redundant binary upload" → provavelmente estás a enviar um build com o mesmo número de versão ou de build de um que já lá está.

Uma das perguntas que mais nos fazem. Pelo que vemos ao ajudar os nossos clientes a publicar, a maioria das revisões fica concluída em 24 a 48 horas, embora possa demorar mais consoante a app e a carga de trabalho da Apple.

Se tens um prazo — um evento de lançamento, uma data de saída — submete o mais cedo possível em vez de esperar até ao último momento. Assim, se a Apple pedir alterações antes de aprovar, ainda tens tempo para as resolver. E se o teu calendário ficar mesmo apertado, a Apple oferece um pedido de revisão acelerada para situações urgentes. Não é garantido, mas vale a pena tentar sempre que tenhas uma data fixa a cumprir.

O melhor momento para sair da beta não é quando a tua app está perfeita — é quando está pronta para utilizadores reais. Na prática: a experiência principal está sólida, a app já tem conteúdo relevante, e os teus utilizadores beta continuam a voltar porque ela resolve mesmo um problema para eles.

A segunda parte importa tanto quanto a primeira: não publiques sem um plano de lançamento. Um erro comum é concentrar toda a energia em conseguir a aprovação, para depois perceber que ninguém sabe que a app existe. Um público-alvo claro e uma resposta clara a "porque é que alguém escolheria esta app em vez de outra" tem um impacto muito maior na tração do que lançar uns dias mais cedo. E essa resposta não ajuda só o marketing: também tende a alinhar-se com o que a Apple procura durante a App Review. As apps que trazem algo genuinamente útil ou distinto costumam ter um percurso mais simples do que as que parecem mais uma variante de algo que já existe.

As duas plataformas podem ser complicadas, cada uma à sua maneira. Pelo que vemos, as primeiras submissões são rejeitadas mais vezes do lado da Apple do que na Google Play — mas isso não significa que a Google Play seja mais fácil. Tem as suas próprias limitações, que podem criar tanto atrito como as da Apple, dependendo do tipo de conta de programador e da configuração da app. Nas atualizações, a taxa de rejeição costuma ser muito mais parecida entre as duas.

Um utilizador antigo da GoodBarber resumiu bem este compromisso no tópico: publicar na Apple é todo um processo, e há sempre algum motivo pelo qual uma app acaba sinalizada — mas ter a documentação e o suporte da GoodBarber para orientar tira grande parte do stress, e garante que a app se mantém em conformidade com as políticas das lojas ao longo do tempo. Também referiu que a Google Play, antigamente a plataforma mais simples, também se tornou mais rigorosa: as apps precisam agora de atualizações regulares, ou a conta de programador arrisca-se a ser sinalizada. Um suporte fiável nas duas frentes, segundo ele, não tem preço.

Há mesmo muito para dizer sobre a Google Play em particular — o suficiente para estarmos a preparar um AMA dedicado a esse tema em vez de misturar tudo aqui.

Tudo o que foi referido acima é exatamente o que a nossa equipa de suporte gere todos os dias — e é também por isso que este serviço existe como uma oferta dedicada: GoodBarber Takes Care (GBTC). Em vez de lidares tu mesmo com a App Review, a equipa GBTC submete a app à App Store e à Google Play em teu nome, do início ao fim. A Apple rejeita, em média, cerca de 42% das primeiras submissões — muitas vezes por motivos difíceis de antecipar — mas, nos últimos 12 meses, a equipa GBTC conseguiu que 91% dessas primeiras submissões rejeitadas fossem finalmente aceites. Nas atualizações, o trabalho de prevenção feito antecipadamente reduz a taxa de rejeição para apenas 5%. Se preferires deixar a App Review a cargo de uma equipa que vive nisto todos os dias, é exatamente para isso que serve a GBTC.

Isto foi o resumo, mas o tópico original continua a valer a pena de ler para o detalhe completo de cada resposta — e continua aberto, por isso, se tiveres uma pergunta que não abordámos, ainda podes publicá-la lá: AMA sobre publicação na App Store no r/GoodBarber.

Este foi o nosso segundo AMA em direto. Diz-nos nos comentários que tema gostarias que abordássemos da próxima vez.