Preparação para App Store: assinatura, build, TestFlight e submissão do app iOS

Capítulo 14

Tempo estimado de leitura: 11 minutos

+ Exercício

O que significa “preparar para a App Store”

Publicar um app iOS envolve duas frentes que precisam estar alinhadas: (1) a parte técnica de assinatura e empacotamento do app (Signing, Bundle ID, versão/build, Archive e distribuição) e (2) a parte administrativa no App Store Connect (cadastro do app, metadados, privacidade, classificação etária, assets e envio para revisão). Um erro em qualquer uma delas costuma bloquear o upload, impedir o TestFlight ou gerar rejeição na revisão.

Pré-requisitos e contas

  • Apple Developer Program ativo (individual ou organização). Sem isso, você não consegue distribuir via TestFlight/App Store.
  • Acesso ao App Store Connect com permissão para criar apps e gerenciar builds (funções como Admin/App Manager/Developer).
  • Identidade do app definida: nome do app, Bundle Identifier e categoria.

Signing & Capabilities: identidade, permissões e entitlements

Conceitos essenciais

  • Signing (assinatura): garante que o app foi gerado por você/empresa e não foi alterado. No iOS, apps precisam ser assinados para rodar em dispositivos e para distribuição.
  • Provisioning: regras que dizem “quem pode rodar” e “como distribuir”. Para App Store/TestFlight, o provisioning é gerenciado automaticamente pelo Xcode na maioria dos casos.
  • Capabilities: recursos do sistema (Push Notifications, iCloud, Sign in with Apple, Associated Domains etc.). Ao ativar uma capability, o Xcode adiciona entitlements ao app e registra configurações no portal da Apple.

Passo a passo: configurar assinatura no Xcode

  1. No Xcode, selecione o projeto > Targets > seu app.
  2. Abra a aba Signing & Capabilities.
  3. Em Team, selecione sua equipe (sua conta do Developer Program).
  4. Marque Automatically manage signing (recomendado para iniciantes e a maioria dos apps).
  5. Confirme o Bundle Identifier (ex.: com.suaempresa.meuapp). Ele precisa ser único globalmente.
  6. Se houver extensões (Widgets, Share Extension etc.), repita a configuração para cada Target e garanta que os Bundle IDs sejam consistentes (ex.: com.suaempresa.meuapp.widget).

Adicionando capabilities com cuidado

Ative apenas o que você usa. Capabilities extras podem exigir configurações adicionais e gerar rejeição (por exemplo, declarar uso de Push sem usar, ou habilitar iCloud sem necessidade).

  • No mesmo painel, clique em + Capability e adicione somente as necessárias.
  • Após ativar, verifique se o app continua compilando e se não surgiram avisos de entitlements.

Bundle Identifier, versão e build number

Bundle Identifier

O Bundle ID é a identidade técnica do app. Depois que o app é criado no App Store Connect, mudar o Bundle ID geralmente significa “outro app”. Defina cedo e mantenha.

Version (Marketing Version) vs Build Number

  • Version (ex.: 1.0, 1.1): o número que o usuário vê na App Store.
  • Build (ex.: 1, 42): número interno que precisa aumentar a cada upload de build para o App Store Connect.

Passo a passo: ajustar no Xcode

  1. Projeto > Target do app > aba General.
  2. Em Identity, ajuste Version e Build.
  3. Antes de enviar um novo build, incremente o Build (mesmo que a Version não mude).

Dica prática: se você estiver testando muito via TestFlight, é comum manter a Version (ex.: 1.0) e subir o Build (1, 2, 3...). Quando for lançar uma atualização pública, aumente a Version (ex.: 1.1) e reinicie/continue o Build.

Gerando um Archive (pacote de distribuição)

O que é Archive

Um Archive é um build “fechado” para distribuição, gerado com configurações de release e assinatura apropriada. É a base para enviar ao TestFlight e à App Store.

Continue em nosso aplicativo e ...
  • Ouça o áudio com a tela desligada
  • Ganhe Certificado após a conclusão
  • + de 5000 cursos para você explorar!
ou continue lendo abaixo...
Download App

Baixar o aplicativo

Passo a passo: criar Archive no Xcode

  1. No topo do Xcode, selecione um destino apropriado: escolha Any iOS Device (arm64) (ou um dispositivo físico). Evite “iOS Simulator” para Archive.
  2. Vá em Product > Archive.
  3. Aguarde o processo. Ao finalizar, abrirá a janela Organizer na aba Archives.

Validação e distribuição

No Organizer, selecione o Archive e use:

  • Validate App: checa assinatura, entitlements, consistência e alguns requisitos antes do upload.
  • Distribute App: envia para App Store Connect (TestFlight/App Store).

