Nota, agosto de 2026: este texto é de um lançamento anterior e descreve a estrutura de escalões da altura. O AlcoLog fundiu o escalão Pro no Premium na v1.2.0, por isso existe agora um único escalão pago. Nada se perdeu na fusão, e quem tinha Pro passou para Premium sem custo adicional.

Se estás prestes a lançar uma aplicação iOS v1.0 com subscrições, compras dentro da aplicação, um companheiro para o Watch, widgets, ou qualquer tipo de posicionamento adjacente à saúde, o processo da App Review vai ser mais duro do que a documentação sugere. Este texto é o relato de um ciclo de lançamento (quatro rejeições ao longo de cinco dias, cinco revisores, um único binário) e dos padrões que tornaram o ciclo suportável. Partilho-o porque a experiência é uma das partes menos documentadas de lançar uma aplicação independente a sério, e a versão documentada (sessões da WWDC, a página das Review Guidelines, os fóruns de programadores) não corresponde à realidade do dia a dia.

Se estás a meio do ciclo e à procura de correções táticas, salta diretamente para “O que corrigir antes de submeteres” e “Padrões que vale a pena perceber”. A cronologia pessoal está na segunda metade, se quiseres contexto.

# O que corrigir antes de submeteres

Estes são os pontos que surgiram nas quatro rejeições. Se os corrigires à partida, eliminas o grosso da superfície de rejeição de uma v1.0 de categoria sensível com subscrições.

# Hierarquia de apresentação de preços nas barreiras de subscrição

As Human Interface Guidelines da Apple para subscrições são inequívocas quanto à apresentação de preços. O valor cobrado tem de ser o elemento de preço mais proeminente. O instinto de marketing (fazer com que o desconto pareça o prémio) é o instinto errado aqui. O instinto de conformidade (fazer do valor cobrado o herói tipográfico) é o certo.

O que isto quer dizer na prática: o preço normal deve ser o elemento maior e mais pesado. O preço introdutório ou de desconto deve ser mais pequeno, com um rótulo explícito de “Primeiro período:”. Evita distintivos de percentagem em marcadores pequenos (usa “OFERTA DE LANÇAMENTO” e não “25 % DE DESCONTO”). A aplicação do ponto 3.1.2©, Payments and Subscriptions, é consistente entre revisores.

# Caminho explícito para eliminar dados

Mesmo quando a tua “conta” é apenas um identificador anónimo opcional, o ponto 5.1.1(v) da Apple exige um caminho de eliminação rotulado, visível e imediato. Desligar um interruptor como eliminação implícita parece conforme do lado do programador, mas não satisfaz a fiscalização atual.

Integra um botão explícito “Eliminar os meus dados” no ecrã de privacidade ou de definições desde a primeira compilação. Acrescenta um alerta de confirmação. Garante que o texto à volta descreve o comportamento real da eliminação, e não um prazo de fachada que tencionas rever mais tarde.

# Audita o Info.plist à procura de declarações vestigiais

Modos de segundo plano, obtenção em segundo plano, permissões de localização, declarações de HealthKit e entradas semelhantes do Info.plist podem ficar por usar durante meses enquanto a base de código evolui. São assinalados quando não correspondem a uma funcionalidade real. A aplicação do ponto 2.5.4, Software Requirements, é aqui mecânica e inequívoca.

Em concreto: qualquer entrada em UIBackgroundModes precisa de corresponder a uma funcionalidade que a use de facto. Se a tua aplicação declara “location” como modo de segundo plano mas nunca usas localização contínua em segundo plano e tens allowsBackgroundLocationUpdates = false, remove a declaração. A monitorização de regiões não a exige. A auditoria leva dez minutos e evita um ciclo de rejeição.

# Ligação funcional aos Termos de Utilização nos metadados da App Store

O campo Política de Privacidade na App Store Connect é bem conhecido. O requisito dos Termos de Utilização é menos conhecido. Se estás a usar o EULA padrão da Apple, inclui uma ligação aos Termos de Utilização na descrição da aplicação. Se estás a usar um EULA personalizado, acrescenta-o no campo próprio da App Store Connect.

A própria página de termos deve divulgar todos os produtos pagos, com duração da subscrição, preço e mecânica de renovação. A maioria das equipas tem estes elementos espalhados por páginas separadas ou enterrados na política de privacidade. Consolida-os numa página de termos que o revisor consiga ler em dois minutos.

# Vídeos de App Preview: usa capturas de ecrã em bruto

