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
- No Xcode, selecione o projeto > Targets > seu app.
- Abra a aba Signing & Capabilities.
- Em Team, selecione sua equipe (sua conta do Developer Program).
- Marque Automatically manage signing (recomendado para iniciantes e a maioria dos apps).
- Confirme o Bundle Identifier (ex.:
com.suaempresa.meuapp). Ele precisa ser único globalmente. - 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
- Projeto > Target do app > aba General.
- Em Identity, ajuste Version e Build.
- 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.
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
Passo a passo: criar Archive no Xcode
- No topo do Xcode, selecione um destino apropriado: escolha Any iOS Device (arm64) (ou um dispositivo físico). Evite “iOS Simulator” para Archive.
- Vá em Product > Archive.
- 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
- No Organizer > selecione o Archive > clique em Distribute App.
- Escolha App Store Connect.
- Escolha Upload.
- Mantenha as opções padrão quando não tiver certeza (o Xcode normalmente gerencia assinatura e símbolos automaticamente).
- 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
- No App Store Connect, abra My Apps e selecione seu app.
- Vá em TestFlight.
- Selecione o build recém-processado.
- Preencha o campo What to Test (instruções para testadores). Seja objetivo: o que validar, fluxos principais, credenciais de teste se necessário.
- Adicione testadores internos (selecionando usuários da equipe) e/ou crie um grupo de testadores externos.
- 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
- Acesse App Store Connect > My Apps > + > New App.
- Escolha a plataforma iOS.
- Defina Name (nome exibido na loja), Primary Language, Bundle ID (o mesmo do Xcode) e SKU (identificador interno, ex.:
MEUAPP_IOS_001). - 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
- No App Store Connect, abra seu app > vá em App Store > selecione a versão (ex.:
1.0). - Preencha todos os campos obrigatórios (metadados, screenshots, classificação etária, privacidade, informações de revisão).
- Em Build, selecione o build enviado (ele precisa estar processado e disponível).
- Responda se o app usa criptografia (export compliance) quando solicitado.
- 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”)
| Área | Verificação |
|---|---|
| Identidade | Bundle ID correto, Team correto, assinatura automática funcionando |
| Versão | Version definida e Build incrementado (build único para cada upload) |
| Archive | Archive em Release, Validate sem erros, upload concluído |
| TestFlight | Build testado em fluxos principais, sem crashes conhecidos |
| Permissões | Usage Descriptions no Info.plist com textos específicos e verdadeiros |
| Privacidade | App Privacy preenchido e consistente com SDKs e política de privacidade |
| Metadados | Descrição, keywords, categoria, URLs de suporte/privacidade corretas |
| Assets | Ícone final, screenshots corretos por dispositivo, sem conteúdo enganoso |
| Revisão | App Review Information com instruções e login de teste (se necessário) |
| Qualidade | Sem 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.