De quem é a conta da App Store: sua ou de quem desenvolve o app

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.

O que a conta de desenvolvedor realmente guarda#

Vale entender o que está em jogo antes de decidir onde o app mora.

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 não é ideológica: é de cronograma.

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.

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#

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:

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#

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.

Titularidade e operação são camadas separadas. Confundir as duas é o que produz o arranjo ruim.

Os atalhos que não servem#

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 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:

1. 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.
2. 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.
3. 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 é.
4. 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.