TestFlight: como testar seu app de iPhone antes do envio

O que é o TestFlight e para que ele serve?

O TestFlight é o serviço da Apple que permite instalar seu app em iPhones de verdade antes do lançamento na App Store. Você envia uma build para o App Store Connect, convida testadores, e eles instalam o app pelo aplicativo TestFlight, gratuito na App Store. Existem dois tipos de testadores: os internos, até 100 membros da sua equipe, sem revisão da Apple; e os externos, até 10.000 pessoas, convidadas por e-mail ou por link público, depois de uma revisão beta da sua primeira build. Cada build fica disponível para teste por 90 dias.

Critério	Testadores internos	Testadores externos
Número máximo	100	10.000
Acesso à sua conta	Sim, com uma função	Não
Convite	Adição ao grupo interno	E-mail ou link público
Revisão beta da Apple	Nenhuma	Na primeira build
Para quem	Você, um sócio, alguém próximo	Amigos, primeiros usuários

Para usar o TestFlight, você precisa de uma conta Apple Developer paga: o serviço não está disponível com uma conta gratuita. Todo o resto deste guia parte do princípio de que você tem uma, pelo programa padrão: o programa Enterprise da Apple não dá acesso ao TestFlight.

Nos meus apps, cada build enviada pelo EAS Submit passa pelo TestFlight e pelo meu iPhone antes de ir para revisão. É ali que eu encontro os problemas que não aparecem durante o desenvolvimento.

Enviar uma build para o TestFlight

Uma build é uma versão compilada e assinada do seu app: se estiver mal assinada, a Apple recusa no envio com o erro ITMS-90034. Para ela aparecer no TestFlight, você precisa enviá-la ao App Store Connect. Com Expo, é eas build --platform ios e depois eas submit --platform ios, com uma imagem de build recente o bastante para evitar o ITMS-90725. Segundo a documentação do Expo, a build aparece no TestFlight depois do processamento pela Apple, geralmente em 10 a 15 minutos. Dá para fazer tudo isso de um PC: o guia publicar um app iOS sem Mac detalha o fluxo completo.

Dois detalhes costumam travar na primeira vez:

• O número da build precisa mudar a cada envio. A Apple recusa duas builds com o mesmo número para uma mesma versão. Com o EAS, ative o incremento automático e esqueça isso.
• A pergunta sobre criptografia. Enquanto você não responder à pergunta sobre o uso de criptografia, a build fica bloqueada com status de conformidade pendente (Missing Compliance). Você pode responder toda vez no App Store Connect, ou declarar de uma vez por todas na configuração do seu app.

Testadores internos: sua equipe, sem espera

Os testadores internos são usuários da sua conta App Store Connect, com uma função atribuída. A Apple permite até 100, e cada um pode instalar o app em vários dispositivos, até 30.

A grande vantagem: não tem revisão beta. Assim que a build termina o processamento, sem erro automático como o ITMS-90717, você a adiciona ao seu grupo interno e ela fica disponível. É o grupo certo para você, e para um sócio ou alguém próximo a quem você dá acesso à sua conta.

O limite: é preciso adicioná-los como usuários da sua conta App Store Connect. Não serve para desconhecidos.

Testadores externos e revisão beta

Os testadores externos não precisam de nenhum acesso à sua conta. Você pode convidar até 10.000, por e-mail ou por link público. É o grupo certo para amigos, primeiros usuários, uma comunidade.

Em troca, a Apple verifica a build antes de liberá-la para eles. Quando você adiciona a primeira build de uma versão a um grupo externo, ela vai para revisão beta. As builds seguintes da mesma versão não exigem necessariamente uma revisão completa.

Antes desse envio, o App Store Connect pede informações de teste:

• uma descrição da beta, que diz aos testadores o que eles devem observar;
• um endereço de e-mail para feedback;
• seus dados de contato, para a Apple conseguir falar com você.

A revisão beta não é a revisão da App Store. Uma build aceita no TestFlight ainda pode ser recusada na publicação.

A revisão beta verifica se a build segue as regras, mas a revisão final também olha sua página, suas assinaturas, seus textos legais e a experiência completa. Tenha em mente os motivos de recusa clássicos, explicados em por que a Apple recusa um app.

