O que new-app-info (novas-informações-do-app) faz?
Transforma o pedido "precisamos de informações adicionais" da Apple em um único arquivo. O usuário responde com ele no App Store Connect e também cola no campo Notas das Informações da Revisão do App, para que submissões futuras já o tenham. A gravação é a única parte que só o usuário pode fazer.
Os seis itens que a Apple exige
Cada pacote responde a todos os seis itens, numerados de 1 a 6 nesta ordem, mesmo que a mensagem do usuário enviada pela Apple esteja faltando ou com uma redação diferente. Se a mensagem da Apple adicionar ou alterar um item, siga a versão da Apple e anote o que foi diferente.
| # | A Apple pede | Respondido por |
|---|---|---|
| 1 | Uma gravação de tela capturada em um dispositivo físico executando o sistema operacional mais recente. Deve começar com o lançamento do app e mostrar o fluxo típico do usuário, incluindo, quando o app os tiver: registro de conta, login e exclusão de conta; conteúdo gerado pelo usuário com sua denúncia e bloqueio; e acesso a conteúdo ou funcionalidades pagos | Parte 1 (a lista de cenas) + resposta §1 |
| 2 | O propósito do app e o público-alvo: o problema que ele resolve e o valor que oferece | Resposta §2 |
| 3 | Instruções para configurar e acessar as principais funcionalidades, incluindo quaisquer credenciais de login ou arquivos de amostra necessários | Resposta §3 |
| 4 | Os serviços externos, ferramentas ou plataformas usados para a funcionalidade principal (fornecedores de dados, autenticação, processadores de pagamento, serviços de IA) | Resposta §4 |
| 5 | Quaisquer diferenças regionais em funcionalidades ou conteúdo, ou confirmação de que o app funciona da mesma forma em todas as regiões | Resposta §5 |
| 6 | Para uma indústria altamente regulamentada ou material de terceiros protegido: documentação ou credenciais que mostram a autorização | Resposta §6 |
Regras rígidas
- A gravação deve ser de um dispositivo físico, com o sistema operacional mais recente, em uma única tomada sem edição, em velocidade normal, começando ao tocar no ícone do app. Nunca ofereça uma gravação de simulador ou uma edição acelerada como a submissão. Você não pode controlar o telefone do usuário, então a gravação é dele para fazer; seu trabalho é a lista de cenas.
- Reivindique apenas o que está no build. Cada funcionalidade, serviço e idioma deve vir do código, não de planos ou notas.
- Não aplicável ainda é uma resposta. Dê em uma frase com o motivo (ex.: "O app não tem registro de conta ou login").
- Contas: se os usuários podem criar contas, a exclusão de conta é obrigatória e deve estar na gravação; se estiver faltando, relate isso como um bloqueio. Se houver um login, o item 3 precisa de credenciais de demonstração (um conjunto por tipo de conta): diga ao usuário para inseri-las no App Store Connect. Nunca escreva senhas reais no arquivo.
- Nunca envie, submeta ou edite nada no App Store Connect. O usuário cola a resposta e anexa o vídeo.
- Preencha todos os placeholders que puder a partir do repositório ou do dispositivo. Liste os que sobraram e o que preenche cada um.
Passo 1: Leia a mensagem da Apple
Se o usuário colou uma, verifique seus itens numerados em relação à tabela acima e anote quais condições de gravação (contas, UGC, conteúdo pago) se aplicam a este app.
Passo 2: Baseie-se no código
Leia o código no commit submetido, não na cópia de trabalho (fixe-o primeiro, como no Passo 6 → O build de revisão, passo 0). A cópia de trabalho geralmente é uma branch de funcionalidade com funcionalidades não lançadas, e descrevê-las para a Apple é uma reivindicação sobre um build que eles não têm. Use git grep <padrão> <commit> -- <caminhos> e git show <commit>:<caminho>.
Exclua build, Pods, .dart_tool, node_modules e .git em toda pesquisa.
| Item | Onde procurar |
|---|---|
| 1, 3: fluxo principal desde o lançamento | Roteador e telas; integração; o loop principal |
| 1, 3: contas, login, exclusão | firebase_auth, sign_in_with_apple, supabase, Auth, login, signUp, deleteAccount, delete.*data |
| 1: conteúdo gerado pelo usuário | Postagem, comentários, chat, uploads; report, block, flag |
| 1, 3: conteúdo pago | purchases_flutter, revenuecat, StoreKit, product_id, telas de paywall. Descubra quais funcionalidades são bloqueadas, quaisquer testes grátis, quando o paywall pode aparecer e onde está Restaurar Compras |
| 1: bloqueio de captura de tela | no_screenshot, truques isSecureTextEntry, UIScreen.capturedDidChange, FLAG_SECURE. Uma tela bloqueada aparece em branco na gravação, então a resposta deve dizer o porquê |
| 2: propósito e público | Texto da listagem na loja, documentos de marca ou voz, README, checklist de lançamento, texto de integração (.arb, .strings, strings.xml) |
| 3: arquivos de amostra | Importações de arquivos, seletores de documentos, leitura de QR/código de barras, hardware que o app precisa |
| 4: serviços externos | Dependências (pubspec.yaml, Podfile, package.json, Gradle) e defines de build (--dart-define, arquivos de chaves, scripts de release). Para cada um: o que faz e quais dados recebe. Liste apenas SDKs que o build de release realmente ativa |
| 5: regiões | Locais enviados; verificações de região (locale, countryCode, region); preços, funcionalidades ou conteúdo específicos da região |
| 6: regulamentado ou protegido | Conteúdo e alegações de saúde, médico, financeiro, jogos de azar, legal ou infantil; conteúdo licenciado, música, imagens, fontes e suas licenças |
| Contato | E-mails de suporte em configurações, documentos de privacidade e arquivos do site |
| Plataforma | IPHONEOS_DEPLOYMENT_TARGET, TARGETED_DEVICE_FAMILY (somente iPhone, ou iPad também) |
Verifique se a redação de análises no item 4 corresponde à política de privacidade no repositório. Sinalize se não corresponder, ou se você não puder confirmar as respostas de Privacidade do App no App Store Connect.
Passo 3: O dispositivo e o sistema operacional (item 1)
xcrun devicectl list devicesmostra os dispositivos pareados. Pegue o próprio iPhone do usuário que está disponível.xcrun devicectl device info details --device <id> | grep -i osVersionmostra a versão do iOS.- Pesquise na web pela versão mais recente do iOS. Se o telefone estiver desatualizado, diga: o usuário atualiza em Ajustes → Geral → Atualização de Software antes de gravar, então você lê a versão novamente. O sistema operacional do telefone é de responsabilidade do usuário atualizar.
- Se nenhum telefone estiver pareado, deixe
[versão do iOS]e diga ao usuário onde encontrá-la (Ajustes → Geral → Sobre).
Passo 4: Prevenir problemas comuns
Verifique cada um dos problemas comuns da Apple e coloque o resultado no relatório de volta ao usuário. Estas são verificações para o usuário, não parte da resposta.
| Diretriz | Verificação |
|---|---|
| 2.1 Bugs e travamentos | A gravação usa o build do TestFlight da versão submetida, em um dispositivo real. Plataformas suportadas de TARGETED_DEVICE_FAMILY: se o iPad for suportado, diga ao usuário para testar também em um iPad |
| 2.1 Acessando o app | Login → as credenciais de demonstração são inseridas no App Store Connect, um conjunto por tipo de conta, e ainda funcionam |
| 2.3.3 Capturas de tela | Liste as capturas de tela da loja (ex.: app-store-assets/*screenshots*). Sinalize qualquer uma que pareça apenas arte do título, uma tela de abertura ou uma tela de login |
| 3.1.1 Compra dentro do app | Cada id de produto no código está configurado no App Store Connect e anexado a esta submissão. Liste os ids para o usuário verificar |
| 3.2 Outros modelos de negócios | Se o app é para uma empresa, organização ou seus funcionários, sinalize que precisa de uma opção de distribuição diferente (apps personalizados ou distribuição não listada) |
Passo 5: Escreva o arquivo
Escreva app-store-assets/new-app-info.md se essa pasta existir, senão ./new-app-info.md. Mantenha esta forma (um exemplo completo está em examples/seven-minute-math/new-app-info.md):
# Informações da Revisão do App — <Nome do app>
Responda no App Store Connect com a Parte 2 e anexe a gravação. Depois cole a Parte 2 em
Informações da Revisão do App → Notas, para que submissões futuras a tenham.
<Placeholders ainda a preencher, se houver.>
## Parte 1 — a gravação de tela (item 1; grave você mesmo)
Porquê: um dispositivo físico, o sistema operacional mais recente, uma tomada, velocidade normal, começando ao tocar no ícone.
Configuração (padrão: um build de release instalado a partir do Mac; veja "O build de revisão" abaixo):
crie um testador sandbox (App Store Connect → Usuários e Acesso → Sandbox → Contas de Teste);
exclua o app do telefone; você compila e instala o build de revisão; Gravação de Tela na
Central de Controle com o microfone desligado; Não Perturbe ativado; faça login na folha de compra da Apple com
o testador sandbox (a folha dizendo "Sandbox" é esperada).
Lista de cenas, numerada: toque no ícone → integração → o fluxo típico do início ao fim → resultados →
cada condição de gravação que se aplica (inscrever-se, fazer login, excluir a conta; publicar, denunciar,
bloquear; paywall, compra sandbox, a funcionalidade desbloqueada, Restaurar Compras) → como os usuários
excluem seus dados → parar.
Qualquer tela que ficará em branco (bloqueio de captura) e porquê.
## Parte 2 — a resposta (cole isto)
Saudação, mais o dispositivo e a versão do iOS em que a gravação foi feita.
**1. Gravação de tela** … **6. Indústria regulamentada / material de terceiros**: uma seção em negrito para cada.
Linha de encerramento com o e-mail de suporte.
Escrita:
- §1: o que a gravação mostra, quais condições de gravação não se aplicam e porquê, e quaisquer telas em branco.
- §2: para quem é, o problema, como o app o resolve, o valor. Três ou quatro frases.
- §3: o que é necessário para começar (credenciais vão no App Store Connect, nunca no arquivo), depois as principais funcionalidades em uma lista curta, com grátis vs pago e quando o paywall aparece.
- §4: um item por serviço com o que ele faz. Depois uma linha dizendo o que o app não usa (IA, fornecedores de dados, autenticação), onde isso for verdade.
- §5: idiomas e quaisquer diferenças regionais, ou "funciona da mesma forma em todas as regiões".
- §6: documentação, ou "Não aplicável" com o motivo.
- Simples, factual e educado. Sem linguagem de marketing.
Passo 6: O vídeo completo (item 1)
O build de revisão
Grave um build de release exatamente da versão que está em revisão, instalado no telefone diretamente a partir do Mac. Você compila e instala; o usuário grava.
- Fixe a versão submetida. Pergunte ao usuário a versão e o número do build mostrados no App Store Connect para a submissão em revisão (ex.: 1.0.0 (1)), a menos que ele já tenha fornecido. Encontre o commit que a produziu: uma tag de release, a branch release ou main, uma mensagem de commit como "enviado para a App Store", ou o commit onde
pubspec.yaml/Info.plistdefiniram essa versão e build. Se dois commits puderem corresponder, pergunte qual. Nunca compile a partir da cópia de trabalho: geralmente está em uma branch de funcionalidade com alterações não commitadas que a Apple não viu. Compile em uma worktree isolada (git worktree add --detach <scratch>/review-build <commit>) [nota: emborascratchnão seja traduzido, mantive o comando original). Copie quaisquer arquivos de chave ignorados pelo git (ex.:keys.json) para ela comcp, sem lê-los. Diga ao usuário qual commit você está compilando e o que está em branches mais novas que não estarão no vídeo. - Encontre o build de dispositivo normal do projeto (scripts de execução,
tool/*.sh, Makefile, Fastlane). Remova toda flag que finja compras, comoDUMMY_PURCHASES,MOCK,FAKE,USE_TEST_STORE, uma chavetest_do RevenueCat ou um arquivo de configuração StoreKit. Uma compra falsa nunca mostra a folha da Apple, e um revisor vendo funcionalidades pagas desbloqueadas sem ela pode tratar isso como uma forma de contornar a compra dentro do app (3.1.1). Verifique se a chave de compra é a chave da loja real apenas pelo seu prefixo (ex.:grep -q '"REVENUECAT_IOS_KEY": "appl_'); nunca imprima valores de chave. - Compile em modo release, nunca debug: builds de debug do Flutter e React Native não podem ser abertos a partir do ícone da tela inicial, e a Apple quer que a gravação comece ali. Flutter:
flutter build ios --releasecom as defines habituais do projeto menos as falsas. - Verifique se o app compilado corresponde à submissão:
/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" -c "Print CFBundleVersion" build/ios/iphoneos/Runner.app/Info.plistdeve imprimir a versão e o build submetidos. Se não imprimir, pare e diga ao usuário. - Peça ao usuário para excluir o app do telefone primeiro (isso apaga os dados no telefone, então é decisão dele), depois instale:
xcrun devicectl device install app --device <id> build/ios/iphoneos/Runner.app. - Builds instalados a partir do Mac compram através do sandbox da Apple, então o usuário precisa de um testador sandbox para fazer login na folha de compra. Uma instalação do TestFlight do mesmo número de build também funciona (as compras são gratuitas com o próprio Apple ID), e garante o binário exato que a Apple tem. Use-a se o usuário preferir.
Gravação e verificação
O pacote não está completo até que a gravação exista e tenha sido verificada. O usuário a grava; você o orienta através dela. No chat, forneça a configuração da Parte 1 (incluindo o testador sandbox) e a lista de cenas numerada. Peça a ele para enviar o arquivo via AirDrop para app-store-assets/review-recording/ e avisar quando estiver lá. Então:
ffprobe -v error -show_entries format=duration:stream=width,height,codec_name -of default=nw=1 <arquivo>. Verifique se a resolução corresponde a uma tela real de iPhone (não a uma janela de simulador ou uma edição cortada) e se a duração cobre todo o fluxo.- Faça uma folha de contato com um quadro a cada 10 segundos:
ffmpeg -i <arquivo> -vf "fps=1/10,scale=240:-1,tile=8x8" -frames:v 1 <dir>/contact.png. Também salve o primeiro quadro sozinho. Leia ambos. - Verifique, em ordem: o primeiro quadro mostra a tela inicial ou o ícone do app sendo tocado; cada passo da lista de cenas...
[truncado para tradução]