Preparar uma app para a App Store e o Google Play

A sua app funciona no telemóvel. Pode anunciar o lançamento?

Eu não marcaria a campanha apenas com essa confirmação. Antes, pediria uma entrega específica: tudo o que permite submeter a app às lojas, responder à revisão e disponibilizá-la ao público certo.

A Apple e a Google têm processos de revisão e informação obrigatória para publicação. Na App Store, por exemplo, selecionar a versão e deixá-la preparada para revisão ainda não significa que tenha sido enviada. No Google Play, também existem estados distintos para a app, as atualizações e os elementos da publicação. (developer.apple.com)

Para o seu negócio, a decisão é concreta: autorizar a submissão não deve ser o mesmo que autorizar o anúncio público. Trate esses momentos separadamente. O guia seguinte destina-se ao lançamento de uma app pública para clientes, não à distribuição interna aos trabalhadores.

Comece pela conta em que a app vai ficar

Antes de aprovar imagens ou descrições, peça para ver as contas de publicação.

A minha recomendação é que uma empresa publique através das suas próprias contas de organização e atribua acessos à equipa de desenvolvimento. Assim, a responsabilidade pelo produto não fica confundida com a relação com um fornecedor.

Na Apple, a inscrição de uma organização exige uma entidade legal, uma pessoa com autoridade para celebrar os acordos e, salvo exceções previstas, um número D‑U‑N‑S. A Google também distingue contas pessoais de contas de organização e exige esse identificador para criar uma conta empresarial. Não presuma que basta usar o nome comercial no formulário. (developer.apple.com)

Peça à pessoa responsável pelo projeto que confirme:

Qual é a entidade titular de cada conta?
Quem controla o endereço de contacto e a recuperação de acesso?
Quem pode aceitar acordos em nome da empresa?
Quem submete versões e acompanha as mensagens das lojas?
Quem assume essas tarefas se o contacto habitual estiver ausente?

Estas perguntas devem ficar resolvidas antes da entrega final. A equipa técnica pode preparar o processo, mas recomendo que alguém da empresa fique responsável por desbloquear decisões administrativas.

A revisão precisa de conseguir usar o serviço

Imagine uma empresa de aluguer de equipamentos que cria uma app para os clientes consultarem contratos e prolongarem reservas. A instalação pode correr bem e, ainda assim, quem revê a app não conseguir passar do início de sessão.

A Apple pede informação de acesso e instruções quando são necessárias para avaliar a app. A Google também exige os elementos que permitam entrar em áreas restritas, incluindo instruções relevantes para mecanismos de autenticação. Uma conta que não funciona não cumpre esse objetivo. (developer.apple.com)

Neste exemplo, eu prepararia uma conta de demonstração com um contrato fictício e uma reserva que pudesse ser alterada. O objetivo seria mostrar o percurso completo sem expor dados de clientes nem provocar uma operação real.

Peça à equipa para executar o teste a partir de uma instalação nova, seguindo apenas as instruções que vai entregar. Se precisar de telefonar a um programador para continuar, as instruções ainda não estão prontas.

Vale a pena esclarecer por escrito:

Que credenciais devem ser usadas e como se ultrapassam os passos adicionais de autenticação?
Que dados de demonstração existem?
Há limitações geográficas ou condições especiais de acesso?
Como se testam operações que, normalmente, teriam consequências comerciais?

Mantenha esse acesso disponível durante a revisão. Evite uma demonstração que dependa de alguém estar no escritório para aprovar manualmente cada tentativa.

Descreva os dados que a app realmente utiliza

Quem preenche os formulários de privacidade precisa de conhecer a implementação, não apenas a ideia inicial do produto.

A Apple pede informação sobre as práticas de recolha de dados da app, incluindo as de parceiros cujo código esteja integrado. A secção de segurança dos dados do Google Play também abrange dados tratados através de bibliotecas e componentes de terceiros. Por isso, adicionar uma ferramenta de análise ou de diagnóstico pode ser relevante para as declarações da publicação. (developer.apple.com)

Não recomendo que o responsável de marketing responda sozinho a estes formulários, nem que a equipa técnica decida sem validação da empresa. Peça primeiro um inventário simples, com uma linha por tipo de dado:

Dado utilizado, como endereço de email ou localização.
Função que justifica a sua utilização.
Destino: apenas o dispositivo, servidores da empresa ou um fornecedor.
Componente da app responsável pelo tratamento.
Pessoa que confirmou a informação.