Maquetas de telemóvel em 3D, molduras de dispositivo e composições de marketing estilizadas são decisões à discrição do revisor ao abrigo do ponto 2.3.4, Accurate Metadata. A página pública de orientações não proíbe explicitamente as molduras de dispositivo, mas o material de formação interna com que os revisores trabalham parece proibi-las. Capturas de ecrã simples, na resolução nativa, são inequivocamente seguras.

Guarda o embrulho de marketing para o teu próprio site, para as redes sociais e para o Reddit. Põe capturas de ecrã no espaço do App Preview. A diferença de conversão entre “pré-visualização com maqueta polida” e “pré-visualização com gravação de ecrã em bruto” é pequena. A redução de risco é grande.

Os revisores trabalham com orçamentos de tempo de 5 a 15 minutos por aplicação. Nem sempre vão encontrar todas as compras dentro da aplicação associadas à versão. Se as tuas compras forem alcançáveis por caminhos diferentes (barreiras separadas, cartões separados, navegação mais funda), inclui migalhas de navegação, clique a clique, para cada uma delas nas tuas App Review Notes.

Um formato que funciona:

Subscrições Premium e compra Lifetime: separador Definições > cartão Premium > botão Obter Premium > folha de upgrade Premium Subscrições Pro e compra Lifetime: separador Definições > cartão Pro > botão Obter Pro Itens consumíveis do Tip Jar: separador Definições > passa os cartões de escalão > cartão Tip Jar > Mostrar opções de gorjeta

Isto parece excessivo. Evita um ciclo de rejeição concreto (guideline 2.1(b), Information Needed) que de outro modo te custa um dia.

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

Para uma submissão v1.0 com subscrições numa categoria sensível, conta com pelo menos sete dias de calendário entre a primeira submissão e a data de lançamento que assumiste publicamente. Cada ciclo de rejeição demora cerca de 24 horas se responderes depressa. Quatro ciclos de rejeição são um pior caso realista para submissões v1.0 de categoria sensível.

Se a tua data de lançamento está assumida externamente (pré-encomenda configurada, In-App Events agendados, rajada de marketing marcada, jornalistas contactados), sete dias de folga são o mínimo. Dez são mais confortáveis. Abaixo de sete arriscas falhar a data por causa de uma única rejeição processual.

# Padrões que vale a pena perceber

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

# Cada rejeição encontra coisas diferentes

As quatro rejeições vieram a assinalar pontos que não se sobrepunham. Todos os revisores tiveram acesso a todos os ecrãs que o revisor anterior tinha aprovado. O primeiro assinalou uma ligação de EULA nos metadados. O segundo assinalou três pontos diferentes no mesmo binário (modo de segundo plano, apresentação de preços, botão de eliminação). O terceiro assinalou um material de marketing. O quarto fez uma pergunta de navegação.

Isto não é um defeito. É uma característica de como a App Review está estruturada. As revisões parecem ser por problema, não por aplicação. Os revisores param no primeiro problema de vulto que apanham dentro do seu orçamento de tempo. Não são obrigados a fazer auditorias exaustivas, e o sistema não atribui um estado de “já aprovado” às superfícies que um revisor anterior aceitou. A estrutura favorece o débito institucional em detrimento da experiência do programador.

A implicação: não consegues extrair uma auditoria completa de nenhuma passagem única de revisão. Só consegues aquilo que o revisor atual trouxer à superfície na sua janela de tempo, e tens de aceitar que o revisor seguinte pode trazer à superfície qualquer outra coisa, de forma independente, na passagem seguinte.

# Cada rejeição tende a ser de menor alcance do que a anterior

Um padrão vago, não uma garantia. A primeira rejeição é muitas vezes substantiva (um requisito em falta, um problema de arquitetura). A segunda ainda é substantiva mas com mais forma de lista de verificação. A terceira deriva para metadados periféricos. A quarta é às vezes uma pergunta processual e não sequer uma rejeição.

A razão não é a aplicação estar a “ficar melhor” a cada passagem. A razão é que a superfície revisível no binário e nos metadados encolhe a cada passagem, à medida que os pontos já assinalados são corrigidos e os pontos já aprovados saem do âmbito. Os revisores esgotam de forma independente a superfície disponível da lista de verificação, o que significa que as revisões posteriores têm menos para encontrar.

Este padrão é reconfortante enquanto estás no ciclo, mas não contes com ele. Um revisor tardio pode ainda assim trazer à superfície um ponto substantivo que os anteriores deixaram passar.

