Apple rejeita o app de astronomia Dark Hours por «astrologia» - duas vezes

A Apple rejeitou o Dark Hours, um app de astronomia para observar objetos celestes, sob o argumento de que ele «diz respeito à astrologia» - e, quando o desenvolvedor Terry Godier recorreu, o App Review Board da Apple manteve a rejeição alegando que o app «inclui uma função de leitura de tarô ao vivo», segundo os relatos publicados em 7 de agosto de 2026 pelo Daring Fireball e pelo desenvolvedor Michael Tsai. O caso importa para além de um único app: é um exemplo documentado da mais alta instância de escalonamento de revisão da Apple ratificando uma rejeição factualmente errada.

O que aconteceu

O Dark Hours é um app de astronomia criado por Terry Godier, com um design nativo de iOS que usa a interface Liquid Glass da Apple, segundo o post de John Gruber no Daring Fireball. A rejeição inicial da App Review da Apple o classificou como astrologia. Godier escalou pelo processo de recurso da Apple até o App Review Board - a última instância para rejeições contestadas - e a resposta do board, citada em ambos os posts, foi: «Entendemos que o app inclui uma função de leitura de tarô ao vivo.»

Godier contesta isso categoricamente. O app «não tem nenhuma função de tarô, nenhum horóscopo e nada que eu, ou qualquer outra pessoa a quem perguntei, associaria à astrologia», disse ele, conforme citado pelo Daring Fireball. A própria avaliação de Gruber depois de examinar o app: «É imediatamente óbvio que ele diz respeito à ciência da astronomia e não tem absolutamente nada a ver com astrologia.»

Por que os desenvolvedores estão prestando atenção

As críticas reunidas na compilação de Michael Tsai vão além do erro individual e miram o sistema que o produziu. Godier argumenta que o processo de revisão é inconsistente nos dois sentidos: aprova apps de baixa qualidade, como invólucros do ChatGPT e jogos sobrecarregados de anúncios excessivos, ao mesmo tempo em que rejeita uma ferramenta científica legítima. A caracterização de Gruber sobre o desfecho do recurso foi mais direta: «Isto é saído diretamente de Kafka.»

O detalhe que torna este caso notável é onde o erro foi ratificado. Erros de revisores individuais são uma constante conhecida no desenvolvimento para a App Store. Aqui, segundo ambos os relatos, o App Review Board - a via de escalonamento que existe justamente para corrigir tais erros - introduziu uma nova alegação incorreta (a função de tarô) em vez de detectar a original.

O que isso significa para os desenvolvedores

Se você publica no iOS, as lições práticas são concretas:

• Não presuma que o App Review Board reexamina o seu app do zero. Neste caso documentado, o board manteve uma classificação errada com uma justificativa que, segundo o desenvolvedor, descreve uma função que não existe. Monte o seu recurso como se tivesse de refutar a rejeição original e antecipar leituras equivocadas adjacentes - deixe claro o que o seu app não é, com capturas de tela.
• A confusão com uma categoria adjacente é um risco real de rejeição. Um app de astronomia foi lido como astrologia. Se o domínio do seu app tem um vizinho superficialmente parecido, mais regulado ou restrito (astronomia/astrologia, educação/jogos próximos de apostas, bem-estar/medicina), trate a distinção explicitamente nas suas notas de revisão antes do primeiro envio.
• A documentação pública movimenta os casos. Ambos os posts saíram em 7 de agosto de 2026 e foram amplamente recolhidos por agregadores para desenvolvedores no mesmo dia. Nenhuma das fontes relata uma reversão por parte da Apple até o momento da redação, mas o padrão histórico que o enquadramento «rejeição da semana» de Gruber sugere - rejeições de grande visibilidade atraindo escrutínio público - é uma alavanca que os desenvolvedores já usaram quando o processo formal falha. Guarde registro de cada troca com a revisão para poder publicar uma cronologia exata, se assim decidir.
• Planeje os cronogramas de lançamento levando em conta o risco de revisão. Um recurso que chega ao App Review Board e fracassa não deixa ao app nenhum caminho para a App Store além do reenvio. Se uma data de lançamento importa, reserve margem para pelo menos um ciclo de rejeição em qualquer categoria onde uma classificação errada como esta seja plausível.

Nem o Daring Fireball nem o post de Tsai relatam qualquer comentário da Apple além das respostas de revisão citadas acima.