Passo a passo: enviar para o App Store Connect

  1. No Organizer > selecione o Archive > clique em Distribute App.
  2. Escolha App Store Connect.
  3. Escolha Upload.
  4. Mantenha as opções padrão quando não tiver certeza (o Xcode normalmente gerencia assinatura e símbolos automaticamente).
  5. Conclua o upload e aguarde a confirmação.

Após o upload, o build pode levar alguns minutos (às vezes mais) para aparecer no App Store Connect, pois passa por processamento.

TestFlight: distribuir para testes internos e externos

Conceito

TestFlight é o canal oficial da Apple para distribuir builds para testadores antes do lançamento. Você pode ter:

  • Testes internos: membros da equipe no App Store Connect (geralmente mais rápido para começar).
  • Testes externos: usuários convidados por link/email; normalmente exige uma revisão rápida do build para testes.

Passo a passo: habilitar um build no TestFlight

  1. No App Store Connect, abra My Apps e selecione seu app.
  2. Vá em TestFlight.
  3. Selecione o build recém-processado.
  4. Preencha o campo What to Test (instruções para testadores). Seja objetivo: o que validar, fluxos principais, credenciais de teste se necessário.
  5. Adicione testadores internos (selecionando usuários da equipe) e/ou crie um grupo de testadores externos.
  6. Para externos, envie para revisão de TestFlight se solicitado e aguarde aprovação.

Boas práticas para testes via TestFlight

  • Crashes e logs: ative coleta de feedback e incentive testadores a enviar relatórios. Corrija crashes antes de submeter à App Store.
  • Compatibilidade: teste em diferentes tamanhos de tela e versões do iOS suportadas pelo seu app.
  • Permissões: valide fluxos que pedem acesso (câmera, fotos, localização). Se o texto de permissão estiver ausente ou genérico, isso pode gerar rejeição.

App Store Connect: cadastrar o app e preparar a página

Passo a passo: criar o registro do app

  1. Acesse App Store Connect > My Apps > + > New App.
  2. Escolha a plataforma iOS.
  3. Defina Name (nome exibido na loja), Primary Language, Bundle ID (o mesmo do Xcode) e SKU (identificador interno, ex.: MEUAPP_IOS_001).
  4. Selecione User Access conforme sua equipe.

Metadados essenciais (o que costuma travar revisão)

  • Descrição: explique claramente o que o app faz, sem promessas enganosas. Evite mencionar recursos que não existem.
  • Palavras-chave: relevantes e sem marcas registradas indevidas.
  • URL de suporte: obrigatória. Deve levar a uma página real com contato e informações do app.
  • URL de privacidade: obrigatória na maioria dos casos. Deve descrever coleta/uso de dados de forma coerente com o que você declarar em privacidade.
  • Categoria: escolha a mais adequada para reduzir risco de rejeição por posicionamento incorreto.

Privacidade: App Privacy (rótulos de privacidade)

No App Store Connect, você precisa declarar quais dados o app coleta e como são usados. Isso deve bater com o comportamento real do app e com sua política de privacidade.

  • Vá em App Privacy e responda o questionário.
  • Se você usa analytics, login, anúncios ou SDKs de terceiros, revise o que eles coletam.
  • Se você declara que não coleta dados, garanta que não há coleta indireta por bibliotecas.

Classificação etária (Age Rating)

Preencha o questionário de conteúdo. Responda com precisão: marcar conteúdo indevido pode elevar a idade mínima e reduzir alcance; omitir pode gerar rejeição.

Screenshots, ícone e pré-visualizações

  • Ícone: precisa estar correto no asset catalog e atender aos tamanhos exigidos. Evite bordas, transparência e elementos que pareçam botões do sistema.
  • Screenshots: devem representar o app real. Evite imagens enganosas, marketing exagerado e texto ilegível. Prepare por tamanho de dispositivo exigido.
  • Sem conteúdo proibido: nada de marcas de terceiros sem permissão, dados pessoais reais, ou telas com informações sensíveis.

Requisitos mínimos de qualidade (o que a Apple observa)

  • Estabilidade: não pode crashar em fluxos comuns. Crashes recorrentes são motivo frequente de rejeição.
  • Funcionalidade completa: botões que não fazem nada, telas vazias sem explicação e links quebrados costumam reprovar.
  • Conteúdo e precisão: descrição e screenshots devem corresponder ao app entregue.
  • Experiência: o app deve ser utilizável; telas de “em construção” ou conteúdo placeholder podem ser rejeitados.

Configurações adicionais comuns antes de enviar

Permissões (Usage Descriptions)

Se o app acessa recursos protegidos, você precisa incluir textos de justificativa no Info.plist (por exemplo, câmera, fotos, localização). Textos genéricos como “precisamos disso” aumentam chance de rejeição. Use frases específicas do benefício ao usuário.