# O rigor dos revisores varia muitíssimo

Ao longo de quatro revisões do mesmo binário, a variação naquilo que cada revisor encontrou foi substancial. Um encontrou três pontos. Outro encontrou um ponto periférico. Um terceiro fez uma pergunta que se respondia tocando num cartão do segundo separador da aplicação.

Não tens influência nenhuma sobre que revisor recebe a tua submissão em cada passagem. Planeia para a variação. Não assumas que a passagem seguinte vai ser mais rigorosa ou mais branda do que a anterior. São amostras independentes de uma distribuição larga.

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

Os dois circuitos têm equipas diferentes e critérios diferentes. Uma compilação que passa na Beta com as mesmas funcionalidades que são assinaladas na revisão de produção não é uma contradição. São dois processos de revisão diferentes.

Se estás a usar o TestFlight para confirmar que estás pronto para o revisor de produção, estás a usá-lo para o sinal errado. O TestFlight apanha problemas de validade da compilação e de conformidade básica. A App Review de produção apanha toda a superfície de fiscalização. Não são intercambiáveis.

# Os vetores de fiscalização de categoria sensível acumulam-se

As subscrições, sobretudo com preços introdutórios ou ofertas de experimentação, ativam automaticamente a fiscalização do ponto 3.1.2. As categorias adjacentes à saúde (álcool, exercício físico, saúde mental, sono) chamam a atenção do revisor para as preocupações com alegações médicas do ponto 1.4.1. As funcionalidades sensíveis à privacidade (localização, HealthKit, identificadores anónimos) ativam o escrutínio do ponto 5.1.1. As submissões de primeira versão v1.0 ativam revisões abrangentes. Os In-App Events ligados a datas de lançamento ativam o escrutínio dos metadados.

Cada vetor, isoladamente, é gerível. Acumulam-se de forma multiplicativa. Um lançamento a sério numa categoria sensível, com subscrições, várias plataformas e um In-App Event, tem todos os vetores ativos ao mesmo tempo. Um utilitário gratuito de um único ecrã, sem compras dentro da aplicação, passa em 2 minutos. A dificuldade da tua experiência de revisão está correlacionada com a seriedade e a amplitude do teu lançamento, não com a qualidade da tua aplicação.

# A documentação e a fiscalização nem sempre coincidem

Uma rejeição pode citar orientações que não aparecem explicitamente na página pública ligada. Os revisores trabalham a partir de material de formação interno que se sobrepõe às Review Guidelines públicas sem ser idêntico a elas. Se encontrares uma rejeição que não corresponde à documentação pública, podes contestar com educação. Às vezes isso é revertido, às vezes não.

Quando contestares, fá-lo por escrito no Resolution Center, num parágrafo estruturado que cite a orientação pública e peça a cláusula concreta que está a ser aplicada. Evita a frustração na linguagem. O revisor está a ler a resposta com um orçamento de tempo; a resposta que é lida com atenção é a que respeita esse orçamento.

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

Algumas notas práticas sobre o vaivém no Resolution Center.

# Responde no próprio dia, se conseguires

A forma mais rápida de sair do ciclo é manter o ciclo em andamento. O relógio de cada ciclo de rejeição reinicia quando respondes. Respostas no próprio dia produzem resolução na mesma semana; respostas de vários dias esticam o ciclo na mesma proporção.

Isto exige que a tua equipa esteja estruturada para lançar correções depressa. Para um programador independente, isto significa muitas vezes limpar o calendário nos dias a seguir à submissão. A janela de submissão não pode ser tratada como trabalho de fundo.

# Junta as tuas correções numa só ressubmissão

Se uma rejeição assinala três pontos, corrige os três antes de voltares a submeter. Não mandes uma resposta do tipo “corrigi dois de três, estou a trabalhar no terceiro”. O revisor seguinte vai trazer à superfície pontos completamente diferentes; a resposta com correção parcial só acrescenta mais um ciclo à fila.

# Inclui gravações de ecrã a verificar a correção

Para qualquer correção não trivial, anexa uma gravação de ecrã de 30 segundos a mostrar a correção em ação. O fluxo de eliminação, a apresentação de preços corrigida, o novo caminho de navegação. O revisor tem mais probabilidade de dar o ponto por resolvido na passagem seguinte se conseguir ver a correção sem ter de lá navegar sozinho.

# Pede uma revisão abrangente na tua resposta

