Nota, agosto de 2026: este post é de uma versão anterior e descreve a estrutura de níveis daquela época. O AlcoLog fundiu o nível Pro no Premium na v1.2.0, então agora existe um único nível pago. Nada se perdeu na fusão, e quem tinha o Pro passou para o Premium sem custo adicional.

Se você está prestes a lançar um app iOS v1.0 com assinaturas, compras dentro do app, um companheiro para o Watch, widgets ou qualquer tipo de posicionamento ligado à saúde, o processo de App Review vai ser mais difícil do que a documentação sugere. Este post é o relato de um ciclo de lançamento (quatro rejeições em cinco dias, cinco revisores, um único binário) e dos padrões que tornaram o ciclo suportável. Estou compartilhando porque essa experiência é uma das partes menos documentadas do lançamento de um app indie sério, e a versão documentada (sessões da WWDC, a página das Review Guidelines, os fóruns de desenvolvedores) não corresponde à realidade do dia a dia.

Se você está no meio do ciclo e procura correções táticas, pule direto para “O que corrigir antes de enviar” e “Padrões que vale a pena entender”. A cronologia pessoal está na segunda metade, se você quiser contexto.

# O que corrigir antes de enviar

Estes são os itens que apareceram ao longo de quatro rejeições. Se você corrigir tudo antes, elimina a maior parte da superfície de rejeição de uma v1.0 de categoria sensível com assinaturas.

# Hierarquia da exibição de preços nos paywalls de assinatura

As Human Interface Guidelines da Apple para assinaturas são inequívocas sobre a apresentação de preços. O valor cobrado precisa ser o elemento de preço mais proeminente. O instinto de marketing (fazer o desconto parecer a grande vantagem) é o instinto errado aqui. O instinto de conformidade (fazer do valor cobrado o herói tipográfico) é o certo.

O que isso significa na prática: o preço normal deve ser o elemento maior e mais pesado. O preço introdutório ou promocional deve ser menor, com o rótulo explícito “Primeiro período:”. Evite selos de porcentagem em marcadores pequenos (use “OFERTA DE LANÇAMENTO”, não “25% OFF”). A aplicação da 3.1.2© Payments and Subscriptions nesse ponto é consistente entre os revisores.

# Um caminho explícito para excluir os dados

Mesmo quando sua “conta” é só um identificador anônimo opcional, a 5.1.1(v) da Apple exige um caminho de exclusão rotulado, visível e imediato. Desligar uma chave como exclusão implícita parece conforme do lado do desenvolvedor, mas não satisfaz a aplicação atual.

Coloque um botão explícito “Excluir meus dados” na tela de privacidade ou de ajustes desde a primeira build. Adicione um alerta de confirmação. Garanta que o texto ao redor descreva o comportamento real de exclusão, e não um prazo genérico que você pretende revisar depois.

# Audite o Info.plist em busca de declarações vestigiais

Modos em segundo plano, busca em segundo plano, permissões de localização, declarações do HealthKit e entradas semelhantes do Info.plist podem ficar sem uso por meses enquanto a base de código evolui. Elas são sinalizadas quando não correspondem a um recurso real. A aplicação da 2.5.4 Software Requirements aqui é mecânica e inequívoca.

Especificamente: qualquer entrada de UIBackgroundModes precisa corresponder a um recurso que realmente a utilize. Se o seu app declara “location” como modo em segundo plano mas você nunca usa localização contínua em segundo plano e tem allowsBackgroundLocationUpdates = false, remova a declaração. O monitoramento de região não exige isso. A auditoria leva dez minutos e evita um ciclo de rejeição.

O campo Política de Privacidade no App Store Connect é bem conhecido. A exigência dos Termos de Uso é menos conhecida. Se você usa o EULA padrão da Apple, inclua um link para os Termos de Uso na descrição do app. Se usa um EULA personalizado, adicione-o no campo de EULA personalizado do App Store Connect.

A própria página de termos deve divulgar todos os produtos pagos, com duração da assinatura, preço e mecânica de renovação. A maioria dos times tem esses elementos espalhados por páginas separadas ou enterrados na política de privacidade. Consolide tudo em uma página de termos que o revisor consiga ler em dois minutos.

# Vídeos de App Preview: use capturas de tela puras

