Os novos artigos do App Review Help da Apple, lidos por um criador de apps de Mac

Resposta curta

Na sua nota Hello Developer de novembro de 2026, a Apple apontou aos desenvolvedores novos artigos de ajuda do App Review. Eles colocam por escrito coisas que a maioria de nós aprendeu com rejeições: a Apple pretende revisar 50% dos envios em menos de 24 horas e 90% em menos de 48; os logins de demonstração precisam continuar funcionando quando a revisão começa; você deve responder no App Store Connect em vez de reenviar para responder a uma pergunta; uma rejeição que começa com "Bug Fix Submissions:" permite que você publique a correção e resolva o problema na próxima vez; mais da metade das suas capturas de tela deve mostrar o app em uso; e toda permissão precisa da sua própria purpose string clara. Só um artigo menciona o Mac pelo nome, mas todas as regras valem para um envio à Mac App Store.

A maior parte do que sei sobre o App Review aprendi com e-mails de rejeição. Então, quando o Hello Developer de novembro de 2026 da Apple disse “Veja os novos artigos de ajuda do App Review”, eu li todos. Agora eles ficam em um só lugar, o App Review Help, e dizem em voz alta muita coisa que antes era folclore.

Aqui está o que há neles que importa para um app de Mac, e o que eu mudaria antes do meu próximo envio.

Primeiro, para quem é isto

O App Review só olha o que passa pelo App Store Connect: a Mac App Store, o TestFlight, as In-App Purchases e o resto. Se você vende o seu app de Mac pelo seu próprio site com um Developer ID, ninguém na Apple o revisa. Ele passa pela notarização, que é uma verificação automática. Então, se você distribui só direto, dê uma olhada rápida e guarde este artigo para o dia em que adicionar uma versão para a Mac App Store.

Quanto tempo leva uma revisão

O artigo sobre o status da revisão dá a meta da própria Apple: revisar pelo menos 50% dos envios em menos de 24 horas e 90% em menos de 48 horas. Ele também diz o que deixa uma revisão mais lenta, como um histórico de revisões limitado, documentos de que a Apple precisa ou problemas complexos ou inéditos.

O que eu faria: planejar um dia de lançamento com dois dias livres antes, mais para um primeiro app. E enviar cedo com liberação manual, para você escolher o minuto em que ele entra no ar.

É no campo Notes que as revisões são ganhas

O artigo sobre revisão completa é direto: “Envios incompletos serão rejeitados.” Os detalhes que importam:

Os logins de demonstração precisam funcionar quando a revisão começa, não só quando você envia. Uma conta de teste que expira ou muda nesse meio-tempo pode levar à rejeição.
Se o login precisa de um código, coloque em Notes. Sem ele, a Apple pode precisar ligar, e as ligações costumam ser feitas em três a cinco dias úteis. É uma semana perdida.
Assinaturas precisam de uma conta de demonstração com assinatura expirada, para que quem revisa veja todo o fluxo de compra.

O que eu faria: escrever o campo Notes como um tutorial curto para um desconhecido. Onde clicar primeiro, qual conta usar e o que o ícone da barra de menus faz se o seu app não tem janela. Esse último é bem Mac.

Quando é rejeitado

Esta é a parte que eu queria ter tido por escrito anos atrás.

Não reenvie para responder a uma pergunta. Se o App Review pedir informações, responda no App Store Connect. Reenvie só para uma correção no build, e só depois de resolver todos os problemas apontados.
Procure "Bug Fix Submissions:" no topo. Se uma rejeição começa com essa nota, o artigo sobre Bug Fix Submissions diz que você pode responder aceitando e resolver o problema na próxima atualização. Não reenvie. Só funciona para apps que já foram aprovados antes, nunca para problemas legais ou de segurança, e um problema não pode ser adiado duas vezes.
Peça revisão acelerada só quando for real. A Apple diz que os pedidos acelerados “devem ser reservados para casos de urgência genuína”, e só para builds já enviados para revisão. Para um lançamento ligado a um evento, coloque o evento e a data em Notes.
Recorra por último. Primeiro responda à rejeição e explique. Se isso não funcionar, o App Review Board aceita um recurso por app, e depois que você reenviou, não dá mais para recorrer dessa rejeição.