Um pedido educado para que quaisquer preocupações restantes sejam levantadas em conjunto na passagem atual, em vez de espalhadas por ciclos adicionais, é razoável. Nem sempre resulta, mas ocasionalmente resulta. A formulação conta: “Tratámos de todos os problemas levantados até agora com prontidão e boa-fé. Agradecíamos uma revisão abrangente face a todas as orientações aplicáveis nesta passagem, para minimizar ciclos adicionais.”

Isto põe o revisor numa posição em que a resposta seguinte ou aprova a aplicação, ou traz à superfície todas as preocupações restantes. Ambos os desfechos são melhores do que mais uma rejeição de um só ponto.

# Trata cada passagem como independente

A tentação é assumir que o revisor seguinte leu as notas do anterior. Provavelmente não leu. Cada resposta no Resolution Center deve ser autónoma, a resumir o estado da submissão para alguém que não viu a conversa anterior.

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

# A cronologia pessoal

Para contexto, foi isto que aconteceu nos cinco dias.

Submeti a compilação 22 num sábado à tarde. A submissão incluía 4 subscrições de renovação automática, 2 compras Lifetime não consumíveis, 5 itens consumíveis do Tip Jar, descrição da aplicação, capturas de ecrã, vídeos de App Preview, um In-App Event ligado à semana de lançamento e pré-encomenda configurada para a data de lançamento em 175 países.

Tinha passado as seis semanas anteriores a eliminar sistematicamente todos os problemas que conseguia antecipar. As App Review Notes foram redigidas com explicações amigáveis para o revisor sobre as partes da aplicação com mais probabilidade de atrair escrutínio. A informação de comerciante do DSA tinha sido aprovada uma semana antes. Os rótulos nutricionais de privacidade estavam publicados. A Beta App Review tinha aprovado várias compilações. Sentia-me pronto.

Dia 2, 5h15: primeira rejeição. Guideline 3.1.2©. Falta de ligação funcional aos Termos de Utilização nos metadados da App Store. Correção lançada no próprio dia (ligação aos Termos acrescentada à folha de upgrade dentro da aplicação, página de termos alargada para divulgar todos os produtos pagos, descrição da aplicação atualizada). Ciclo de um dia.

