TestFlight: o que é, teste beta e trabalho com builds

O que é TestFlight

TestFlight é a forma legítima e única oficial de distribuir aplicações iOS para teste sem publicar na App Store. O serviço foi lançado pela Apple em 2014 após adquirir a empresa de mesmo nome. Antes do TestFlight, os desenvolvedores usavam distribuição Ad Hoc com limite de 100 dispositivos por temporada — o TestFlight removeu essa limitação e simplificou o processo para alguns cliques.

Por que precisa do TestFlight

O iOS tem uma política de segurança rigorosa: uma aplicação só pode ser instalada num dispositivo através da App Store ou usando certificados especiais. TestFlight resolve o problema dos testes beta atuando como proxy entre o desenvolvedor e o tester: a Apple verifica o build quanto aos requisitos básicos, após o que os testers recebem a aplicação através da aplicação TestFlight da App Store, o que não exige confiar em ficheiros não assinados.

TestFlight vs Ad Hoc vs Enterprise

Existem três formas de distribuir aplicações iOS fora da App Store: Ad Hoc (limite de 100 dispositivos, requer o UDID de cada dispositivo), Enterprise (distribuição interna sem limites, requer um certificado Enterprise da Apple por $299/ano) e TestFlight (até 10.000 testers, gratuito, não requer recolha de UDID). O TestFlight é a escolha ideal para testes beta, Ad Hoc é adequado para testes específicos de dispositivos e Enterprise para aplicações corporativas.

Como funciona o TestFlight

O processo de publicação de um build através do TestFlight consiste em cinco etapas: compilação no Xcode, carregamento no App Store Connect através do Archive Organizer, processamento da Apple, convite aos testers e instalação da aplicação através da aplicação TestFlight. Cada etapa leva de alguns minutos a uma hora, dependendo da complexidade do projeto.

Requisitos da Apple para o build

O build deve ser criado com um certificado de distribuição e um perfil de aprovisionamento válido. A Apple verifica: validade do certificado, correspondência do bundle identifier, ausência de APIs privadas, ícones corretos (1024×1024) e presença do ícone da App Store. Se o build não passar na verificação, o TestFlight mostra um erro com a descrição do problema.

Processamento do build

Após o carregamento, o build passa pela verificação automatizada da Apple: análise estática do código binário, verificação da assinatura digital, verificação de uso de APIs privadas e malware. O processamento leva de 15 minutos a 2 horas para o primeiro build e geralmente 150 minutos para os seguintes. O estado do processamento é exibido em Activity no App Store Connect.

// Configuração do TestFlight no Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Verificar: se a aplicação está instalada através do TestFlight
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Versão beta via TestFlight")
        }
        return true
    }
}

Testers internos e externos

TestFlight divide os testers em dois grupos: Testers Internos (Internal Testers) e Testers Externos (External Testers). A diferença está no número de participantes, acesso aos builds e necessidade de revisão da Apple. Escolher o grupo certo acelera o processo de teste e cumpre as políticas da App Store.

Testers internos (Internal)

Até 100 participantes da equipa do Apple Developer Program. Para convidar um tester interno, basta adicionar o seu Apple ID no App Store Connect — ele obtém acesso imediato a todos os builds. Não é necessária revisão da Apple. Ideal para testes smoke diários e verificação precoce de funcionalidades.

Testers externos (External)

Até 10.000 participantes que não fazem parte da equipa de desenvolvimento. O primeiro build para testers externos passa por uma revisão básica da Apple (geralmente 12 dias). Builds subsequentes com alterações que não afetam a funcionalidade principal podem passar sem revisão repetida. Os testers externos são convidados através de email ou link público.

Como carregar um build no TestFlight

O carregamento de um build no TestFlight é feito através do Xcode, Application Loader ou linha de comandos com xcrun. O método mais comum é através do Xcode Archive Organizer após criar um arquivo do projeto. Um método alternativo é a automatização através do Fastlane para CI/CD Pipeline.

Carregamento manual via Xcode