Mockups de celular em 3D, molduras de aparelho e composições estilizadas de marketing são decisões a critério do revisor sob a 2.3.4 Accurate Metadata. A página pública de orientação não proíbe explicitamente molduras de aparelho, mas o material de treinamento interno com que os revisores trabalham aparentemente proíbe. Capturas de tela simples, em resolução nativa, são inequivocamente seguras.

Guarde o enfeite de marketing para o seu próprio site, redes sociais e Reddit. Coloque capturas de tela no espaço do App Preview. A diferença de conversão entre “preview de mockup caprichado” e “preview de gravação de tela pura” é pequena. A redução de risco é grande.

Os revisores trabalham com orçamentos de tempo de 5 a 15 minutos por app. Eles nem sempre vão encontrar todas as compras anexadas à versão. Se as suas compras são alcançadas por caminhos diferentes dentro do app (paywalls separados, cartões separados, navegação mais profunda), inclua o caminho clique a clique de cada compra nas suas App Review Notes.

Um formato que funciona:

Assinaturas Premium e compra vitalícia: aba Ajustes > cartão Premium > botão Obter Premium > painel de upgrade do Premium Assinaturas Pro e compra vitalícia: aba Ajustes > cartão Pro > botão Obter Pro Itens consumíveis do Tip Jar: aba Ajustes > role para além dos cartões de nível > cartão Tip Jar > Mostrar opções de gorjeta

Parece exagero. Evita um ciclo específico de rejeição (Guideline 2.1(b) Information Needed) que, sem isso, custa um dia.

# Folga no calendário entre o envio e a data de lançamento assumida

Para uma submissão v1.0 com assinaturas em uma categoria sensível, planeje pelo menos sete dias corridos entre o primeiro envio e a data de lançamento que você assumiu externamente. Cada ciclo de rejeição leva cerca de 24 horas se você responder rápido. Quatro ciclos de rejeição são um pior caso realista para submissões v1.0 de categoria sensível.

Se sua data de lançamento está assumida externamente (pré-venda configurada, In-App Events agendados, disparo de marketing contratado, jornalistas acionados), sete dias de folga é o mínimo. Dez dias é mais confortável. Qualquer coisa abaixo de sete e você corre o risco de perder a data por uma única rejeição procedimental.

# Padrões que vale a pena entender

Algumas observações de dentro do ciclo que não são óbvias na documentação.

# Cada rejeição encontra coisas diferentes

As quatro rejeições voltaram apontando itens que não se sobrepunham. Todo revisor tinha acesso a todas as telas que o revisor anterior havia liberado. O primeiro revisor apontou um link de EULA nos metadados. O segundo apontou três itens diferentes no mesmo binário (modo em segundo plano, exibição de preço, botão de exclusão). O terceiro apontou um material de marketing. O quarto fez uma pergunta de navegação.

Isso não é um defeito. É uma característica de como a App Review está estruturada. As revisões parecem ser por problema, não por app. Os revisores param no primeiro problema relevante que encontram dentro do orçamento de tempo. Eles não são obrigados a fazer auditorias exaustivas, e o sistema não dá status de “já liberado” às superfícies que um revisor anterior aceitou. A estrutura favorece a vazão institucional em vez da experiência do desenvolvedor.

A implicação: você não consegue extrair uma auditoria completa de nenhuma passagem de revisão. Você só obtém o que o revisor atual conseguir levantar na janela de tempo dele, e precisa aceitar que o próximo revisor pode levantar qualquer outra coisa, de forma independente, na passagem seguinte.

# Cada rejeição tende a ser menor em escopo do que a anterior

É um padrão frouxo, não uma garantia. A primeira rejeição costuma ser substantiva (um requisito faltando, um problema de arquitetura). A segunda ainda é substantiva, mas com mais cara de checklist. A terceira tende a periféricos de metadados. A quarta às vezes é uma pergunta procedimental, e nem chega a ser uma rejeição.

O motivo não é que o app está “melhorando” a cada passagem. O motivo é que a superfície revisável do binário e dos metadados encolhe a cada passagem, conforme os itens já apontados são corrigidos e os já liberados saem do escopo. Os revisores estão esgotando a superfície disponível do checklist de forma independente, o que significa que as revisões posteriores têm menos a encontrar.

Esse padrão é reconfortante enquanto você está no ciclo, mas não conte com ele. Um revisor tardio ainda pode levantar um item substantivo que os anteriores deixaram passar.

# O rigor dos revisores varia muito