Dia 4, 16h03: segunda rejeição. Três pontos numa só mensagem. Guideline 2.5.4 (entrada vestigial “location” em UIBackgroundModes, que não devia lá estar). Guideline 3.1.2© (preço introdutório apresentado com mais destaque do que o valor cobrado). Guideline 5.1.1(v) (o interruptor de desligar o identificador anónimo precisava de um botão de eliminação explícito e rotulado). Correção lançada no próprio dia (entrada do Info.plist removida, hierarquia de preços invertida, botão explícito “Eliminar dados anónimos” 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 maquetas de telemóvel em 3D a demonstrar os ecrãs da aplicação. A nota do revisor citava conteúdo que não mostra “suficientemente a aplicação em uso” e apontava especificamente as molduras de dispositivo.

O desafio: a página pública de orientações em developer.apple.com/app-store/app-previews/ não proíbe explicitamente as molduras de dispositivo. A regra documentada mais próxima é “Stay within the app”, com exemplos sobre planos por cima do ombro e interação física com dispositivos. Nenhuma se aplicava.

Com o lançamento a quatro dias e um atraso acumulado de quatro dias já sofrido, fiz a troca. Removi os vídeos de App Preview para desbloquear a ressubmissão. Pedi reconsideração com educação, caso houvesse uma cláusula concreta que me tivesse escapado. Enviei um parágrafo educado e estruturado a pedir que quaisquer preocupações restantes fossem levantadas em conjunto nesta passagem. A remoção do App Preview manteve-se. O pedido de reconsideração não teve resposta direta.

Dia 6, 19h23: quarta mensagem. Guideline 2.1(b), Information Needed. Tecnicamente, não é uma rejeição. É uma pausa na revisão para fazer uma pergunta. O revisor não conseguia localizar duas das compras dentro da aplicação associadas à versão e perguntou onde as encontrar.

A captura de ecrã que anexou mostrava a primeira barreira de pagamento corretamente. A segunda barreira estava no mesmo ecrã de Definições, acessível ao tocar num cartão logo abaixo do cartão até ao qual o revisor tinha navegado com sucesso. Respondi com navegação explícita, passo a passo, para todas as 11 compras dentro da aplicação, e enviei em menos de uma hora.

Dia 7, 20h30: aprovação. Compilação aprovada. Pré-encomenda ativada. Semana de lançamento marcada para 11 de maio.

Os cinco dias foram intensos. Nenhum deles foi existencial, olhando para trás, ainda que não parecesse isso a meio do ciclo. O atraso acumulado quase custou a data de lançamento, mas não custou. O produto que foi lançado é exatamente o que estava construído antes da submissão. Nada foi cortado, alterado ou adiado para passar na revisão.

# O que o ciclo não assinala também é informativo

Ao longo de quatro revisões, as superfícies com que eu mais tempo tinha perdido a preocupar-me nunca foram assinaladas.

A funcionalidade de pontuação de hábitos (uma pontuação de 0 a 100 com fatores que ajudam e prejudicam, ao longo de seis pilares ponderados). A superfície de registo de medicação (só registo, sem qualquer saída de aconselhamento). O modelo de privacidade (sem contas, dados no dispositivo, partilha anónima opcional com eliminação explícita). As escritas para o HealthKit. Nenhuma destas superfícies, as partes da aplicação com mais probabilidade de levantar preocupações de alegação de saúde ou de privacidade, foi assinalada em qualquer das quatro revisões. Quatro revisores independentes olharam todos, e todos escolheram não as assinalar.

A implicação para quem constrói em categorias sensíveis: o trabalho de divulgação proativa conta. As App Review Notes que explicam a metodologia, os avisos dentro da aplicação, as escolhas cuidadas de nomes, o enquadramento conservador na descrição. Nada disso é glamoroso. Tudo isso contribuiu para que quatro revisores seguidos escolhessem não assinalar as superfícies mais discutíveis. A classificação de 18+, a folha de aviso legal logo no primeiro arranque, o texto explícito de “não prestamos aconselhamento médico” nas áreas relevantes. Tudo isso resultou.

O que foi assinalado, em vez disso, foi a superfície processual e mecânica. A hierarquia de apresentação de preços. As declarações de modo de segundo plano. A presença de ligações nos metadados. As composições dos materiais de marketing. A facilidade de encontrar as compras dentro da aplicação. As partes substantivas da aplicação passaram em todas as passagens.

# Notas finais para programadores independentes

Algumas observações que não encaixavam bem acima.

As aplicações baratas que vês na App Store não estão a receber tratamento mais brando. Foram aprovadas há anos, quando os padrões eram mais baixos, ou não ativam os vetores de escrutínio que o teu lançamento a sério ativa. O sistema recompensa aplicações de pouco esforço e pouco risco com pouco escrutínio. O teu esforço e o teu cuidado são parte da razão pela qual a tua revisão é mais difícil. Não é um comentário à qualidade da tua aplicação.

O sistema não está dimensionado para te dar a experiência que queres. A App Review é um conjunto de prestadores externos. Os revisores tratam de dezenas de aplicações por dia, a minutos por aplicação. São formados nas Review Guidelines como lista de verificação, não na experiência de utilização concreta de nenhuma aplicação em particular. A distância de empatia é estrutural, não pessoal.

Documentar experiências independentes acaba por mover as coisas. A Apple melhorou a App Review de forma significativa na última década. Parte dessa melhoria vem de programadores independentes a documentarem as suas experiências com consistência e da pressão agregada a acumular-se. A tua rejeição individual não vai levar a que nenhum revisor concreto seja reformado. O agregado estruturado das experiências independentes acaba por mover a superfície institucional.

Provavelmente vais lançar o produto que construíste. Todas as funcionalidades que temi que fossem cortadas foram lançadas intactas. O ciclo de quatro rejeições parecia existencial enquanto estava a acontecer. O desfecho real convergiu para a aprovação, desde que eu continuasse a responder com clareza e mantivesse a folga do prazo de lançamento no bolso.

Se estás a meio do ciclo agora mesmo, a fazer noitadas no Resolution Center: o lançamento acontece. Continua a responder. O sistema não é pessoal. O produto é teu.

Este texto documenta o lançamento do AlcoLog, uma aplicação iOS de registo de bebidas. O AlcoLog é lançado na App Store a 11 de maio de 2026, depois do ciclo descrito acima. A aplicação é gratuita com escalões Premium opcionais e está disponível para pré-encomenda em 175 países.

Se és programador iOS e queres comparar notas sobre experiências na App Review, a comunidade indie-iOS no r/iOSProgramming e o Indie Hackers são bons sítios por onde começar. Quanto mais especificamente cada um de nós documentar o que encontrou, mais útil se torna o agregado para a pessoa a seguir.