Checklist de envio para a App Store (2026): do build no Xcode 26 ao Submit for Review

Um checklist de envio para a App Store é a lista do que precisa estar pronto ao mesmo tempo antes de você enviar: um build funcional, uma página da loja precisa, respostas de privacidade verdadeiras e contexto suficiente para que o revisor consiga usar o app. Um build que compila sem erros não basta. As seis seções abaixo seguem a ordem em que o App Store Connect pede cada item, e cada uma começa com uma resposta curta e prática.

O que um envio para a App Store precisa ter antes de você clicar em Submit?

Um envio para a App Store precisa de um build processado vinculado à versão, dos metadados obrigatórios da versão, capturas de tela, uma política de privacidade, dados de contato para o App Review e, se o app tiver login, credenciais de demonstração que funcionem. A própria lista "Before You Submit" da Apple nas Diretrizes de revisão da App Store acrescenta mais dois itens: "Ative os serviços de backend para que estejam ativos e acessíveis durante a revisão" e explique os recursos que não são óbvios nas notas de revisão.

Quais configurações de conta e do registro do app precisam estar prontas?

Você precisa de uma assinatura ativa do Apple Developer, de um registro do app cujo bundle ID corresponda ao build assinado e de alguém na equipe com a função Account Holder, Admin ou App Manager. Essas são as funções que a página Submit an app da Apple exige para enviar.

Ao criar o registro, escolha o nome, o idioma principal e o SKU. O SKU é interno e os clientes nunca o veem. Se você vende um app pago ou compras dentro do app, conclua antes os contratos pagos, os dados fiscais e bancários. Um contrato não assinado pode atrasar um lançamento comercial mesmo quando o build está perfeito.

Quais requisitos de build se aplicam aos uploads para a App Store em 2026?

Em outubro de 2026, a página de requisitos futuros da Apple diz que "os apps enviados ao App Store Connect devem ser compilados com o Xcode 26 ou posterior usando um SDK do iOS 26, iPadOS 26, tvOS 26, visionOS 26 ou watchOS 26" (desde 28 de abril de 2026). Ela também diz que apps para iOS e iPadOS "devem ter como alvo o iOS 13 ou posterior" (desde 9 de setembro de 2026).

• Aumente o número de build a cada upload e confirme que o número de versão corresponde à versão que você pretende lançar.
• Atualize a imagem do Xcode no CI (Codemagic, Expo EAS, GitHub Actions etc.), além da sua própria máquina.
• Depois do processamento, responda a qualquer pergunta de conformidade de exportação e vincule o build processado à versão.
• Instale o build do TestFlight em um dispositivo físico. Teste o onboarding, o login, os estados offline, as compras e a restauração de compras. Funcionar no simulador não prova que o build distribuído funciona.
• Leia o e-mail que o App Store Connect envia após o upload. Avisos ITMS sobre privacy manifests ou versões de SDK viram bloqueios se forem ignorados.

A diretriz 2.1(a) é direta sobre o que acontece caso contrário: "Vamos rejeitar pacotes e binários de apps incompletos que travem ou apresentem problemas técnicos evidentes." Remova telas provisórias, menus de debug e links quebrados antes de gerar o archive. Nosso plano de testes do build de release para a 2.1 detalha essas verificações.

Quais capturas de tela e metadados o App Store Connect exige?

Em outubro de 2026, as especificações de capturas de tela da Apple exigem pelo menos uma captura para "iPhone com Dynamic Island (tela média)", por exemplo 1206 × 2622 ou 1179 × 2556 em retrato. Apps que rodam no iPad também precisam de pelo menos uma captura de iPad de 13 polegadas, como 2064 × 2752 ou 2048 × 2732.

Você "pode enviar até 10 capturas de tela por tamanho de dispositivo nos formatos .jpeg, .jpg ou .png", e "as imagens não podem incluir canais alfa nem transparências." Se a interface for igual em todos os tamanhos, envie apenas a maior resolução exigida e o App Store Connect a reduz. A diretriz 2.3.3 diz que as capturas de tela "devem mostrar o app em uso, e não apenas a arte do título, a tela de login ou a splash screen."

• Escreva uma descrição que diga para quem é o app e o que a pessoa consegue fazer na primeira sessão.
• Mantenha o nome, o subtítulo e as palavras-chave relevantes. Não repita palavras-chave nem use nomes de concorrentes.
• Garanta que a URL de suporte e a URL da política de privacidade abram sem exigir login.
• Responda ao questionário de classificação etária com base no que o app realmente contém e permite fazer.
• Mostre o build atual nas capturas de tela, incluindo qualquer paywall que o usuário vá encontrar.

