O TestFlight é a ferramenta da Apple para distribuir uma app antes de ela estar na App Store. Envia o binário assinado para o App Store Connect, convida pessoas, e elas instalam-no no próprio iPhone através da app TestFlight. O que recebem não é uma pré-visualização nem um simulador: é exatamente o build que vai submeter depois ao App Review, com o seu ícone, as suas permissões e o seu código nativo.
Três números enquadram todo o serviço. Até 100 testadores internos, membros da sua equipa no App Store Connect, até 10 000 testadores externos convidados por e-mail ou através de um link público, e 90 dias de validade para cada build. Tudo o resto, da revisão beta às capturas de ecrã de feedback, decorre da forma diferente como estes dois grupos são tratados. Este guia percorre o caminho do envio até ao telemóvel de um testador, e depois lista os limites e os erros que atrasam um lançamento.
O TestFlight é uma etapa de um percurso mais longo. Se precisar da sequência completa, da conta de programador ao lançamento, leia o nosso guia sobre como publicar uma app na App Store.
O que é o TestFlight e onde se situa
O TestFlight vive dentro do App Store Connect, no separador com o mesmo nome, e nos dispositivos dos testadores como uma app gratuita da App Store. Do seu lado exige uma adesão ao Apple Developer Program; do lado do testador, apenas uma Conta Apple. Cobre iOS, iPadOS, macOS, tvOS, watchOS e visionOS, pelo que um build para Mac ou Vision Pro segue o mesmo fluxo que um build para iPhone.
O seu lugar no pipeline é entre o build e a revisão. As ferramentas anteriores mostram o seu código num telemóvel mais depressa, mas não como a sua app real: o Expo Go carrega apenas o seu JavaScript dentro de um invólucro partilhado, e um development build transporta o seu código nativo mas com as ferramentas de desenvolvimento lá dentro. O TestFlight é o primeiro momento em que tem o binário de produção nas mãos. O nosso guia sobre testar com o Expo Go cobre essa etapa anterior e os seus limites.
Do envio ao telemóvel de um testador, passo a passo
1. Envio e processamento
Um build chega ao App Store Connect a partir do Xcode, da app Transporter da Apple, de um serviço de build como o EAS Submit, ou de uma plataforma como a Cadrant que opera o EAS por si. Depois de enviado, o build passa por um processamento: a Apple verifica o pacote, indexa os símbolos e analisa-o, o que demora de alguns minutos a cerca de uma hora nas alturas de maior afluência. Aparece depois no separador TestFlight da sua app com um estado.
A primeira paragem é muitas vezes «Missing Compliance». A Apple pergunta se a app usa encriptação para além da que o iOS fornece; para a maioria das apps que apenas fazem chamadas HTTPS, a resposta é não, e pode definir a chave ITSAppUsesNonExemptEncryption na configuração da app para que a pergunta nunca mais bloqueie um build. Enquanto a resposta não ficar registada, ninguém consegue instalar o build.
2. Testadores internos: a sua equipa, sem revisão
Os testadores internos são as pessoas que têm uma função na sua equipa do App Store Connect: Admin, App Manager, Developer, Marketing ou Customer Support. Pode ter até 100 por app, e recebem cada build minutos depois do processamento, sem qualquer revisão da Apple. Pode até assinalar «distribuir automaticamente» num grupo interno para que cada novo envio siga sozinho. É o ciclo da sua própria equipa: enviar, testar, corrigir, voltar a enviar, várias vezes por dia se for preciso.
3. Testadores externos: até 10 000 pessoas e uma revisão beta
Os testadores externos são todos os outros: clientes, amigos, uma lista de espera. Organiza-os em grupos, convida-os por e-mail ou partilha um link público, e cada grupo pode receber builds diferentes. O limite é de 10 000 testadores externos por app, somando todos os grupos. A visão geral do TestFlight da Apple fixa as regras dos dois círculos.
A diferença em relação ao teste interno é a Beta App Review. O primeiro build que adiciona a um grupo externo é enviado ao App Review para confirmar que respeita as App Review Guidelines, na prática uma verificação mais leve do que a revisão de lançamento, que costuma ficar concluída em menos de um dia. Os builds seguintes da mesma versão saem muitas vezes sem uma nova revisão completa, a menos que altere algo a que a Apple dá importância. Para que essa revisão passe, preencha as informações de teste: o que testar, um e-mail de contacto e uma conta de demonstração se a app exigir início de sessão.
4. Do lado do testador
Um testador instala a app TestFlight, abre o e-mail de convite ou o link público, aceita e toca em Instalar. A app aparece no ecrã principal com um ponto laranja ao lado do nome, o sinal de que se trata de uma beta. Quando envia um novo build, o TestFlight avisa-o e pode atualizar automaticamente. Para enviar feedback, tira uma captura de ecrã e usa a folha de partilha, ou abana o dispositivo se tiver ativado essa opção; a captura e o comentário chegam ao App Store Connect, juntamente com os registos de falhas de qualquer crash que a app sofra durante o teste.
Limites, prazos e os erros que custam uma semana
| Regra | Valor | Consequência |
|---|---|---|
| Testadores internos | 100 por app, utilizadores do App Store Connect | Adicione primeiro os colegas à equipa; precisam de uma função, não apenas de um e-mail |
| Testadores externos | 10 000 por app, e-mail ou link público | Um link público pode ter um limite e ser fechado; os critérios no link reduzem quem entra |
| Beta App Review | Primeiro build por grupo externo, normalmente em menos de um dia | Planeie o primeiro build externo um dia antes de precisar dos testadores nele |
| Validade do build | 90 dias | Depois disso, a app deixa de abrir nos testadores até ser enviado um novo build |
| Processamento | De alguns minutos a cerca de uma hora | Não volte a enviar um build porque «ainda não apareceu»; espere pelo e-mail |
| Custo | Gratuito com o Developer Program | A adesão de 99 USD por ano é a única despesa |
Os atrasos de que as pessoas se queixam raramente vêm da Apple. Vêm destes erros:
- Deixar a pergunta sobre a encriptação sem resposta. O build fica em Missing Compliance e os convites nunca partem. Defina a chave de encriptação na configuração uma vez por todas.
- Esperar que o teste externo seja imediato. O interno é imediato; o externo espera pela Beta App Review. Use um grupo interno nas primeiras horas e o grupo externo nos primeiros dias.
- Sem notas de teste, sem conta de demonstração. A Beta App Review precisa de uma porta de entrada, exatamente como a revisão de lançamento. Um início de sessão que funciona poupa um build rejeitado.
- Convidar a Conta Apple errada. O convite está ligado ao e-mail; se o dispositivo do testador usar outra Conta Apple, o convite nunca corresponde. Os links públicos evitam o problema.
- Tratar o TestFlight como um canal de distribuição. As diretrizes proíbem usá-lo para entregar uma app ao público em vez da App Store, e os builds morrem de qualquer forma ao fim de 90 dias.
O TestFlight com a Cadrant
Se a sua app foi construída com o criador de apps móveis da Cadrant, as etapas antes do TestFlight ficam tratadas por si: o build iOS corre na sua própria conta Expo (o plano gratuito cobre 15 builds iOS por mês), e o Expo entrega o binário terminado à sua conta do App Store Connect, onde a ficha da app e o certificado de distribuição foram criados durante um percurso guiado. A partir daí, está no percurso TestFlight normal: abra o App Store Connect, responda à pergunta sobre a encriptação se lhe for feita, adicione testadores internos ou um grupo externo, e instale nos seus dispositivos.
O que deve verificar aí é o que a pré-visualização no editor e o Expo Go não conseguem mostrar: APIs nativas como a câmara, as notificações push e os seletores de ficheiros, os fluxos de início de sessão e de dados contra o seu projeto Supabase, o desempenho num dispositivo real, e o comportamento com permissões recusadas ou sem ligação. Encontrou um bug? Corrija-o na Cadrant, publique um novo build, distribua-o e repita até estar pronto para o App Review. A documentação Testar com o TestFlight lista os cliques exatos.
Em resumo
- Enviar, esperar pelo processamento, responder à pergunta sobre a encriptação: só então alguém pode instalar.
- Os testadores internos (100 membros da equipa) recebem os builds de imediato; os testadores externos (10 000) esperam por uma Beta App Review no primeiro build de uma versão.
- Preencha as notas de teste e uma conta de demonstração, convide por link público sempre que puder, e não se esqueça da expiração aos 90 dias.
- Teste no TestFlight o que o Expo Go não consegue mostrar, porque o revisor vai fazê-lo.
Usado desta forma, o TestFlight não é uma etapa a mais antes do lançamento: é o lançamento, ensaiado com pessoas reais em telemóveis reais, uns dias mais cedo.