Ser dono do app são três coisas decididas em lugares diferentes: o código, no contrato; a ficha na loja, na conta de desenvolvedor; e a capacidade de publicar a próxima versão, nos certificados de assinatura — e quem controla a conta controla o produto. O que importa não é em qual conta o app nasce, e sim em qual conta ele termina, se a sua já começou a ser aberta no primeiro dia e se a migração é um passo previsto no contrato. Já fizemos esse caminho até o fim: a migração preserva avaliações e base instalada, e quebra coisas específicas que precisam estar mapeadas antes.
A pergunta que quase ninguém faz antes de assinar#
Quando uma empresa contrata o desenvolvimento de um aplicativo, a negociação gira em torno de escopo, prazo e preço. Quase nunca alguém pergunta em qual conta de desenvolvedor o app vai ser publicado — e essa é a pergunta que decide quem tem o produto no fim.
A conta de desenvolvedor não é um detalhe operacional. Ela é o registro público de quem é dono daquele app, e é onde ficam guardadas as coisas que você não consegue recriar depois: a ficha na loja, as avaliações acumuladas, o histórico de versões, os certificados de assinatura do aplicativo e os dados fiscais que recebem o dinheiro, quando há.
A resposta curta é: a conta tem que terminar no nome da sua empresa. A resposta útil é mais interessante, porque o caminho até lá quase nunca é direto.
"De quem é o app?" são três perguntas, não uma#
Ser dono do aplicativo que um fornecedor desenvolveu para você junta três coisas diferentes, decididas em lugares diferentes — e dá para acertar a primeira e perder as outras duas sem perceber.
| Camada | O que é | Onde se decide |
|---|---|---|
| O código | o que foi construído, e o direito de usar, alterar e levar a outro fornecedor | no contrato, na cláusula de cessão |
| A ficha na loja | o endereço público do produto, as avaliações e o histórico de versões | na conta de desenvolvedor em que o app foi publicado |
| A capacidade de publicar | poder subir a próxima versão sem depender de terceiro | nos certificados de assinatura e nos papéis de acesso da conta |
O contrato costuma cobrir a primeira linha e não mencionar as outras duas. Daí sai a situação desconfortável: dá para ter a cessão de código perfeitamente escrita e ainda assim não ser dono do produto, porque a ficha que o público conhece, as avaliações acumuladas e os certificados que assinam a próxima atualização estão numa conta que não é sua.
São perguntas separadas e vale fazer as duas. O código responde "posso levar isso embora?". A conta responde "o produto que está no ar é meu?". O resto deste artigo é sobre a segunda, que é a que quase ninguém negocia.
O que a conta de desenvolvedor realmente guarda#
A conta de desenvolvedor guarda o que não se recria depois: a ficha na loja, as avaliações acumuladas, o histórico de versões, os certificados de assinatura do aplicativo e os dados fiscais que recebem o dinheiro. Ela é o registro público de quem é dono do app, não um detalhe operacional do projeto. Quando o app vende algo dentro dele, é sobre essa receita que a loja cobra comissão, e o que paga e o que não paga está em quando o app paga comissão à Apple e ao Google.
Vale entender o que está em jogo antes de decidir onde o app mora.
| O que fica na conta | Por que importa |
|---|---|
| A ficha do app na loja | é o endereço público do produto, com URL própria |
| Avaliações e classificações | é reputação acumulada, e não existe forma de transportá-la à mão |
| Histórico de versões | é o registro de que o produto é mantido |
| Certificados de assinatura | sem eles ninguém publica atualização do app |
| Dados fiscais e bancários | é quem recebe, quando o app vende |
| Identificadores e credenciais | Bundle ID, chaves de notificação, segredos de assinatura |
Nenhum desses itens é recriável do zero sem custo. Uma ficha nova significa começar do zero em avaliações — e avaliação é um dos poucos ativos de aplicativo que não se compra nem se acelera.
Os dois caminhos possíveis#
Existem dois arranjos honestos, e a diferença entre eles é de cronograma, não ideológica: esperar a conta da sua empresa ficar pronta antes de publicar, ou publicar pela conta de quem desenvolve e migrar depois. O segundo só é seguro quando a migração está combinada por escrito e a sua conta já começou a ser aberta.
Existem dois arranjos honestos, e a diferença entre eles não é ideológica: é de cronograma.
| Esperar a sua conta ficar pronta | Publicar pela conta de quem desenvolve e migrar | |
|---|---|---|
| Início | o lançamento fica refém do cadastro da empresa | as duas coisas correm em paralelo |
| Durante o projeto | você é titular desde o primeiro dia | quem desenvolve opera sem intermediário |
| No fim | não há nada a fazer | há uma migração, com gatilho e data |
| Risco real | semanas paradas esperando cadastro | ficar sem a migração, se ela não estiver no contrato |
O terceiro arranjo — publicar na conta de quem desenvolve e deixar lá — não está na tabela porque não é um caminho, é uma dependência. É esse que cria a conversa ruim três anos depois — e é a mesma armadilha que decide a plataforma de um site institucional, num produto diferente.
Como fazemos: duas trilhas em paralelo#
Na Epicora o processo é este, e ele existe porque a burocracia e o lançamento têm relógios diferentes.
A conta do cliente começa a ser aberta no primeiro dia. Isso inclui o número D-U-N-S, a conta Apple e a conta Google, todos em nome da empresa dele. Essa trilha é lenta e não depende de código: é cadastro, verificação de identidade e validação de pessoa jurídica, e cada uma dessas etapas tem o próprio tempo de resposta.
A publicação não espera essa trilha terminar. O app é publicado primeiro pela conta da Epicora, que já está verificada e operante — e é assim que a primeira submissão, a revisão da loja e as correções de revisão acontecem sem ficar reféns de um cadastro externo.
Quando o app estabiliza, faz-se a migração para as contas do cliente, que a essa altura já existem e já estão verificadas.
Já rodamos esse ciclo inteiro. O aplicativo da ProHire nasceu publicado pela conta da Epicora e foi transferido para a conta da empresa — hoje, se você abrir a ficha dele na App Store, o desenvolvedor listado é a razão social da ProHire, não a nossa. E o que mais interessa é o que não aconteceu na transferência: ninguém precisou reinstalar nada, as avaliações continuaram lá e o app seguiu recebendo atualização pelo mesmo caminho.
O ponto que interessa a quem está contratando não é o arranjo em si — é o critério que ele revela. Se o fornecedor não começou a abrir a sua conta no primeiro dia, o cronograma dele já está errado, mesmo que o app entre no ar na data combinada. A pergunta a fazer numa reunião de kickoff é literal: a minha conta de desenvolvedor já está sendo aberta?
Como a migração funciona de verdade#
Transferir um aplicativo entre contas é procedimento documentado pelas duas lojas e preserva o que importa. A Apple mantém avaliações, classificações e o mesmo Bundle ID, que não pode ser alterado; o Google Play leva usuários, estatísticas, comentários, avaliações e assinaturas. Quem já instalou não precisa fazer nada e não percebe.
Aqui está o que decide se "migrar depois" é um plano ou uma promessa. As duas lojas documentam o procedimento, e ele é razoavelmente generoso com o que importa.
O que sobrevive. A Apple documenta que o app transferido mantém suas avaliações e classificações, conserva o mesmo Bundle ID — que não pode ser alterado — e que os usuários continuam recebendo atualizações normalmente. O Google Play documenta que usuários, estatísticas, dados, comentários, avaliações e assinaturas acompanham o app. Na prática, quem já instalou não faz nada e não percebe.
O que fica para trás ou precisa ser refeito. É uma lista curta, específica, e é onde mora o trabalho:
| Item | O que a migração exige |
|---|---|
| TestFlight (Apple) | precisa ser desligado antes da transferência |
| Assinaturas com renovação automática | gerar um novo shared secret na conta de destino |
| Sign in with Apple | desagrupar e gerar um identificador de transferência |
| Apple Pay | criar um novo Merchant ID na conta de destino |
| App Groups | apagar na origem e registrar no destino |
| Relatórios de vendas anteriores | permanecem com quem transferiu |
| Grupos de teste (Google) | precisam ser recriados |
O que já vimos na prática. Na transferência do aplicativo da ProHire, o que a documentação promete se confirmou: a base instalada não sentiu, as avaliações ficaram e as atualizações seguiram saindo normalmente. O trabalho real foi o da coluna da direita da tabela acima — a lista de credenciais e identificadores a refazer.
O procedimento. Na Apple, o titular da conta de origem inicia a transferência e o titular da conta de destino aceita — desde que o app cumpra os critérios de transferência publicados pela empresa. No Google Play, é uma solicitação que exige o ID de transação do registro das duas contas e passa por aprovação, com resposta do suporte em até dois dias úteis.
Nada disso é impeditivo. Mas repare no que a lista significa: a migração é planejável e não é gratuita. Um app com assinatura recorrente e login social dá mais trabalho para migrar do que um app institucional simples — e isso é argumento para decidir cedo, não para adiar.
O que quem desenvolve faz sem ser dono de nada#
Quem desenvolve não precisa ser dono da conta para trabalhar. No App Store Connect o fornecedor entra como Admin, e no Google Play Console como Release Manager: com esses papéis ele cria e envia builds, submete para revisão, gerencia a ficha e publica versões — tudo, exceto ser dono. Encerrado o contrato, o acesso é removido e o aplicativo não sente nada.
O contra-argumento mais comum para deixar o app na conta do fornecedor é operacional: "mas aí eles não conseguem trabalhar". Não procede.
As duas lojas têm papéis desenhados exatamente para isso. No App Store Connect, o fornecedor entra como Admin; no Google Play Console, como Release Manager. Com esses papéis ele cria e envia builds, submete para revisão, responde a pedidos da loja, gerencia a ficha e publica versões — tudo, exceto ser dono. Quando o contrato acaba, você remove o acesso e o aplicativo não sente nada. É o oposto do que acontece quando a dependência está dentro do próprio sistema, e trocar de fornecedor vira um projeto de substituição.
Titularidade e operação são camadas separadas. Confundir as duas é o que produz o arranjo ruim.
Os atalhos que não servem#
TestFlight não é canal de produção: build distribuído por lá expira em 90 dias, e quando expira o aplicativo para de abrir para quem o instalou por ali. Distribuir o app de produção da empresa por TestFlight significa combinar um dia, a cada trimestre, em que tudo para.
Dois caminhos aparecem como economia e não são.
TestFlight não é canal de produção. É a ferramenta de teste da Apple, e é ótima nisso. Mas build distribuído por TestFlight expira em 90 dias — quando expira, o app simplesmente para de abrir para quem o instalou por ali. Distribuir o aplicativo de produção da empresa por TestFlight significa combinar um dia, a cada trimestre, em que tudo para. O caminho certo para cada caso, do app público ao app de um cliente B2B, está em por que o TestFlight não serve para distribuir o app da empresa.
O Apple Developer Enterprise Program não é uma forma de pular a loja. Ele exige que a empresa publicadora tenha 100 ou mais funcionários próprios e restringe a distribuição a colaboradores internos dessa mesma empresa. Usá-lo para distribuir app a clientes ou a terceiros é uso indevido — e a consequência documentada é a revogação do certificado, que derruba de uma vez todos os aplicativos assinados com ele. Quando um fornecedor concentra vários clientes num certificado desses, o problema de um vira o problema de todos.
O que colocar no contrato#
Quatro cláusulas resolvem o assunto inteiro, e todas cabem em linguagem de comprador:
- Titularidade final é da contratante. As contas Apple e Google do produto são registradas em nome da sua empresa, e é lá que o app termina.
- A abertura das contas começa no início do projeto. Com responsável nomeado dos dois lados, porque D-U-N-S e verificação de empresa não dependem de código e não aceleram no fim.
- Se houver publicação inicial pela conta do fornecedor, há migração — com gatilho e prazo. "Quando o app estiver estável" é um gatilho aceitável desde que estável esteja definido; "quando der" não é.
- Entrega de acessos e artefatos no encerramento. Certificados, chaves, identificadores e a lista de capacidades especiais que a migração exige — porque a documentação da própria Apple coloca essa transferência de informação como responsabilidade de quem entrega.
O critério, em uma frase#
Não pergunte de quem é a conta hoje. Pergunte em qual conta o app vai terminar, quando a sua começou a ser aberta e o que dispara a migração — e peça as três respostas por escrito.
O resto é detalhe de execução. Isso aqui é propriedade.