Em quatro revisões do mesmo binário, a variação no que cada revisor encontrou foi grande. Um encontrou três itens. Outro encontrou um item periférico. Um terceiro fez uma pergunta que se respondia tocando em um cartão na segunda aba do app.

Você não tem influência sobre qual revisor recebe a sua submissão em cada passagem. Planeje contando com a variação. Não assuma que a próxima passagem será mais rigorosa ou mais tolerante que a anterior. São amostras independentes de uma distribuição ampla.

# Aprovação na Beta App Review não prevê aprovação na App Review completa

As duas esteiras têm times e critérios diferentes. Uma build que passa na Beta com os mesmos recursos que são apontados na revisão de produção não é uma contradição. São dois processos de revisão diferentes.

Se você usa o TestFlight para confirmar que está pronto para o revisor de produção, está usando a ferramenta para o sinal errado. O TestFlight pega problemas de validade da build e de conformidade básica. A App Review de produção pega toda a superfície de aplicação. As duas não são intercambiáveis.

# Os vetores de fiscalização de categorias sensíveis se acumulam

Assinaturas, sobretudo com preço introdutório ou ofertas de teste, disparam automaticamente a aplicação da 3.1.2. Categorias ligadas à saúde (álcool, fitness, saúde mental, sono) atraem a atenção do revisor para questões de alegação médica na 1.4.1. Recursos sensíveis à privacidade (localização, HealthKit, identificadores anônimos) disparam o escrutínio da 5.1.1. Submissões de primeira versão v1.0 disparam revisões abrangentes. In-App Events amarrados a datas de lançamento disparam o escrutínio dos metadados.

Cada vetor, isoladamente, é gerenciável. Juntos, eles se multiplicam. Um lançamento sério em categoria sensível, com assinaturas, múltiplas plataformas e um In-App Event, tem todos os vetores ativos ao mesmo tempo. Um utilitário gratuito de uma tela só, sem compras, passa em 2 minutos. A dificuldade da sua experiência de revisão está correlacionada com a seriedade e a amplitude do seu lançamento, não com a qualidade do seu app.

# Documentação e fiscalização nem sempre batem perfeitamente

Uma rejeição pode citar uma orientação que não aparece explicitamente na página pública vinculada. Os revisores trabalham com material de treinamento interno que se sobrepõe às Review Guidelines públicas, mas não é idêntico a elas. Se você encontrar uma rejeição que não bate com a documentação pública, pode contestar educadamente. Às vezes isso é revertido, às vezes não.

Quando contestar, faça por escrito no Resolution Center, em um parágrafo estruturado que cite a orientação pública e pergunte qual cláusula específica está sendo aplicada. Evite frustração na linguagem. O revisor está lendo a resposta com o tempo contado; a resposta que é lida com atenção é a que respeita esse tempo.

# Como responder às rejeições de forma construtiva

Algumas notas práticas sobre o vai e vem no Resolution Center.

# Responda no mesmo dia, se puder

O jeito mais rápido de sair do ciclo é manter o ciclo andando. O relógio de cada ciclo de rejeição reinicia quando você responde. Respostas no mesmo dia produzem resolução na mesma semana; respostas que levam dias esticam o ciclo na mesma proporção.

Isso exige que seu time esteja estruturado para entregar correções rápido. Para um desenvolvedor indie, isso costuma significar limpar a agenda nos dias seguintes ao envio. A janela de submissão não pode ser tratada como trabalho de segundo plano.

# Junte suas correções em um único reenvio

Se uma rejeição aponta três itens, corrija os três antes de reenviar. Não mande uma resposta do tipo “corrigi dois de três, trabalhando no terceiro”. O próximo revisor vai levantar itens completamente diferentes; a resposta com correção parcial só acrescenta mais um ciclo à fila.

# Inclua gravações de tela verificando as correções

Para qualquer correção não trivial, anexe uma gravação de tela de 30 segundos mostrando a correção em ação. O fluxo de exclusão, a exibição de preço corrigida, o novo caminho de navegação. O revisor tem mais chance de liberar o item na passagem seguinte se conseguir ver a correção sem precisar navegar até ela.

# Peça uma revisão abrangente na sua resposta

Um pedido educado para que quaisquer preocupações restantes sejam levantadas juntas na passagem atual, em vez de espalhadas por ciclos adicionais, é razoável. Nem sempre funciona, mas de vez em quando funciona. A formulação importa: “Tratamos de todos os pontos levantados até aqui com rapidez e boa-fé. Agradeceríamos uma revisão abrangente contra todas as diretrizes aplicáveis nesta passagem, para minimizar ciclos adicionais.”

