Aula 32 · Semana 13 · Quarta, 2 de dezembro de 2026 · 16:30 às 18:30
Consolas das lojas e review da sprint 3
Teoria (30 minutos): Play Console e App Store Connect: ficha da app, declarações de privacidade, tracks, rollout gradual e revisão. Prática: última review de sprint, retrospetiva final e lista de pendentes para o freeze de 09/12.
Freeze: 09/12 às 18:30
No fim desta aula consegues
Descrever o que uma ficha de app precisa na Play Console e no App Store Connect, e o que as declarações de privacidade exigem.
Distinguir os tracks de teste e produção, e explicar para que serve um rollout gradual.
Responder a uma rejeição da revisão de forma metódica.
Ler ratings, reviews e vitals depois de publicar, e dizer o que fazem à visibilidade da app.
Apresentar a sprint 3 do teu grupo e sair com a lista de pendentes fechada para o freeze.
Play Console: ficha e data safety (1 de 2)
Ficha da loja: nome (30 caracteres), descrição curta (80), descrição longa (4000), ícone 512×512, imagem de destaque 1024×500, pelo menos dois screenshots de telemóvel, categoria, e-mail de contacto e URL da política de privacidade. A política é obrigatória para todas as apps.
Data safety form: que dados recolhes, quais partilhas, com que fim, se vão cifrados, se o utilizador pode pedir para apagar. Aparece na ficha antes de instalar. Tens de declarar também o que os SDKs recolhem: o Crashlytics recolhe identificadores de dispositivo e logs de crash.
Classificação de conteúdo: questionário IARC que gera a classificação por região (PEGI na Europa). Sem ele a app não publica.
Conta de programador: 25 USD uma vez; a Google verifica a identidade e, para contas pessoais, pode exigir uma fase de teste fechado com testers antes da produção.
Para os testes: a data safety form declara o que a app e os seus SDKs recolhem; mentir nela é motivo de remoção.
Play Console: tracks, rollout e pré-lançamento (2 de 2)
Do círculo pequeno ao grande: cada track apanha problemas antes do seguinte, e o rollout gradual limita o estrago em produção.
Track
Quem instala
Para quê
Internal testing
Até 100 e-mails, sem revisão, disponível em minutos
A equipa e a turma
Closed testing
Listas ou grupos Google, com revisão
Beta privada; obrigatório para contas novas
Open testing
Qualquer pessoa pela ficha
Beta pública, feedback em escala
Production
Todos
Com rollout gradual: 1 %, 5 %, 20 %, 50 %, 100 %
O rollout gradual serve para apanhar um crash com 1 % dos utilizadores em vez de 100 %. Podes parar (halt), mas não voltar atrás: a correção é um versionCode novo.
O pré-lançamento corre a app em dispositivos reais da Google, tira screenshots e reporta crashes e problemas de acessibilidade antes de tu publicares.
A revisão da Play demora de horas a alguns dias; permissões sensíveis (localização em background, SMS) demoram mais e pedem vídeo.
Analogia O rollout gradual é abrir a loja primeiro a 5 % dos clientes e olhar para as queixas antes de abrir a todos. Se os vitals piorarem, fecha-se a porta (halt) e corrige-se com um versionCode novo; os outros 95 % nunca chegaram a ver o problema.
App Store Connect: ficha, privacy labels e screenshots
Ficha: nome (30), subtítulo (30), descrição (4000), palavras-chave (100 caracteres, separadas por vírgula), URL de suporte e de política de privacidade, categoria, questionário de idade.
Screenshots por dispositivo: um conjunto para iPhone de 6,9 polegadas é obrigatório; iPad de 13 polegadas se a app corre em iPad. As imagens têm de ser da app real, não maquetes.
Privacy nutrition labels: três caixas na ficha, "Data used to track you", "Data linked to you" e "Data not linked to you". Preenches por categoria de dados e finalidade, incluindo o que os SDKs fazem.
Privacy manifest (PrivacyInfo.xcprivacy): desde 2024 os SDKs e a app declaram as APIs sensíveis que usam e porquê. Sem ele, o upload é rejeitado.
A ficha e o build são coisas separadas: podes ter a ficha pronta semanas antes do primeiro build.
Para os testes: as privacy labels da Apple e a data safety da Google são a mesma pergunta em dois formulários: o que recolhes, para quê, e se está ligado à pessoa.
App Store Connect: review notes e o que a revisão verifica
Review notes: conta de demonstração com credenciais, como chegar a cada funcionalidade, o que é preciso para testar (uma tag NFC, uma localização nos Açores). Se precisa de hardware, junta um vídeo. Metade das rejeições evita-se aqui.
O que verificam: crashes, funcionalidade incompleta ou conteúdo de teste, login obrigatório sem razão, metadata que não corresponde à app, privacidade, pagamentos fora do sistema da loja, apps que são "só um site".
Tempo: a maioria das revisões fecha em 24 a 48 horas. A primeira submissão de uma app nova demora mais.
Expedited review: pedido por formulário para correções críticas ou eventos com data. Funciona quando a razão é real; abusar fecha a porta.
A revisão da Google é mais automática, a da Apple é mais humana. Nas duas há guidelines numeradas: a rejeição cita o número.
Analogia As duas lojas são alfândegas, mas com inspeções diferentes. A da Apple é humana: alguém abre a app, carrega nos botões e lê as review notes, por isso demora um ou dois dias e cita a regra que falhou. A da Google é sobretudo por máquina: mais rápida, mas apanha o que se mede automaticamente (data safety, target API level, permissões) e não perdoa formulários mal preenchidos.
Responder a uma rejeição
Lê a guideline citada, inteira, no site da Apple ou da Google. A mensagem da rejeição resume; a guideline explica.
Responde no Resolution Center (Apple) ou no formulário de recurso (Google) se achas que o revisor não percebeu. Curto, factual, com screenshots ou vídeo. Muitas rejeições resolvem-se com uma explicação.
Corrige e volta a submeter se o problema é real. Um build novo, com número de build novo, e notas a dizer o que mudou.
Recorre ao App Review Board ou ao apoio da Play só quando a resposta e a correção não chegaram. É lento.
Não faças upload do mesmo build à espera de outro revisor, e não discutas: o objetivo é publicar, não ter razão.
Exemplo real "Guideline 2.1: we were unable to log in." A resposta certa não é discutir: é uma conta de demonstração que funciona e um vídeo de 30 segundos. Publicado no dia seguinte.
Depois de publicar: ratings, reviews e vitals
Ratings e reviews: responde em público, com educação, a todas as que dizem algo concreto. Pede avaliação dentro da app no momento certo (in_app_review), nunca ao arrancar. A Play pesa mais as avaliações recentes.
Android vitals: a Play mede a taxa de crashes e de ANR percebidos pelo utilizador. Acima dos limiares (cerca de 1,1 % de crashes e 0,5 % de ANR) a app perde visibilidade na loja e ganha um aviso na ficha. Isto é uma sanção real, não uma sugestão.
App Store: métricas de crashes, retenção e conversão da ficha em App Analytics; os crashes com símbolos aparecem no Xcode Organizer.
Adoção por versão: quantos utilizadores ainda estão na versão anterior. Decide quando podes desligar uma API antiga (aula 28) ou forçar atualização (aula 30).
Rollout gradual + vitals é o ciclo: sobe a percentagem quando os números aguentam, pára quando não.
Para os testes: as lojas penalizam a visibilidade de apps que ultrapassam os limiares de crash e ANR; publicar é o início da manutenção, não o fim.
Review da sprint 3: o formato
Minuto
O que o grupo faz
0 a 1
Objetivo da sprint em duas frases e o que ficou feito vs planeado (a partir do board de issues, não de memória).
1 a 4
Demo no telemóvel projetado, build de release: fluxo completo de utilizador, incluindo modo avião e um estado de erro.
4 a 5
Um problema técnico que resolveram esta sprint e como. Uma pessoa diferente da que fez a demo.
+2
Feedback do docente e dos colegas: uma coisa boa, uma coisa a corrigir antes do freeze.
Ordem: a do sorteio de hoje ao chegar. Quem não está pronto quando é chamado passa para o fim.
É a última review antes das defesas. O que ouvires aqui é o que vais ouvir no dia 14 se não corrigires.
Retro final: se começassem de novo
Cinco minutos em silêncio. Cada pessoa escreve num post-it (ou numa issue) uma coisa que faria diferente desde o kickoff e uma coisa que repetiria tal e qual.
Cinco minutos no grupo. Leem-se, agrupam-se, escolhe-se uma de cada.
Um minuto por grupo para a turma. A de "faria diferente" e a de "repetiria".
As que aparecem sempre: "começar os testes mais cedo", "PRs mais pequenos", "não deixar o offline para o fim", "combinar quem faz o quê antes de abrir o editor".
A retro não é para culpar ninguém. É para que a próxima equipa em que estiverem, na empresa, não repita o mesmo.
Tarefa Cada grupo cola as duas frases escolhidas no README, numa secção "Retrospetiva". Faz parte da entrega e diz muito sobre a equipa a quem ler o repositório.
Lista de pendentes para o freeze de 09/12
Cria uma milestone "Freeze v1.0.0" no GitHub e mete lá só as issues que cabem em cinco dias úteis. O resto vai para uma milestone "Depois" e fica escrito no README como trabalho futuro.
Prioridade: requisitos mínimos a funcionar, depois estados de erro e offline, depois CI verde, depois README e distribuição, só depois extras. Corta funcionalidades, não qualidade.
Cada issue com um responsável e um PR associado. Uma issue sem dono na sexta é uma issue que não vai ser feita.
Sexta (aula 33) é o workshop de finalização: tragam a lista feita, não é para a fazer lá.
Quarta 09/12 às 18:30: tag v1.0.0. A partir daí só o README pode mudar.
Tarefa Antes de sair da sala, cada grupo mostra ao docente a milestone "Freeze v1.0.0" com as issues, os responsáveis e os dois pontos de feedback da review lá dentro.
Até à próxima aula
Para fazer
Fechar os pendentes da milestone "Freeze v1.0.0" até sexta, com PRs revistos por um colega.
Secção "Retrospetiva" no README com as duas frases do grupo.
Sexta às 08:30: revisão para o teste 2 e workshop de finalização. Traz o portátil, o telemóvel e o keystore acessível.
First-time app review guide (Capgo): o que uma primeira submissão precisa nas duas lojas, incluindo o teste fechado obrigatório na Play para contas novas.