NSCameraUsageDescription: Precisamos da câmera para você escanear documentos e anexar ao seu cadastro. NSPhotoLibraryUsageDescription: Precisamos acessar suas fotos para você selecionar uma imagem de perfil.

Login e conta de teste (quando aplicável)

Se o app exige login para funcionar, forneça credenciais de teste no campo de App Review Information no App Store Connect, além de instruções claras. Sem isso, a revisão pode falhar por não conseguir acessar funcionalidades.

Build settings e compatibilidade

  • Confirme o Deployment Target (versão mínima do iOS) coerente com seu público e com o que você testou.
  • Garanta que o app está em Release para Archive e que não depende de recursos apenas de debug.

Submissão para revisão (App Store)

Passo a passo: selecionar build e enviar

  1. No App Store Connect, abra seu app > vá em App Store > selecione a versão (ex.: 1.0).
  2. Preencha todos os campos obrigatórios (metadados, screenshots, classificação etária, privacidade, informações de revisão).
  3. Em Build, selecione o build enviado (ele precisa estar processado e disponível).
  4. Responda se o app usa criptografia (export compliance) quando solicitado.
  5. Clique em Submit for Review.

Acompanhando status até aprovação

Os status mais comuns no App Store Connect:

  • Prepare for Submission: você ainda está preenchendo dados.
  • Waiting for Review: enviado, aguardando fila.
  • In Review: em análise.
  • Pending Developer Release: aprovado, aguardando você liberar (se estiver em lançamento manual).
  • Ready for Sale: publicado na App Store.
  • Rejected: reprovado; você receberá o motivo e, geralmente, evidências (prints/logs).

Checklist de submissão (antes de clicar em “Submit for Review”)

ÁreaVerificação
IdentidadeBundle ID correto, Team correto, assinatura automática funcionando
VersãoVersion definida e Build incrementado (build único para cada upload)
ArchiveArchive em Release, Validate sem erros, upload concluído
TestFlightBuild testado em fluxos principais, sem crashes conhecidos
PermissõesUsage Descriptions no Info.plist com textos específicos e verdadeiros
PrivacidadeApp Privacy preenchido e consistente com SDKs e política de privacidade
MetadadosDescrição, keywords, categoria, URLs de suporte/privacidade corretas
AssetsÍcone final, screenshots corretos por dispositivo, sem conteúdo enganoso
RevisãoApp Review Information com instruções e login de teste (se necessário)
QualidadeSem links quebrados, telas vazias sem contexto, placeholders ou erros visuais graves

Problemas comuns e como resolver rapidamente

1) “No profiles found” / erros de assinatura

  • Confirme que você selecionou o Team correto no Target.
  • Ative Automatically manage signing.
  • Verifique se o Bundle ID no Xcode é o mesmo do App Store Connect.
  • Se houver múltiplos Targets, todos precisam estar assinados.

2) Build não aparece no App Store Connect

  • Aguarde o processamento (pode demorar).
  • Confirme que o upload foi para o app certo (Bundle ID).
  • Verifique se o Build number não foi repetido.

3) Rejeição por privacidade

  • Alinhe a declaração de App Privacy com o comportamento real e com SDKs.
  • Garanta que a Privacy Policy URL descreve claramente coleta, uso e retenção.

4) Rejeição por permissões (Info.plist)

  • Inclua todas as chaves necessárias para recursos usados.
  • Escreva descrições específicas do motivo do acesso.
  • Evite pedir permissão “na abertura” sem contexto; peça quando o usuário aciona a funcionalidade.

5) Rejeição por metadados inconsistentes

  • Screenshots devem refletir o app atual (mesma navegação/funcionalidades).
  • Descrição não pode prometer recursos ausentes.
  • Se há compras/assinaturas, isso deve estar claro e configurado corretamente.

6) Crashes durante revisão

  • Reproduza em um dispositivo limpo (sem dados) e em rede instável.
  • Teste primeiro fluxo (onboarding/login) com atenção: é onde a revisão mais esbarra.
  • Se o app depende de backend, garanta que o ambiente está estável e que há fallback/erros amigáveis.

Agora responda o exercício sobre o conteúdo:

Ao enviar um novo build para o App Store Connect (por exemplo, para TestFlight), o que você deve fazer em relação a Version e Build no Xcode?

Você acertou! Parabéns, agora siga para a próxima página

Você errou! Tente novamente.

O Build é um número interno que precisa aumentar a cada novo upload para o App Store Connect. A Version é a versão de marketing exibida ao usuário e pode permanecer igual durante testes, como no TestFlight.

Capa do Ebook gratuito iOS para Iniciantes com SwiftUI: do zero ao primeiro app na App Store
100%

iOS para Iniciantes com SwiftUI: do zero ao primeiro app na App Store

Novo curso

14 páginas

Baixe o app para ganhar Certificação grátis e ouvir os cursos em background, mesmo com a tela desligada.