Depois, use esse inventário para verificar as respostas em cada loja. As perguntas não são idênticas; não copie mecanicamente a declaração de uma plataforma para a outra. A documentação de ambas explica os respetivos critérios. (developer.apple.com)

Também deve existir uma política de privacidade acessível e adequada à app. A Apple exige ligações funcionais para privacidade e suporte; a Google inclui requisitos de política de privacidade na preparação da publicação. Preencher as fichas das lojas não substitui esse trabalho. (developer.apple.com)

Feche a montra da app sem prometer a próxima versão

A página da loja deve apresentar o produto que vai ser entregue. Não a versão que espera ter daqui a alguns meses.

A Apple identifica conteúdo provisório, ligações sem funcionamento e informação incompleta entre os problemas a evitar na submissão. A preparação no Google Play inclui declarações sobre conteúdo, acesso, público e classificação etária, conforme aplicável. Estes elementos merecem validação própria, além dos testes técnicos. (developer.apple.com)

Para uma app de aluguer, prefira imagens de uma reserva e de um contrato de demonstração a ecrãs vazios. Confirme que a descrição distingue aquilo que o cliente faz sozinho daquilo que continua a depender de aprovação da empresa.

Sugiro uma revisão conjunta entre quem conhece o serviço e quem acompanha o desenvolvimento. Abram a app ao lado dos materiais da loja e comparem cada promessa com o comportamento observado.

Se a descrição diz que o prolongamento é imediato, mas o pedido fica pendente, corrija a descrição ou a função antes de avançar. Essa decisão pertence ao negócio; não deve ser deixada para a pessoa que carrega as imagens.

Use esta grelha para autorizar a submissão

A grelha abaixo é uma proposta de controlo de entrega. Não substitui os requisitos das lojas: serve para a sua empresa saber o que foi verificado, por quem e em que versão.

Preencha cada linha separadamente para iPhone e Android. Use três estados: pronto, bloqueado e não aplicável, este último sempre com justificação.

|---|---|---|---|

| Informação sobre dados | Inventário revisto e respostas preparadas para cada loja | Produto, equipa técnica e apoio de privacidade | Há componentes cujo tratamento de dados é desconhecido |

Não use uma percentagem de conclusão para ultrapassar um bloqueio. Se a conta de demonstração não entra, ter todas as imagens prontas não resolve o problema.

Em contrapartida, distinga bloqueios de preferências. Uma alteração de redação que não compromete a exatidão pode ficar para depois; uma função anunciada mas indisponível merece outra decisão.

Separe o calendário técnico do calendário comercial

Evite comprometer uma data pública contando que ambas as lojas vão responder ao mesmo tempo. A Google avisa que certas revisões podem demorar até sete dias, ou mais em casos excecionais. Esse prazo não é uma promessa para a sua app. (support.google.com)

Na Apple, confirme o estado real da submissão: «Ready for Review» significa que a informação está preparada, mas a app ainda não foi submetida. Peça uma confirmação de envio, não apenas uma mensagem a dizer que está tudo carregado. (developer.apple.com)

Organize o lançamento com três autorizações distintas:

1. Versão aceite pela empresa: os testes acordados passaram e os problemas pendentes têm uma decisão registada.

2. Submissão autorizada: contas, acessos, declarações e materiais estão preparados.

3. Campanha autorizada: a disponibilidade foi confirmada para o público pretendido e o apoio ao cliente está preparado.

Se apenas uma plataforma estiver disponível, decida expressamente entre esperar ou lançar por fases. Não deixe que essa escolha resulte de um anúncio automático ou de uma data antiga no plano de marketing.

O que deve ficar na entrega do fornecedor

Ao contratar o desenvolvimento de uma app para iPhone e Android, peça que a proposta esclareça onde termina o trabalho de publicação.

A submissão está incluída? Quem responde a uma rejeição? Como se distingue a correção de um problema da versão entregue de uma nova funcionalidade pedida pela empresa? Quem mantém os dados de demonstração durante esse período?

Estas perguntas não garantem aprovação. Permitem, porém, acordar responsabilidades antes de surgir um impedimento.

Para a próxima reunião do projeto, leve a grelha preenchida e peça duas decisões: o que falta para submeter e o que falta para anunciar. Se as respostas forem diferentes, mantenha-as diferentes no calendário. É preferível ajustar a campanha enquanto ainda está em preparação do que convidar clientes para uma app que ainda não conseguem instalar.