# Como publicar app na App Store e Google Play: guia para empresas

> Passo a passo para publicar app na App Store e no Google Play: contas no nome da empresa, revisão, motivos de rejeição, apps internos e atualizações.

Fonte: https://pervian.tech/blog/publicar-app-na-app-store-e-google-play · Pervian Tech · publicado em 2026-10-01

O app está pronto, testado e aprovado pela diretoria. A data de lançamento foi comunicada aos clientes. Aí chega a notícia: a Apple recusou a versão, o Google pediu um formulário sobre coleta de dados que ninguém sabia preencher e, pior, a conta de desenvolvedor está no CPF do freelancer que começou o projeto dois anos atrás.

Publicar um aplicativo é uma etapa com regras próprias, prazos que a empresa não controla e decisões que, tomadas errado no começo, viram dor de cabeça por anos. Este texto explica, do ponto de vista da empresa dona do app, o que é preciso para publicar na App Store e no Google Play, por que as lojas rejeitam versões e como distribuir e manter o app.

## Resposta curta: o caminho para publicar

Em linhas gerais, publicar um app nas duas lojas segue esta sequência:

1. **Criar as contas de desenvolvedor no nome da empresa**: Apple Developer Program (com anuidade) e Google Play Console (com taxa de registro única). Para conta de organização, as duas exigem dados da empresa e um número D-U-N-S, um identificador internacional de empresas que pode ser solicitado gratuitamente.
2. **Preparar a ficha da loja**: nome, descrição, ícone, capturas de tela, categoria, classificação etária, contato de suporte e endereço da política de privacidade.
3. **Declarar a coleta de dados**: a Apple pede os detalhes de privacidade do app; o Google pede a seção de segurança dos dados. Ambos querem saber o que o app coleta, para quê e se compartilha.
4. **Gerar a versão assinada** com os certificados e chaves da conta e enviar para a loja.
5. **Testar com usuários reais pelos canais oficiais**: TestFlight na Apple e as faixas de teste interno, fechado e aberto no Google Play.
6. **Enviar para revisão**, com instruções e uma conta de demonstração para o revisor entrar no app.
7. **Publicar**, de preferência de forma gradual, e acompanhar falhas e avaliações nos primeiros dias.

## Contas de desenvolvedor no nome da empresa

Esta é a decisão mais importante e a mais negligenciada. **O app pertence a quem é dono da conta na loja**, não a quem pagou pelo desenvolvimento. Se a conta está no nome pessoal de um desenvolvedor, de um sócio que saiu ou da agência que fez o projeto, a empresa depende dessa pessoa para publicar qualquer atualização.

Os problemas aparecem nos piores momentos: a anuidade da Apple vence e o app sai da loja; a agência encerra o contrato e não libera o acesso; o nome de uma pessoa física aparece embaixo do app. Transferir o app entre contas é possível, mas tem requisitos e pode levar tempo.

