O aplicativo ficou pronto numa sexta-feira de maio. O time apresentou, a diretoria aprovou, a data de lançamento foi combinada com o marketing para dali a duas semanas e as peças de divulgação entraram em produção. Parecia o fim do projeto.
Foram necessários cinquenta e um dias até o aplicativo estar disponível para download nas duas lojas. Nesse período: a criação de uma conta de desenvolvedor empresarial travou por falta de um documento, a primeira submissão foi recusada porque uma permissão de localização não estava justificada, e a segunda foi recusada por ausência de uma forma de excluir a conta dentro do app. Nada disso apareceu no cronograma original, porque ninguém sabia que existia.
A tese deste texto é que a publicação nas lojas é uma etapa do projeto com regras próprias, prazos próprios e riscos próprios, e merece o mesmo planejamento que o desenvolvimento. Empresas que tratam essa fase como formalidade final perdem semanas justamente quando o dinheiro do marketing já foi comprometido.
O que é o processo de publicação nas lojas?
É o conjunto de exigências que Apple e Google impõem para que um aplicativo fique disponível ao público, e envolve três frentes distintas: uma conta de desenvolvedor devidamente cadastrada, um conjunto de materiais e políticas obrigatórios, e uma revisão em que o aplicativo é analisado antes de ser liberado.
A palavra revisão é a que costuma surpreender. Diferente de um site, que você publica quando quiser, um aplicativo passa por avaliação de terceiros antes de chegar ao usuário. Essa análise combina verificações automáticas com avaliação humana, e ela pode recusar o seu app por motivos que não têm nada a ver com defeito de funcionamento.
As duas lojas têm filosofias diferentes e isso afeta o planejamento. A da Apple é mais rigorosa na revisão inicial e costuma ser onde as recusas acontecem. A do Google é mais permissiva na entrada, mas aplica verificações de política de forma automatizada e pode suspender um aplicativo publicado sem aviso prévio. Planeje folga maior para a primeira.
De quem devem ser as contas de desenvolvedor?
Da sua empresa. Sempre, sem exceção, e essa é a decisão mais importante de todo este texto.
É comum e conveniente que o fornecedor publique o aplicativo na conta dele, principalmente quando a pressa aperta. O problema aparece depois. A conta de desenvolvedor é a dona do aplicativo publicado, das avaliações acumuladas, do histórico de downloads e do vínculo com quem já instalou. Se essa conta é do fornecedor e a relação termina, você não leva nada disso: precisa publicar um aplicativo novo, do zero, e pedir a cada usuário que instale outra vez.
Junto com a conta, três itens precisam estar sob controle da empresa: os certificados de assinatura, que provam que a atualização vem de quem publicou o original; o cadastro de faturamento, se o app vende algo; e o acesso administrativo, com o fornecedor entrando como convidado que pode ser removido a qualquer momento. É a mesma lógica que já defendemos ao falar de código-fonte e documentação: o ativo é seu, o parceiro tem acesso.
Como referência de ordem de grandeza, a conta da Apple é uma anuidade e a do Google é uma taxa única, ambas em valores baixos frente ao custo do projeto. Não é o dinheiro que trava: é o processo de verificação da empresa, que exige documentos e pode levar dias ou semanas.
O que as lojas exigem antes de aceitar o seu aplicativo?
Além do aplicativo funcionando, existe uma lista de itens obrigatórios que precisa ser preparada em paralelo ao desenvolvimento, não depois:
- Política de privacidade publicada. Precisa estar acessível numa página pública e descrever de verdade o que o app coleta. As duas lojas exigem também um formulário declarando quais dados são coletados e para quê, e a declaração precisa bater com o comportamento real.
- Justificativa de cada permissão. Câmera, localização, contatos, notificação. Cada permissão pedida precisa de uma explicação em texto e de um motivo evidente dentro do app. Permissão pedida sem uso claro é motivo comum de recusa.
- Caminho para excluir a conta dentro do aplicativo. Se o app permite criar conta, precisa permitir apagá-la sem depender de e-mail para o suporte. Muitos projetos descobrem isso na recusa.
- Materiais da ficha da loja. Ícone, capturas de tela em vários tamanhos, descrição, classificação indicativa. Parece trivial e consome mais tempo do que se imagina.
- Acesso de teste para o revisor. Se o app exige login, é obrigatório fornecer usuário e senha funcionais. Credencial expirada é uma das causas mais bobas e mais frequentes de recusa.
Nada nessa lista é difícil. Todos os itens são demorados quando descobertos no último dia.
Quanto tempo leva a revisão e por que um app é recusado?
Como referência de planejamento, a revisão costuma levar de um a três dias úteis nas duas lojas quando está tudo certo, e a primeira submissão de um aplicativo novo tende a demorar mais que as atualizações seguintes. O que estoura o cronograma não é a revisão em si: é o ciclo de recusa, correção e nova submissão, que pode se repetir duas ou três vezes.
Os motivos de recusa mais comuns se repetem com uma constância impressionante. Permissão sem justificativa clara. Ausência de exclusão de conta. Política de privacidade que não corresponde ao que o app coleta. Aplicativo que é apenas o site dentro de uma casca, sem nada que justifique ser um app. Conteúdo ou funcionalidade incompleta no momento da análise. E, no caso de venda de conteúdo digital, tentar cobrar por fora do sistema de pagamento da loja.
Quando a recusa vem, ela chega com uma justificativa e um canal de resposta. Vale ler com calma antes de corrigir, porque parte relevante das recusas se resolve com esclarecimento em vez de mudança no código. Trate como diálogo, não como sentença, e reserve no cronograma pelo menos duas semanas de folga entre o app pronto e a data anunciada ao mercado.
Por que corrigir um bug em app não é igual a corrigir no site?
Esta é a diferença que mais frustra quem vem do mundo web e nunca foi avisado. No site, você corrige e todo mundo passa a ver a versão nova no próximo acesso. No aplicativo, não.
Depois de corrigir, a nova versão precisa ser submetida, revisada e aprovada outra vez. E, mesmo aprovada, ela só chega a quem atualiza. Uma parcela dos usuários fica em versões antigas por semanas ou meses, o que significa que o seu servidor precisa continuar atendendo versões velhas do aplicativo por bastante tempo. Isso tem consequência direta na forma de construir as integrações.
Na prática, isso muda três coisas na gestão do produto. Correção urgente deixa de ser instantânea, então vale manter no app a possibilidade de desligar funcionalidades remotamente sem nova publicação. Testes antes de publicar passam a ser mais críticos, porque o custo de errar é maior. E a decisão entre aplicativo e site responsivo ganha um argumento a mais, que exploramos ao comparar aplicativo e site responsivo.
O que precisa estar no contrato com o fornecedor?
Boa parte dos problemas que vemos nessa fase são contratuais, não técnicos. Quatro pontos merecem estar escritos antes de o projeto começar.
Primeiro, propriedade das contas e certificados, com a empresa como titular desde o dia um. Segundo, a publicação como entregável explícito do escopo, incluindo o acompanhamento das recusas até a aprovação. Já vimos contratos em que a entrega era o aplicativo pronto, e a publicação virou serviço extra cobrado à parte no pior momento possível.
Terceiro, um período de suporte pós-lançamento, porque os primeiros dias em produção sempre revelam problemas que nenhum teste antecipa. Quarto, a obrigação de transferir contas, certificados, código e documentação em prazo definido ao fim da relação. Esses pontos se encaixam naturalmente no que já detalhamos sobre contrato de desenvolvimento de software.
Vale notar que aplicativos de uso interno, distribuídos apenas aos funcionários, seguem caminhos diferentes e costumam evitar a revisão pública, assunto que tratamos em aplicativo interno para equipes.
Publicação é parte do projeto, não um detalhe do fim
O erro que se repete em quase todo primeiro aplicativo é tratar as lojas como uma formalidade de entrega. Elas são, na prática, um cliente adicional do seu projeto: têm requisitos próprios, avaliam antes de aceitar e podem dizer não. Um projeto que só descobre esses requisitos no fim vai reformar o que já estava pronto.
O ajuste é simples e barato quando feito no começo. Coloque a criação das contas na primeira semana do projeto, monte a lista de exigências das lojas junto com os requisitos do produto e reserve duas semanas de folga entre o app aprovado internamente e a data anunciada ao mercado. Quem faz isso lança na data combinada.
Na DevCore, cuidamos do ciclo completo de aplicativos, do desenvolvimento à aprovação nas lojas e às atualizações seguintes, dentro dos nossos serviços de desenvolvimento mobile, sempre com as contas em nome do cliente. Se a sua empresa vai lançar o primeiro aplicativo, fale com o nosso time antes de fechar a data com o marketing.
Perguntas frequentes sobre publicar aplicativo nas lojas
Preciso publicar nas duas lojas ao mesmo tempo?
Não é obrigatório, e às vezes não é o melhor caminho. Muitas empresas publicam primeiro na loja do Google, cuja aprovação inicial costuma ser mais rápida, e usam esses dias para ajustar o que aparecer antes de submeter à Apple. O que importa é que a comunicação ao mercado só aconteça quando as duas estiverem no ar, para não frustrar metade do público.
O que acontece se a loja recusar o aplicativo várias vezes?
Não existe punição por recusa, e não há limite prático de tentativas. O custo é tempo. Recusas repetidas costumam indicar que o motivo original não foi compreendido, e nesses casos vale usar o canal de comunicação da loja para pedir esclarecimento em vez de submeter de novo no escuro.
Posso cobrar meus clientes por fora do sistema de pagamento da loja?
Depende do que está sendo vendido. Conteúdo e funcionalidades digitais consumidos dentro do app geralmente precisam usar o pagamento da loja, que retém um percentual. Produtos e serviços físicos ou consumidos fora do aplicativo normalmente podem usar o seu próprio meio de pagamento. Essa distinção afeta a margem do negócio e deve ser verificada antes de definir o modelo comercial, não depois.