Como fazer as respostas de privacidade corresponderem ao app?

Para que as respostas de privacidade correspondam ao app, liste todos os SDKs que você inclui e os dados que cada um coleta, e use essa lista para preencher o App Privacy, redigir a política de privacidade e configurar o comportamento dentro do app. A diretriz 2.3 diz que seus metadados, "incluindo as informações de privacidade", devem refletir o app com precisão.

A diretriz 5.1.1(i) determina: "Todos os apps devem incluir um link para a política de privacidade no campo de metadados do App Store Connect e dentro do app, de forma facilmente acessível." A diretriz 5.1.1(v) acrescenta: "Se o seu app permite criar uma conta, você também deve oferecer a exclusão da conta dentro do app." SDKs de analytics, relatórios de crash, anúncios e login costumam mudar suas respostas, então audite-os com nossa auditoria de SDKs para os rótulos de privacidade. Verifique também se o app e cada SDK incluído trazem um privacy manifest PrivacyInfo.xcprivacy que cubra as APIs com motivo obrigatório (required-reason APIs) que eles usam.

O que incluir em App Review Information?

O App Review Information deve incluir um contato que responda, credenciais de demonstração que funcionem e não expirem, e notas que levem o revisor direto aos recursos principais. A diretriz 2.1(a) pede que você "inclua as informações da conta demo (e ative seu serviço de backend!) se o app tiver login"; um modo demo embutido no lugar de uma conta exige aprovação prévia da Apple.

Veja um exemplo prático de notas de revisão: "Entre com a conta de revisão fornecida. Abra Library, escolha o projeto de exemplo e toque em Export. A conta tem todos os recursos premium liberados. Os recursos de localização usam uma cidade simulada, então não é preciso se deslocar." Não mande o revisor para uma conta vazia, um código de uso único que expira ou um fluxo que só funciona enquanto você está online para aprová-lo. Nosso guia de configuração de conta demo mostra como criar um login de revisão que funcione de verdade.

Como enviar um app para revisão no App Store Connect?

Para enviar um app para revisão, vincule o build à versão, clique em Add for Review e depois em Submit for Review. Só o Add for Review não envia nada à Apple. A sequência abaixo segue a página Submit an app da Apple em outubro de 2026.

1. Em Apps, selecione o app e clique na versão do app na barra lateral.
2. Role até a seção Build e confirme que o build correto está vinculado.
3. Na seção App Store Version Release, escolha o lançamento manual se quiser controlar o dia do lançamento e clique em Save.
4. Clique em Add for Review e escolha um rascunho de envio existente ou crie um novo. O status muda para Ready for Review.
5. Clique em Submit for Review. Quando a revisão começar, o status muda para In Review.
6. Guarde uma cópia dos metadados e das notas enviados e acompanhe o e-mail do contato de revisão caso surjam perguntas.

Se o envio voltar rejeitado, leia o número da diretriz e a explicação do revisor antes de mudar qualquer coisa. Algumas correções envolvem só metadados. Outras exigem um novo build. Nosso guia de rejeição na App Store explica como identificar qual é o seu caso.

O que deu errado para outros desenvolvedores no envio?

Nos dois casos públicos abaixo, o app funcionava para o próprio desenvolvedor, e o problema só apareceu no build enviado ou na primeira sessão do revisor.

Um desenvolvedor no fórum do Adalo recebeu uma rejeição pela diretriz 2.1: "não conseguimos entrar com as credenciais da conta demo que você forneceu." As credenciais eram válidas, mas o primeiro toque no login não fazia nada e só o segundo funcionava, porque a navegação condicional rodava no botão de login antes de a sessão do usuário ser registrada. A solução foi direcionar o botão de login para uma tela de transição em branco que continha as ações condicionais, e então reenviar o app.

Um desenvolvedor no fórum do JUCE recebeu "ITMS-91053: Missing API declaration" após um upload, dizendo que novos uploads "devem incluir um array NSPrivacyAccessedAPITypes no privacy manifest do app." As categorias apontadas eram SystemBootTime e FileTimestamp, e outro usuário relatou UserDefaults. A solução foi um arquivo PrivacyInfo.xcprivacy com códigos de motivo aprovados, adicionado como recurso no Xcode. A primeira versão de um usuário omitiu uma chave de tipo, o que gerou o ITMS-91056 por manifest inválido até que ele fosse corrigido.

Os dois desenvolvedores tinham testado apenas no próprio ambiente. Teste o build que a Apple realmente recebe com um login novo e leia todos os e-mails pós-upload antes de clicar em Submit for Review. Se quiser uma segunda opinião sobre o pacote, veja nossos serviços de envio.