Convidar testadores por link público

O link público é o jeito mais simples de fazer pessoas que você ainda não conhece testarem seu app. Este é o passo a passo da Apple, com os nomes da interface em inglês:

1. No App Store Connect, abra seu app e depois a aba TestFlight.
2. Em External Testing, selecione seu grupo externo.
3. Clique em Create Public Link.
4. Escolha Open to Anyone para abrir o link para todo mundo, ou Filter by Criteria para limitá-lo a certos dispositivos e versões do iOS.
5. Se quiser, defina um limite de testadores com Set Limit.

Depois é só compartilhar o link onde quiser: mensagem, rede social, e-mail. A pessoa instala o app TestFlight, abre o link e aceita o convite.

Duas coisas para saber antes de divulgar amplamente:

• Defina um limite. Se o seu link circular mais do que o previsto, você mantém o controle do número de testadores.
• Os testadores por link público são anônimos. O App Store Connect só mostra para eles a data de instalação, as sessões e os crashes. Se você quer saber quem testou o quê, prefira convidar por e-mail.

Quanto tempo dura uma build do TestFlight?

Uma build fica disponível para os testadores por 90 dias. Depois disso, ela expira e seus testadores não conseguem mais abri-la. Se sua beta durar mais, é só enviar uma nova build antes do prazo.

Na prática, você vai enviar builds novas com muito mais frequência: a cada correção importante. Cada nova build adicionada ao grupo é oferecida aos seus testadores, que a baixam pelo app TestFlight.

Receber o feedback dos testadores

O TestFlight tem um sistema de feedback integrado: o testador tira um print dentro do seu app, pode fazer anotações e envia para você. Se o app travar, você recebe um relatório de crash, e o testador pode acrescentar contexto. Fica tudo no App Store Connect.

É útil, mas não basta para entender um crash específico. Nos meus apps, eu adiciono o Sentry, que mostra o erro com a linha de código responsável, e o PostHog, que mostra onde os usuários desistem. Os dois funcionam numa build do TestFlight do mesmo jeito que em produção.

Testar assinaturas no TestFlight

Se o seu app vende uma assinatura, o TestFlight é onde você confere se ela realmente funciona. As compras feitas numa build do TestFlight passam pelo ambiente de teste da Apple: seus testadores não são cobrados. As renovações são aceleradas: cada assinatura renova uma vez por dia, no máximo seis vezes em uma semana, seja qual for a duração real.

Confira no mínimo se os preços exibidos estão certos, se a compra realmente desbloqueia o app e se o botão de restaurar recupera a assinatura depois de uma reinstalação. Eu uso o RevenueCat para gerenciar as assinaturas dos meus apps; toda a configuração, dos produtos no App Store Connect ao paywall, está descrita na página assinaturas in-app no iOS.

O que você precisa testar antes de enviar para a Apple

Esta é a lista que eu sigo antes de cada envio para revisão. Cada item corresponde a um motivo de recusa ou a um crash evitável.

A primeira abertura

• Apague o app, reinstale pelo TestFlight e abra. É o que o revisor vai fazer.
• Percorra o onboarding inteiro, sem pular nada.
• Negue cada permissão (notificações, câmera, localização) e confira se o app continua funcionando.

O dinheiro

• O paywall mostra os preços, a duração e os links para os termos de uso e a política de privacidade.
• A compra funciona, a restauração também.
• Todos os produtos configurados estão visíveis para o revisor: a guideline 2.1 exige que as compras in-app estejam completas, visíveis e funcionando.

As condições difíceis

• Modo avião e rede lenta: uma mensagem clara, não uma tela em branco.
• O menor iPhone que você suporta e o maior: nada cortado, nada escondido pelo teclado. Foi uma tela cortada em iPhone pequeno que me rendeu uma recusa no Solys.
• Textos longos, se o seu app for traduzido.

O material para o revisor

• Se o seu app exige login, uma conta de demonstração nas notas de revisão, com seu backend ligado. A guideline 2.1 pede isso explicitamente.
• Notas de revisão que expliquem em duas frases o que o app faz e onde encontrar a função principal.