Quatro regras, com números

Os artigos sobre as diretrizes são curtos e concretos.

Capturas de tela, 2.3.3. Mais da metade das suas capturas de tela deve mostrar o app em uso, contadas por tipo de dispositivo. Com três capturas, duas precisam mostrar o app. Uma tela de abertura ou um cartão de título são aceitos desde que sejam a minoria. O verificador de capturas de tela do MacPip confere os tamanhos, e o resto você mesmo pode contar.
Imitações, 4.1. Não coloque nomes de apps populares ou termos com marca registrada em nenhum campo de metadados. Isso inclui as palavras-chave, onde o nome de um concorrente é o deslize clássico. O verificador de palavras-chave da App Store conta os seus campos para você ver o que há neles.
Purpose strings, 5.1.1(ii). Cada recurso protegido precisa da sua própria purpose string clara, localizada se o seu app for. O mau exemplo da própria Apple é "To use location." E você também é responsável pelo que os seus SDKs pedem. Cole o seu Info.plist na explicação do Info.plist e ela aponta as vazias e as vagas.
Exclusão de conta, 5.1.1(v). Se as pessoas podem criar uma conta no seu app, elas precisam poder iniciar a exclusão dentro do app. Desativar não basta, e você não pode obrigá-las a ligar para você. Se houver assinatura, avise que a cobrança continua pela Apple até que ela seja cancelada.

A única linha sobre o Mac

Só o artigo sobre dispositivos compatíveis cita o Mac. Ele diz que apps compatíveis de iPhone e iPad podem rodar sem modificação em Macs com Apple silicon, e que apps que dependem de toques impossíveis de fazer com um teclado não são adequados para o macOS. Se você faz um app de iPad, veja se ele aparece na Mac App Store e desative isso se ele não funcionar bem com teclado e trackpad. A mesma página diz que o TestFlight aceita até 100 testadores internos e 10.000 externos, e que o primeiro build que você entrega aos testadores externos também passa pelo App Review.

O What's New também conta

Mais uma, que vem das diretrizes e não dos artigos novos. A Guideline 2.3.12 diz que o texto de What's New deve descrever novos recursos e mudanças, e só correções simples de bugs e trabalho de desempenho podem passar com uma linha genérica. "Bug fixes and improvements" em uma versão com um recurso novo é pedir uma pergunta.

Então a nova ferramenta grátis de hoje é o formatador de notas de versão. Cole notas soltas ou as linhas do seu git log --oneline. Ele as separa em Novidades, Melhorias e Correções, descarta as linhas de chore, ci e merge, avisa sobre números de tickets e nomes de arquivos, confere o limite de 4.000 caracteres e entrega três cópias: texto simples para o App Store Connect, HTML para o seu appcast do Sparkle e Markdown para o GitHub. Suas notas ficam no seu navegador. O verificador de appcast do Sparkle fica ao lado, para o feed onde elas entram.

Minha lista curta

Dois dias livres antes do dia do lançamento, e liberação manual.
Um campo Notes que um desconhecido consiga seguir, com uma conta de demonstração funcionando.
Responda, não reenvie, quando só fizerem uma pergunta.
Conte as capturas de tela, leia cada purpose string e mantenha nomes de outros apps fora das palavras-chave.
What's New que diz o que mudou.

E depois que ele estiver no ar, listar no MacPip é grátis, esteja ou não na Mac App Store. As listagens são analisadas automaticamente quando são enviadas, e um selo azul só quer dizer que uma pessoa testou o app em uma data.

Fontes

Continue lendo

Envie seu app Ferramentas grátis para criadores

A Apple deixou por escrito como o App Review funciona. Aqui está o que eu mudaria antes de enviar