Isso coloca o revisor em uma posição em que a próxima resposta dele ou libera o app, ou levanta todas as preocupações restantes. Os dois desfechos são melhores do que mais uma rejeição de item único.

# Trate cada passagem como independente

A tentação é assumir que o próximo revisor leu as anotações do anterior. Provavelmente não leu. Cada resposta no Resolution Center deve ser autocontida, resumindo o estado da submissão para alguém que não viu a conversa anterior.

Isso significa que uma pequena dose de repetição entre ciclos é necessária. As App Review Notes detalhadas que funcionaram com o primeiro revisor devem ser reanexadas ou reescritas para o terceiro. Não conte com memória institucional.

# A cronologia pessoal

Para contexto, aqui está como foram de fato os cinco dias.

Enviei a build 22 em um sábado à tarde. A submissão incluía 4 assinaturas com renovação automática, 2 compras vitalícias não consumíveis, 5 itens consumíveis de Tip Jar, descrição do app, capturas de tela, vídeos de App Preview, um In-App Event amarrado à semana de lançamento e pré-venda configurada para a data de lançamento em 175 países.

Eu tinha passado as seis semanas anteriores eliminando sistematicamente todo problema que conseguia antecipar. As App Review Notes foram redigidas com explicações amigáveis ao revisor sobre as partes do app com mais chance de atrair escrutínio. As informações de comerciante do DSA tinham sido aprovadas uma semana antes. Os rótulos de privacidade do app estavam no ar. A Beta App Review já tinha liberado várias builds. Eu me sentia pronto.

Dia 2, 5h15: primeira rejeição. Guideline 3.1.2©. Falta de um link funcional para os Termos de Uso nos metadados da App Store. Correção enviada no mesmo dia (link dos Termos adicionado ao painel de upgrade dentro do app, página de termos expandida para divulgar todos os produtos pagos, descrição do app atualizada). Ciclo de um dia.

Dia 4, 16h03: segunda rejeição. Três itens em uma mensagem só. Guideline 2.5.4 (entrada vestigial “location” em UIBackgroundModes, que não deveria estar lá). Guideline 3.1.2© (preço introdutório exibido com mais destaque que o valor cobrado). Guideline 5.1.1(v) (desligar a chave do identificador anônimo precisava de um botão de exclusão explícito e rotulado). Correção enviada no mesmo dia (entrada do Info.plist removida, hierarquia de preços invertida, botão explícito “Excluir dados anônimos” adicionado com alerta de confirmação). Ciclo de um dia.

Dia 5, 17h05: terceira rejeição. Guideline 2.3.4 Accurate Metadata. Os vídeos de App Preview mostravam mockups de celular em 3D demonstrando as telas do app. A nota do revisor citava conteúdo que não “mostra suficientemente o app em uso” e apontava especificamente as molduras de aparelho.

O problema: a página pública de orientação em developer.apple.com/app-store/app-previews/ não proíbe explicitamente molduras de aparelho. A regra documentada mais próxima é “fique dentro do app”, com exemplos sobre tomadas por cima do ombro e interação física com aparelhos. Nenhuma se aplicava.

Com o lançamento a quatro dias e um atraso acumulado de quatro dias já contabilizado, fiz a troca. Removi os vídeos de App Preview para destravar o reenvio. Pedi reconsideração educadamente, caso houvesse uma cláusula específica que eu tivesse deixado passar. Mandei um parágrafo educado e estruturado pedindo que quaisquer preocupações restantes fossem levantadas juntas nessa passagem. A remoção do App Preview foi mantida. O pedido de reconsideração não recebeu resposta direta.

Dia 6, 19h23: quarta mensagem. Guideline 2.1(b) Information Needed. Tecnicamente não era uma rejeição. Era uma pausa na revisão para fazer uma pergunta. O revisor não conseguia localizar duas das compras anexadas à versão e perguntou onde encontrá-las.

A captura de tela que ele anexou mostrava o primeiro paywall corretamente. O segundo paywall estava na mesma tela de Ajustes, acessível ao tocar em um cartão logo abaixo do cartão até o qual o revisor tinha navegado com sucesso. Respondi com a navegação passo a passo explícita para todas as 11 compras, enviada em menos de uma hora.