Se mesmo assim seu app for recusado, a página app recusado pela Apple explica como responder sem perder uma semana. E para a visão geral da publicação, da página da App Store ao lançamento, leia publicar um app na App Store.

Uma planilha de testes para preencher na sua build

Baixe a planilha com 16 cenários em formato CSV. Ela separa a preparação, a ação a executar, o resultado esperado e a evidência observada. Importe no Numbers, Excel ou Google Sheets e preencha a versão, o dispositivo e o resultado de cada teste.

Para um diário de leitura fictício, "salvar uma página" não basta: anote a página 24, feche o app por completo, abra de novo e confira se o valor está lá. Um teste que não foi executado continua como "A testar". Se o seu app não tem nenhuma assinatura, marque "Não se aplica" nos cenários de compra, com esse motivo.

A planilha é um ponto de partida para adaptar, não uma certificação. Veja também as notas para o App Review e os outros modelos gratuitos para explicar ao revisor o fluxo que você realmente verificou.

Do TestFlight para a App Store

O TestFlight é a etapa em que seu app vira realidade: ele roda num iPhone de verdade, nas mãos de pessoas de verdade. No percurso do iOS Kit, é a segunda etapa: construir o núcleo do app e testá-lo no seu iPhone com o TestFlight, antes de conectar as assinaturas e preparar a publicação.

Depois do TestFlight vem a revisão da Apple: o Apple Review Kit reúne meu checklist antes do envio e as notas para o revisor. A página inicial mostra as quatro etapas para criar seu app mobile com Claude Code.

Ninguém pode garantir que a Apple vai aceitar seu app: quem decide é a Apple.

Perguntas frequentes

Como testar meu app de iPhone com o TestFlight?

Envie uma build para o App Store Connect e depois adicione-a a um grupo de testadores. Com Expo, você compila com o EAS Build e envia com o EAS Submit: ela aparece no TestFlight depois do processamento pela Apple, geralmente em 10 a 15 minutos segundo o Expo. Seus testadores instalam pelo app TestFlight, gratuito na App Store. Você precisa de uma conta Apple Developer paga.

Como gerar um link do TestFlight para convidar testadores?

No App Store Connect, abra a aba TestFlight do seu app, selecione seu grupo em External Testing e clique em Create Public Link. Escolha Open to Anyone ou Filter by Criteria e depois defina um limite com Set Limit. Os testadores por link público continuam anônimos: se você quer saber quem testou o quê, prefira convidar por e-mail.

A revisão beta do TestFlight substitui a revisão da App Store?

Não. A revisão beta verifica se a build segue as regras, mas a revisão final também olha sua página, sua classificação etária (Age Rating), suas assinaturas, seus textos legais e a experiência completa. Então uma build aceita no TestFlight ainda pode ser recusada na publicação. Só os testadores externos acionam uma revisão beta, na primeira build de uma versão: os testadores internos não passam por nenhuma.

Quantos testadores dá para convidar no TestFlight?

Você pode convidar até 100 testadores internos e até 10.000 testadores externos. Os internos são membros da sua conta App Store Connect, sem revisão beta, e cada um pode instalar o app em até 30 dispositivos. Os externos são convidados por e-mail ou por link público, depois de uma revisão beta da primeira build. Cada build fica disponível para teste por 90 dias.

Dá para testar uma assinatura no TestFlight sem ser cobrado?

Sim, as compras feitas numa build do TestFlight passam pelo ambiente de teste da Apple: seus testadores não são cobrados. As renovações são aceleradas: cada assinatura renova uma vez por dia, no máximo seis vezes em uma semana, seja qual for a duração real. Confira no mínimo os preços exibidos, o desbloqueio do app e a restauração depois de uma reinstalação. A configuração completa está descrita em assinaturas in-app no iOS.

O que conferir no TestFlight antes de enviar o app para a Apple?

Reinstale o app pelo TestFlight, como o revisor vai fazer, e percorra o onboarding inteiro. Negue cada permissão, teste a compra e a restauração, depois experimente o modo avião, o menor e o maior iPhone que você suporta. Se o app exige login, prepare uma conta de demonstração nas notas de revisão, com seu backend ligado.