Crie um arquivo (Product → Archive), abra o Organizer, selecione o arquivo e clique em Distribute App. Selecione TestFlight como método de distribuição, especifique o certificado e o perfil de aprovisionamento. O Xcode carregará o build no App Store Connect, onde aparecerá após o processamento. Todo o processo leva de 10 a 20 minutos para o primeiro carregamento.

Automatização via Fastlane

Fastlane é a ferramenta mais popular para automatizar o carregamento de builds no TestFlight. O comando fastlane pilot carrega o build e gerencia os testers sem abrir o Xcode. A integração do Fastlane com um servidor CI/CD permite publicar builds no TestFlight automaticamente após passar todos os testes.

# Fastfile — carregamento de build no TestFlight
default_platform(:ios)

lane :beta do
    # Obtenção de certificados via match
    match(type: "appstore")

    # Compilação e assinatura
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # Carregamento no TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot carrega automaticamente o IPA no App Store Connect, aguarda o processamento (se skip_waiting_for_build = false) e atribui o build aos grupos de testers selecionados. O comando distribute_external: true envia imediatamente o build para testers externos após o processamento.

Carregamento via linha de comandos

Sem Fastlane, pode usar xcrun: xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool é suportado pela Apple para ambientes CI e não requer interface gráfica. A palavra-passe é passada através do keychain ou de uma palavra-passe específica da aplicação — não utilize palavras-passe em texto simples.

Recolha de feedback e diagnóstico no TestFlight

TestFlight fornece vários mecanismos de feedback: um formulário de feedback integrado, recolha automática de registos de falhas, métricas de uso e capturas de ecrã. A equipa obtém todos os dados no App Store Connect sem necessidade de integrar SDKs de terceiros para testes beta.

Formulário de feedback integrado

O tester abre a aplicação TestFlight, seleciona o seu build e clica em Send Feedback. O formulário permite enviar um feedback de texto, anexar uma captura de ecrã e indicar a gravidade. Todos os feedbacks são recolhidos no App Store Connect em TestFlight → Feedback. O desenvolvedor pode responder ao feedback e o tester receberá uma notificação na aplicação TestFlight.

Registos de falhas e diagnóstico

Quando uma aplicação falha, o TestFlight recolhe automaticamente um relatório de falha: pilha de chamadas, versão do SO, modelo do dispositivo e hora da falha. Os registos de falhas estão disponíveis no Xcode Organizer (Crashes) e no App Store Connect (TestFlight → Crashes). Para obter registos de falhas simbolizados, é necessário carregar os ficheiros dSYM com o build ou separadamente através do Xcode.

Monitorização de uso

O TestFlight mostra métricas: número de instalações, testers ativos, sessões e falhas. As análises são atualizadas diariamente e ajudam a avaliar o envolvimento dos testers. Se nenhum tester abriu a aplicação numa semana — vale a pena reconsiderar a comunicação com o grupo ou a qualidade do build.

Do TestFlight à publicação na App Store

TestFlight é uma parte integrante do processo de publicação na App Store. O mesmo build que passou pelos testes beta através do TestFlight pode ser enviado para revisão da Apple sem recompilação — basta clicar num botão no App Store Connect. Isto elimina o risco de o build de produção diferir do testado.

Submeter para revisão da App

No App Store Connect, selecione o build que passou nos testes e clique em Submit for Review. A Apple usa o mesmo build do TestFlight — não é necessário recarregar. O tempo de revisão é geralmente de 1 a 3 dias. Se o build for rejeitado — corrija os problemas, carregue um novo build no TestFlight e repita o processo.

Build final antes do lançamento

É recomendável esperar 2448 horas após a ronda final de testes no TestFlight antes de enviar para revisão. Este tempo permite que os testers encontrem erros críticos que possam passar nos testes automatizados. O build release candidate (RC) no TestFlight é uma prática padrão para equipas iOS maduras.

O que fazer após a publicação

Os builds do TestFlight tornam-se automaticamente indisponíveis para novas instalações após o lançamento da versão de produção na App Store. Os testers que já instalaram a versão beta podem continuar a usá-la durante 30 dias após a publicação do lançamento, após o que a aplicação deixa de abrir. Certifique-se de que os testers atualizam para a versão da App Store.