Dia 7, 20h30: aprovação. Build liberada. Pré-venda ativada. Semana de lançamento marcada para 11 de maio.

Os cinco dias foram intensos. Nenhum deles era existencial, em retrospecto, ainda que não parecesse assim no meio do ciclo. O atraso acumulado quase custou a data de lançamento, mas não custou. O produto lançado é exatamente o que foi construído antes do envio. Nada foi cortado, alterado ou adiado para passar na revisão.

# O que o ciclo não aponta também informa

Ao longo de quatro revisões, as superfícies com que eu mais tinha me preocupado nunca foram apontadas.

O recurso de pontuação de hábito (uma nota de 0 a 100 com fatores que ajudam e que prejudicam, distribuídos em seis pilares ponderados). A superfície de acompanhamento de medicação (só registro, sem nenhuma saída de aconselhamento). O modelo de privacidade (sem contas, dados no dispositivo, compartilhamento anônimo opcional com exclusão explícita). As gravações no HealthKit. Nenhuma dessas superfícies, as partes do app com mais chance de disparar preocupações de alegação de saúde ou de privacidade, foi apontada em nenhuma das quatro revisões. Quatro revisores independentes olharam, e todos escolheram não apontá-las.

A implicação para quem constrói em categorias sensíveis: o trabalho de divulgação proativa faz diferença. As App Review Notes que explicam a metodologia, os avisos dentro do app, as escolhas cuidadosas de nomenclatura, o enquadramento conservador na descrição do app. Nada disso é glamouroso. Tudo isso contribuiu para que quatro revisores seguidos escolhessem não apontar as superfícies mais discutíveis. A classificação 18+, o painel de aviso na primeira abertura, o texto explícito de “não fornecemos aconselhamento médico” nas áreas relevantes. Tudo isso funcionou.

O que foi apontado, em vez disso, foi a superfície procedimental e mecânica. Hierarquia da exibição de preços. Declarações de modo em segundo plano. Presença de link nos metadados. Composição do material de marketing. Descoberta das compras. As partes substantivas do app passaram em todas as passagens.

# Notas finais para desenvolvedores indie

Algumas observações que não encaixaram direito acima.

Os apps baratinhos que você vê na App Store não estão recebendo tratamento mais tolerante. Eles foram aprovados anos atrás, quando o padrão era mais baixo, ou não disparam os vetores de escrutínio que o seu lançamento sério dispara. O sistema recompensa apps de baixo esforço e baixo risco com pouco escrutínio. Seu esforço e seu cuidado são parte do motivo pelo qual a sua revisão é mais difícil. Não é um comentário sobre a qualidade do seu app.

O sistema não tem estrutura para dar a você a experiência que você quer. A App Review é um pool de terceirizados. Os revisores lidam com dezenas de apps por dia, com minutos por app. Eles são treinados nas Review Guidelines como checklist, não na UX específica de nenhum app individual. A distância de empatia é estrutural, não pessoal.

Documentar experiências indie acaba movendo as coisas. A Apple melhorou a App Review de forma significativa na última década. Parte dessa melhora vem de desenvolvedores indie documentando consistentemente suas experiências, com a pressão agregada crescendo. A sua rejeição individual não vai fazer nenhum revisor específico ser retreinado. O conjunto estruturado das experiências indie acaba, sim, movendo a superfície institucional.

Você provavelmente vai lançar o produto que construiu. Todo recurso que eu temia que fosse cortado foi lançado intacto. O ciclo de quatro rejeições parecia existencial enquanto acontecia. O resultado real convergiu para a aprovação, desde que eu continuasse respondendo com clareza e mantivesse a folga do prazo de lançamento no bolso de trás.

Se você está no meio do ciclo agora, virando noites no Resolution Center: o lançamento acontece. Continue respondendo. O sistema não é pessoal. O produto é seu.

Este post documenta o lançamento do AlcoLog, um app iOS para registrar bebidas. O AlcoLog chega à App Store em 11 de maio de 2026, depois do ciclo descrito acima. O app é gratuito, com níveis Premium opcionais, e já está disponível para pré-venda em 175 países.

Se você é desenvolvedor iOS e quer trocar notas sobre experiências com a App Review, a comunidade indie de iOS no r/iOSProgramming e o Indie Hackers são bons lugares para começar. Quanto mais especificamente cada um de nós documentar o que encontrou, mais útil o conjunto fica para a próxima pessoa.