O TestFlight é a ferramenta de teste da Apple: cada build vale 90 dias e depois fica indisponível para quem instalou, então não serve para a equipe usar o app no dia a dia. O caminho certo depende de quem usa. App para o público vai para a loja; app da própria equipe vai para a loja com login fornecido pela empresa, ou sai como app privado ou não listado; app para uma empresa cliente sai como app privado para a organização dela, na Apple e no Google. O Enterprise Program da Apple não é atalho: exige 100 ou mais funcionários e serve só para uso interno.
Dá para distribuir o app da empresa pelo TestFlight?#
Não. O TestFlight é a ferramenta de teste da Apple, e cada build (a versão do app enviada para teste) vale por 90 dias. Depois disso, segundo a própria Apple, o build fica indisponível para os testadores, e quem usava o app por ali fica sem ele até alguém enviar uma versão nova. Para uso diário, o app da empresa precisa sair por um canal de distribuição.
A pergunta costuma aparecer no mesmo momento do projeto. O app está pronto, a equipe já testou pelo TestFlight, e alguém sugere deixar assim mesmo, sem passar pela loja. A ideia parece prática porque funciona no primeiro dia.
A própria Apple diz para que o TestFlight existe. Nas diretrizes de revisão da App Store, a seção 2.2 manda colocar versões de teste no TestFlight e não na loja, e diz que todo app enviado ao TestFlight deve ser destinado à distribuição pública. Ou seja, a Apple trata o TestFlight como a etapa anterior à loja.
O que acontece quando a equipe usa o app pelo TestFlight#
A equipe passa a depender de um prazo de 90 dias, de um limite de pessoas e de uma conta que não foi feita para isso. O testador interno precisa ser usuário da conta de desenvolvedor, e o externo depende de uma revisão da Apple. Em qualquer dos dois, alguém precisa enviar um build novo antes do prazo, a cada trimestre.
| Testador interno | Testador externo | |
|---|---|---|
| Quem pode ser | usuário do App Store Connect, com papel na conta (Admin, Developer, Marketing e outros) | qualquer pessoa convidada por e-mail ou por link público |
| Limite | 100 pessoas | 10.000 pessoas |
| Revisão da Apple | não passa | o primeiro build passa pela revisão |
| Validade de cada build | 90 dias | 90 dias |
Os números são da documentação do TestFlight no App Store Connect. A primeira linha é a que mais pesa para uma empresa: para colocar a equipe de vendas como testador interno, cada vendedor ganha um papel dentro da conta que publica o app. E as contas que a própria empresa administra pelo Apple Business, criadas em domínio reservado, não podem testar builds, também segundo a Apple.
O prazo é o ponto que nenhuma configuração resolve. Se ninguém enviar o build novo a tempo, a equipe inteira fica sem o app no mesmo dia. No nosso padrão de publicação, é por esse motivo que o TestFlight está descartado como canal de produção.
Para que o TestFlight serve no projeto#
O TestFlight serve para quem vai usar o app ver a versão antes da loja. Nos nossos projetos, ele entra em dois momentos: quando o cliente valida o app enquanto a loja analisa a primeira versão, e quando a revisão atrasa e alguém precisa continuar testando. O equivalente no Android é o teste interno do Google Play.
Na GT, o app foi enviado à Apple e ao Google em 18 de agosto. No dia seguinte, os responsáveis da GT receberam acesso pelo TestFlight e testaram o app enquanto as lojas faziam a revisão, e os testes terminaram na mesma semana. Nos planos semanais dos projetos com app, o plano B se repete: se a revisão da loja atrasar, o cliente acompanha pelo TestFlight ou pelo teste interno do Google.
O teste interno do Google Play cumpre esse papel bem. Ele aceita até 100 testadores, e cada versão fica disponível em minutos. O próprio Google avisa que esses testes podem não passar pelas revisões normais de política e segurança. Isso agiliza o teste, e é também o motivo para não usar o teste interno como canal da equipe: são 100 pessoas no máximo, cadastradas numa lista de e-mails.
O caminho certo para cada caso#
O caminho depende de quem vai usar o app. App para o público vai para a loja. App da própria equipe vai para a loja com login fornecido pela empresa, ou sai como app privado ou não listado. App feito para uma empresa cliente sai como app privado para a organização dela, nas duas lojas.
| O caso | O caminho na Apple | O caminho no Google | Se usar TestFlight |
|---|---|---|---|
| App para o público (clientes, pacientes, alunos) | App Store | Google Play | o app não aparece na loja, e cada build vale 90 dias |
| App da própria equipe, sem gestão de aparelhos | App Store com login fornecido pela empresa, ou app não listado | Google Play com login fornecido pela empresa | cada funcionário vira usuário da conta ou testador externo, e o app sai do ar se o build vencer |
| App da própria equipe, com gestão de aparelhos | app privado no Apple Business da empresa | app privado no Google Play gerenciado | os mesmos problemas, com o caminho privado já à mão |
| App para uma empresa cliente (B2B) | app privado para a organização do cliente no Apple Business | app privado para a organização do cliente | o cliente depende de você enviar um build a cada 90 dias |
App para o público#
O app para o público vai para a App Store e para o Google Play, com a revisão de cada versão. No Google, uma conta pessoal criada depois de 13 de novembro de 2023 precisa antes de um teste fechado com pelo menos 12 testadores por 14 dias seguidos. A exigência vale para conta pessoal. Para app de empresa, a conta deve ser da empresa, porque é a conta que define quem é dono do app, como explicamos em de quem deve ser a conta da App Store.
App para a própria equipe#
Na maioria dos nossos projetos, o app da equipe vai para a loja pública com acesso fechado. Na Beckers, o app Android dos técnicos está publicado na Google Play como aplicativo corporativo, sem cadastro público, e só entra quem recebe e-mail e senha da empresa. Para um app com login, a Apple pede na revisão uma conta de demonstração com o servidor ligado (diretriz 2.1).
Quando a empresa não quer o app na busca da loja, a Apple oferece a distribuição não listada. O app fica na App Store, instala e atualiza como qualquer outro, e só chega a ele quem tem o link. A Apple cita como exemplo ferramentas de venda para parceiros e recursos para funcionários, e recusa o pedido se o app estiver em fase de teste.
Quando a empresa administra os aparelhos da equipe, o app pode ser privado. Na Apple, ele aparece só no Apple Business da empresa, que é o antigo Apple Business Manager, unificado pela Apple com outros serviços numa plataforma gratuita em abril de 2026. A documentação diz que esse caminho inclui apps próprios para uso interno. No Google, o app privado chega pelo Google Play gerenciado, por meio do sistema de gestão de aparelhos que a empresa já usa.
App para uma empresa cliente#
Quando o app é feito para os funcionários de outra empresa, o caminho é o app privado para a organização dela. Na Apple, o app é atribuído ao identificador da organização do cliente no Apple Business. No Google, o mesmo app privado pode ir para até 1.000 organizações, e o Google prevê que a software house publique direto para o cliente com o identificador da organização que ele fornece.
Essa decisão se toma antes da primeira publicação. Na Apple, a forma de distribuição não muda depois que o app é aprovado, e passar de privado para público exige um registro novo. No Google, o app privado só fica público como um app novo, com outro nome de pacote.
Por que o Enterprise Program não é atalho#
O Apple Developer Enterprise Program serve para uma empresa grande distribuir apps de uso interno aos seus funcionários, fora da loja. Ele exige 100 ou mais funcionários, entrevista de verificação e avaliação contínua, e custa US$ 299 por ano. Não serve para distribuir app a clientes, e o certificado pode ser revogado, o que tira do ar todos os apps assinados com ele.
A página do programa diz que ele é só para os casos que a App Store, os apps privados, o Ad Hoc e o TestFlight não atendem. O contrato do programa, na versão de 8 de junho de 2026, é direto: para distribuir a terceiros, a empresa precisa usar a App Store ou a distribuição de app privado. Na mesma versão, a Apple se reserva o direito de revogar os certificados a qualquer momento, inclusive quando a empresa descumpre o contrato.
A consequência da revogação está na documentação de certificados da Apple: os usuários deixam de conseguir abrir os apps assinados com aquele certificado. Quando um fornecedor usa uma conta Enterprise para entregar apps a vários clientes, uma revogação causada por um cliente derruba os apps de todos os outros.
E o Ad Hoc?#
O Ad Hoc instala o app direto em aparelhos cadastrados, fora da loja. Cada conta pode cadastrar até 100 iPhones por ano, um por um, e o contador só é renovado no início de cada ano de assinatura. Serve para um teste com poucos aparelhos, e não para uma equipe que contrata gente nova todo mês.
E mandar o APK direto no Android?#
O Android ainda instala um app enviado como arquivo, mas o Google começou a fechar esse caminho. Desde 30 de setembro de 2026, no Brasil, os apps instalados pelas lojas participantes, entre elas a Google Play e a Galaxy Store, precisam estar registrados por um desenvolvedor verificado. O Google anunciou que leva a verificação a todos os apps em aparelhos Android certificados a partir de 2027.
O que decidir antes de desenvolver o app#
Antes do desenvolvimento, quatro respostas definem a distribuição, e todas cabem numa reunião de escopo:
- Quem usa o app: o público, a equipe da empresa ou os funcionários de um cliente.
- A empresa administra os aparelhos? Se não administra, o app privado do Google fica fora de alcance, e o caminho é a loja com login.
- Em qual conta o app vai ser publicado, e se é conta de empresa ou pessoal, por causa do teste de 14 dias do Google.
- O app vai cobrar alguma coisa dentro dele? Se vai, entram as regras de pagamento das lojas, explicadas em quando o app paga comissão à Apple e ao Google.
Se ainda não está claro se o sistema precisa mesmo de aplicativo, a pergunta anterior está em aplicativo ou sistema web.
Perguntas frequentes#
O app instalado pelo TestFlight para de funcionar depois de 90 dias?#
O build para de funcionar, sim. Segundo a Apple, um build pode ser testado por até 90 dias e depois fica indisponível para os testadores. Quem usa o app por ali só continua se um build novo for enviado antes do prazo e cada pessoa instalar a versão nova. Quando o app é publicado na loja, ele não tem esse prazo.
Posso usar o teste interno do Google Play para distribuir o app à equipe?#
Funciona por um tempo, mas não é o canal certo. O teste interno aceita até 100 testadores, cadastrados numa lista de e-mails, e o Google avisa que esses testes podem não passar pelas revisões normais de política e segurança. Para uma equipe que usa o app todo dia, o caminho é a publicação na loja com login fornecido pela empresa, ou um app privado pelo Google Play gerenciado.
Preciso de um sistema de gestão de aparelhos (MDM) para ter um app privado?#
No Google, sim: o app privado chega pelo Google Play gerenciado, por meio de um sistema de gestão de aparelhos, que pode ser o próprio Google pelo Admin console. Na Apple, o app privado aparece no Apple Business da empresa e é distribuído por gestão de aparelhos ou por códigos de resgate. Desde abril de 2026, o Apple Business é gratuito e já traz gestão de aparelhos.
App interno também passa pela revisão da Apple?#
Passa. O app publicado na loja, o app não listado e o app privado para uma organização são todos revisados pela Apple antes de chegar a alguém. Se o app tem login, a Apple pede uma conta de demonstração com o servidor ligado. O teste externo do TestFlight também passa por revisão no primeiro build. No TestFlight, só o teste interno, limitado a 100 usuários da conta, fica de fora.
Dá para tornar público depois um app que nasceu privado?#
Não diretamente. Na Apple, depois que o app é aprovado, a forma de distribuição não muda: para passar de privado a público, ou o contrário, é preciso criar um registro novo de app e reenviar. A única exceção é mudar um app público para não listado. No Google Play, o app privado continua privado, e torná-lo público exige publicar um app novo, com outro nome de pacote.
Fontes#
- Apple, TestFlight overview (App Store Connect Help): https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview
- Apple, TestFlight: https://developer.apple.com/testflight/
- Apple, App Store Review Guidelines, revisão de 8 de junho de 2026 (diretrizes 2.1 e 2.2): https://developer.apple.com/app-store/review/guidelines/
- Apple, Set distribution methods (App Store Connect Help): https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/set-distribution-methods
- Apple, Custom apps: https://developer.apple.com/custom-apps/
- Apple, Unlisted app distribution: https://developer.apple.com/support/unlisted-app-distribution/
- Apple Newsroom, "Introducing Apple Business", 24 de março de 2026: https://www.apple.com/newsroom/2026/03/introducing-apple-business-a-new-all-in-one-platform-for-businesses-of-all-sizes/
- Apple Developer Enterprise Program: https://developer.apple.com/programs/enterprise/
- Apple Developer Enterprise Program License Agreement, versão de 8 de junho de 2026 (seção 5.3): https://developer.apple.com/support/downloads/terms/apple-developer-enterprise-program/Apple-Developer-Enterprise-Program-License-Agreement-English.pdf
- Apple, Certificates overview: https://developer.apple.com/support/certificates/
- Apple, Devices overview: https://developer.apple.com/help/account/devices/devices-overview/
- Google Play, configurar teste aberto, fechado ou interno: https://support.google.com/googleplay/android-developer/answer/9845334
- Google Play, requisitos de teste para contas pessoais novas: https://support.google.com/googleplay/android-developer/answer/14151465
- Google Play, publicar apps privados: https://support.google.com/googleplay/android-developer/answer/6145139
- Android Developers, verificação de desenvolvedor: https://developer.android.com/developer-verification
- Android Developers Blog, "Android developer verification", junho de 2026: https://android-developers.googleblog.com/2026/06/android-developer-verification.html
Próximo passo#
Se a sua empresa vai ter um app para a equipe ou para clientes, a forma de distribuição entra no escopo desde o começo, junto com a conta e a revisão das lojas. É o tipo de produto que construímos e publicamos em produtos SaaS, como o app de campo da Beckers, que está na Google Play com acesso só para quem a empresa libera.