O caminho certo é a empresa criar as próprias contas, com um e-mail corporativo que não dependa de uma pessoa (algo como apps@suaempresa.com.br), e convidar o fornecedor como membro da equipe, com o nível de acesso necessário. [Se o fornecedor sair](https://pervian.tech/blog/trocar-de-fornecedor-de-software), basta remover o acesso.

O mesmo vale para os ativos técnicos que ficam fora da loja: [chaves de assinatura, certificados](https://pervian.tech/blog/senhas-e-chaves-de-api-no-codigo), conta do serviço de notificações, repositório de código. Tudo isso deveria estar sob controle da empresa e previsto em contrato. Explicamos esse ponto em detalhe em [propriedade do código-fonte no contrato](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato).

Para criar as contas, separe CNPJ, razão social e endereço como no cadastro oficial, o D-U-N-S, um responsável legal que possa aceitar os termos e o site da empresa no ar. A emissão do D-U-N-S e a verificação da conta podem levar de alguns dias a algumas semanas, conforme a fila de cada órgão e loja. Por isso, essa etapa deve começar junto com o desenvolvimento, não no fim.

## O que as lojas exigem antes de aprovar

A Apple faz uma revisão mais detalhada, feita também por pessoas. O Google automatiza boa parte da análise, mas também rejeita e pode suspender apps já publicados. O que ambas esperam:

- **Um app completo.** Nada de telas com "em breve", botões que não fazem nada ou links quebrados.
- **Acesso para o revisor.** Se o app exige login, é preciso fornecer uma conta de demonstração com dados de exemplo. Se depende de um equipamento (uma balança, um leitor) ou de um cadastro aprovado pela empresa, explique isso nas notas de revisão, de preferência com um vídeo curto.
- **Ficha fiel ao app.** Capturas de tela e descrição precisam mostrar o que o app realmente faz.
- **Justificativa para cada permissão.** No iPhone, cada acesso a câmera, localização, contatos ou fotos precisa de um texto explicando por que o app pede aquilo. No Android, permissões sensíveis, como localização em segundo plano, exigem declaração e às vezes um vídeo demonstrando o uso.
- **Exclusão de conta.** Se o usuário pode criar conta no app, as lojas exigem que ele também consiga pedir a exclusão dessa conta e dos dados associados.

O tempo de revisão varia: muitas vezes é de um a poucos dias, mas pode demorar mais em épocas de pico ou na primeira publicação. Nunca marque uma data de lançamento contando com aprovação no mesmo dia.

Um detalhe do Google Play: contas pessoais novas precisam rodar um teste fechado com um mínimo de testadores e de dias antes de publicar para o público. Contas de organização, hoje, não têm essa exigência. Confirme as regras vigentes ao abrir a conta.

## Motivos comuns de rejeição

A maior parte das rejeições se repete. Conhecendo a lista, dá para evitar quase todas.

| Motivo | Como costuma aparecer | Como evitar |
|---|---|---|
| App incompleto ou com falhas | Tela travando, erro de login, conteúdo de teste visível | Testar a versão final em aparelhos reais antes de enviar |
| Revisor sem acesso | Conta de demonstração expirada ou sem dados | Criar uma conta exclusiva para revisão, com dados de exemplo, e testá-la antes |
| App que é só um site embrulhado | Abre o site da empresa dentro de uma moldura, sem recurso próprio | Ter funcionalidades que justifiquem o app; senão, avaliar um PWA |
| Permissão sem justificativa clara | Pede localização ou contatos sem explicar | Pedir só o necessário, no momento em que for usado, com texto claro |
| Privacidade inconsistente | Declaração de dados diferente do que o app coleta | Mapear as bibliotecas de terceiros (SDKs) e o que coletam antes de preencher os formulários |
| Pagamento fora da loja para conteúdo digital | Venda de assinatura ou conteúdo digital por link próprio | Entender as regras de compra no app antes de desenhar o modelo de cobrança |
| Login social sem alternativa exigida | Login só com redes sociais no iPhone | Verificar as regras atuais da Apple para opções de login |

Sobre pagamentos: venda de **produto físico ou serviço prestado fora do app** (um pedido, uma visita técnica) normalmente pode usar o meio de pagamento da empresa. Já **conteúdo digital consumido no app**, como uma assinatura que libera funcionalidades, em geral precisa usar o sistema de compra da loja, com as regras e a comissão dela. Essas regras mudam com frequência, inclusive por decisões de órgãos reguladores em vários países, e o Brasil está entre eles. Valide o modelo de cobrança, com as regras vigentes de cada loja, antes de construí-lo.

Se o app é só uma vitrine do site, vale reconsiderar o formato. Comparamos as opções em [app nativo, híbrido ou PWA](https://pervian.tech/blog/app-nativo-hibrido-ou-pwa).

## Política de privacidade e coleta de dados

As duas lojas exigem uma política de privacidade publicada em endereço acessível, e a LGPD exige que a empresa informe ao titular quais dados trata, com que finalidade e com quem compartilha. Os dois assuntos andam juntos.

O ponto que pega as empresas desprevenidas: **o formulário da loja inclui o que as bibliotecas de terceiros coletam**, não só o que o seu código coleta. Ferramentas de análise de uso, monitoramento de falhas, publicidade e login social enviam dados por conta própria. Se a declaração diz que o app não coleta identificadores e uma biblioteca de análise coleta, há inconsistência.

O roteiro prático é montar uma lista única com os dados que o app coleta diretamente, as bibliotecas embutidas e o que cada uma coleta, a finalidade e o compartilhamento. Dessa lista saem a política de privacidade, revisada pelo jurídico, e os formulários das lojas. Toda biblioteca nova reabre a lista.

## Apps só para funcionários: distribuição privada

Muitos apps de empresa não são para o público: força de vendas, ordem de serviço, [conferência de estoque](https://pervian.tech/blog/app-de-inventario-com-codigo-de-barras), diário de obra. Publicar um app desses aberto na loja expõe a tela de login a qualquer pessoa e obriga a passar por regras pensadas para o consumidor final. Existem caminhos melhores.

| Caminho | Plataforma | Quando faz sentido |
|---|---|---|
| Teste interno e fechado | Google Play | Grupos pequenos, piloto, validação antes do lançamento |
| TestFlight | Apple | Testes e pilotos; cada versão expira em 90 dias e precisa ser substituída por uma nova |
| Google Play gerenciado (apps privados) | Android | Distribuir para os aparelhos da empresa sem aparecer na loja pública |
| Apps personalizados via Apple Business Manager | Apple | Distribuir para a empresa ou para clientes específicos, sem listagem pública |
| Gestão de dispositivos (MDM) | Ambas | Frota de aparelhos corporativos com instalação e atualização centralizadas |
| Instalação direta do arquivo (Android) | Android | Exceções; dificulta atualização e controle, e as regras de instalação fora da loja estão ficando mais restritas |

Com aparelhos corporativos, distribuição privada pela loja somada a uma ferramenta de gestão de dispositivos é o arranjo mais organizado: o app chega instalado, a atualização não depende do funcionário e, quando ele sai, o acesso é retirado. Apps privados também passam por revisão, em geral mais simples. Se os aparelhos são dos funcionários, envolva RH e jurídico na política de uso.

## Atualizações, versões e usuários desatualizados

Publicar a primeira versão é o começo. Toda correção, ajuste ou funcionalidade nova passa de novo pela revisão. E, diferentemente de um sistema web, em que todo mundo usa a versão mais recente assim que ela sobe, **no app cada usuário pode estar numa versão diferente**.

O vendedor que nunca atualiza o celular continua enviando pedidos no formato antigo; o servidor muda uma regra e a versão de seis meses atrás para de funcionar. Algumas práticas evitam o problema:

- **Versão mínima obrigatória.** O app consulta o servidor ao abrir e, se estiver abaixo da versão mínima aceita, pede a atualização antes de continuar.
- **Servidor compatível com versões anteriores.** Mudanças na comunicação entre app e servidor devem conviver com a versão anterior por um tempo.
- **[Publicação gradual](https://pervian.tech/blog/ci-cd-para-gestores).** As duas lojas permitem liberar a versão para uma parte dos usuários primeiro. Se aparecer um problema, ele atinge poucos e a liberação pode ser interrompida.
- **Monitoramento de falhas.** Uma ferramenta que reporta travamentos por versão mostra rapidamente se a atualização nova trouxe problema.
- **Correção urgente com plano.** Se um bug grave escapar, a correção ainda precisa passar pela revisão. Ter regras que podem ser ajustadas pelo servidor, sem nova versão, reduz esse risco.

Há também as atualizações que a empresa não pediu. Todos os anos a Apple e o Google lançam versões novas dos sistemas e passam a exigir que os apps sejam compilados com ferramentas e níveis de compatibilidade recentes. No Google Play, apps que não acompanham o nível exigido deixam de aparecer para quem usa versões mais novas do Android, e novas versões só são aceitas depois que o app é atualizado para o nível exigido. Na Apple, o envio de versões passa a exigir ferramentas recentes de desenvolvimento. Na prática, um app sem nenhuma manutenção por um ou dois anos perde alcance e, quando surge uma correção urgente, ela vem acompanhada de uma atualização técnica que ninguém tinha planejado.

## Quem cuida do app depois de publicado

Um app publicado tem rotina: renovar anuidade e certificados, responder avaliações, cumprir prazos de mudança de política, atualizar bibliotecas e revisar a declaração de privacidade. Do lado da empresa, alguém precisa receber os e-mails das lojas, aceitar novos termos e autorizar acessos. Do lado técnico, alguém precisa executar. Esse trabalho cabe dentro de um contrato de [manutenção evolutiva de software](https://pervian.tech/blog/manutencao-evolutiva-de-software), que trata correções, ajustes de plataforma e melhorias como rotina, e não como emergência.

### Checklist antes de enviar a primeira versão

- [ ] Contas da Apple e do Google em nome da empresa, verificadas.
- [ ] Chaves de assinatura e certificados guardados em local controlado pela empresa.
- [ ] Política de privacidade publicada e revisada pelo jurídico.
- [ ] Formulários de privacidade preenchidos a partir do mapa de dados.
- [ ] Textos de justificativa para todas as permissões.
- [ ] Exclusão de conta disponível, se o app tiver cadastro.
- [ ] Conta de demonstração testada, com instruções para o revisor.
- [ ] Teste em aparelhos reais, Android e iPhone, incluindo modelos mais antigos.
- [ ] Verificação de versão mínima e monitoramento de falhas ativos.
- [ ] Data de lançamento com folga para pelo menos uma rodada de rejeição.

## Perguntas frequentes

### Quanto tempo a Apple leva para aprovar um app?

Depende do caso. Muitas vezes a revisão da App Store leva de um a poucos dias, mas pode demorar mais em épocas de pico ou na primeira publicação, e cada rejeição reinicia o ciclo. Por segurança, a data de lançamento do app deve ter folga para pelo menos uma rodada de rejeição e correção.

### Precisa de CNPJ para publicar app na App Store e no Google Play?

Para publicar como organização, sim. As contas de organização da Apple e do Google pedem os dados da empresa, um número D-U-N-S e um responsável legal que aceite os termos. Contas pessoais existem, mas deixam o app vinculado a uma pessoa física, o que cria dependência quando essa pessoa sai ou o fornecedor muda.

### Dá para publicar um app só para os funcionários, sem aparecer na loja?

Dá. O Google Play gerenciado permite distribuir apps privados para os aparelhos da empresa, e a Apple oferece apps personalizados pelo Apple Business Manager, sem listagem pública. Combinados com uma ferramenta de gestão de dispositivos, esses caminhos instalam e atualizam o app de forma centralizada. Apps privados também passam por revisão, em geral mais simples.

### Como transferir um app que está na conta de outra pessoa?

As duas lojas permitem transferir um app entre contas de desenvolvedor, mas o processo tem requisitos, pode levar tempo e depende da colaboração do dono atual da conta. Por isso o ideal é a empresa criar as próprias contas na App Store e no Google Play desde o início e convidar o fornecedor como membro da equipe.

### Um app publicado precisa de manutenção mesmo sem funcionalidades novas?

Precisa. Todos os anos a Apple e o Google lançam versões novas dos sistemas e passam a exigir que os apps sejam compilados com ferramentas recentes. Um app sem manutenção perde alcance no Google Play e fica difícil de atualizar quando surge uma correção urgente. Renovar certificados e revisar a declaração de privacidade também fazem parte da rotina.

## Como a Pervian Tech trabalha publicação de apps

Na Pervian Tech, a publicação entra no planejamento desde o início. No diagnóstico, levantamos se o app será público ou interno, quais dados coleta, quais permissões usa e como será cobrado, porque isso muda o desenho do app e o caminho de distribuição. Orientamos a empresa a abrir as próprias contas nas lojas e trabalhamos como membros convidados, de modo que o app, as chaves e o código fiquem sempre no nome de quem é dono do negócio.

Depois do lançamento, cuidamos das atualizações de plataforma, das mudanças de política e da evolução do app dentro de um acompanhamento contínuo. Veja como funciona nosso [desenvolvimento de aplicativos para empresas](https://pervian.tech/solucoes/desenvolvimento-de-aplicativos-para-empresas) e o serviço de [desenvolvimento mobile](https://pervian.tech/servicos/desenvolvimento-mobile), ou leia outros textos em [aplicativos](https://pervian.tech/blog/categoria/aplicativos).

O diagnóstico inicial é gratuito, o projeto é sob medida e o investimento é sob consulta, porque depende do escopo e do tipo de distribuição. Se a sua empresa vai lançar um app ou tem um app preso na conta de outra pessoa, [conte o que está acontecendo](https://pervian.tech/#contato).