Apple fecha arbitrariamente relatórios de bugs se o usuário não confirmar manualmente que eles ainda não foram corrigidos

• A Apple encerra automaticamente bugs reportados pelo Feedback Assistant se o usuário não confirmar (verify) manualmente que “ainda não foram corrigidos”
• No caso do bug de vazamento de privacidade relacionado à extensão de filtro de rede (FB12088655), que ficou 3 anos sem resposta, a Apple de repente exigiu verificação e informou que, sem resposta em 2 semanas, consideraria o problema corrigido
• No entanto, mesmo depois de os desenvolvedores do Little Snitch confirmarem que o mesmo problema continuava presente no macOS mais recente, a Apple fechou o relatório
• Esse procedimento funciona como uma estrutura que reduz artificialmente o número de relatórios de bugs, produzindo o efeito de esconder problemas reais de qualidade
• Como resultado, aponta-se que a forma como a Apple gerencia bugs enfraquece a confiança dos desenvolvedores e prejudica uma cultura colaborativa de feedback

---

Problema de encerramento automático de relatórios de bugs da Apple

• Um desenvolvedor que reportou um bug pelo Apple Feedback Assistant criticou a prática da Apple de fechar relatórios arbitrariamente sem a confirmação do usuário
  • A Apple encerra automaticamente o relatório se o usuário não confirmar manualmente que “o bug ainda não foi corrigido”
  • Depois de anos sem responder, ela subitamente envia um pedido de verificação e, se não houver resposta em 2 semanas, considera o item “corrigido”
• No caso FB12088655 “Privacy: Network filter extension TCP connection and IP address leak”, enviado em março de 2023, a Apple ficou 3 anos sem responder e só em março de 2026 pediu verificação no macOS 26.4 beta 4
  • Como o beta do sistema operacional não estava instalado continuamente, era difícil verificar, e mesmo ao perguntar à Apple se havia sido corrigido, não houve uma resposta clara
  • A Apple informou que, “se não houver verificação em até 2 semanas, consideraremos o problema corrigido e fecharemos o relatório”
  • Os desenvolvedores do Little Snitch relataram que o mesmo problema podia ser reproduzido também no macOS 26.4 beta 4
  • O mesmo bug continuava presente também na versão final do macOS 26.4
• Aponta-se que exigir confirmação direta do usuário para um bug que não foi corrigido é um procedimento ineficiente e irrazoável
  • Menciona-se a possibilidade de existir internamente uma estrutura de incentivos voltada a reduzir o número de relatórios de bugs
  • Com isso, o número de “bugs abertos” diminui, fazendo os indicadores internos parecerem mostrar melhoria de qualidade

Outros casos de relatórios de bugs

• Outro exemplo citado é o bug FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab”
  • Mesmo sendo um problema reproduzível em 100% dos casos, a Apple o marcou como “Investigação concluída - Não foi possível diagnosticar com as informações atuais (Investigation complete - Unable to diagnose with current information)”
  • Em 9 de março, foram solicitadas informações adicionais, mas a Apple não respondeu
• No beta do iPadOS 26.4, surgiu um novo bug de travamento do Safari, e a Apple não o corrigiu antes do lançamento da versão pública
  • O autor criticou dizendo que “parece que o objetivo do beta não é corrigir bugs, mas incomodar quem os reporta”

Mudanças após o Hacker News e resposta da Apple

• Logo depois de este texto chegar à primeira página do Hacker News, a Apple atualizou o relatório FB22057274
  • A Apple pediu o envio de logs sysdiagnose para um problema de UI
  • O autor apontou que já havia fornecido etapas de reprodução e gravação de tela, e que o sysdiagnose é um material desnecessário e com risco de violação de privacidade
• O autor respondeu ao pedido da Apple da seguinte forma
  • “Para um bug de UI, sysdiagnose não é necessário e não ajuda”
  • Como forma de reproduzir o problema sem o Little Snitch, explicou que é possível configurar o perfil de atraso de uplink de 3000ms usando o Network Link Conditioner do Xcode Additional Tools para reproduzir o mesmo comportamento

Guia do Xcode Additional Tools

• O Xcode Additional Tools inclui vários utilitários úteis e pode ser baixado na página Apple Developer Downloads (login necessário)

Avaliação geral

• A forma como a Apple gerencia relatórios de bugs impõe uma carga desnecessária aos desenvolvedores e funciona com uma estrutura mais focada em reduzir o número de relatórios do que em resolver os problemas reais
• Relatórios sem resposta por longos períodos, exigências de verificação irrazoáveis e pedidos ineficientes de informação estão enfraquecendo a confiança e a disposição de colaboração dos desenvolvedores

[GN⁺]

Comentários do Hacker News

• O autor provavelmente nunca teve experiência com software corporativo
  Quando o desenvolvedor recebe um relatório de bug, a tática clássica é enrolar sem fazer nada, dizendo “não consigo reproduzir; você já verificou na versão mais recente?”
  Se não conseguirem confirmar, fecham como “erro do usuário” ou “não reproduzível”
  A única forma de lidar com isso é responder “sim, verifiquei”, mesmo sem ter verificado de fato

  • Já usei suporte pago da Microsoft, e eles sempre exigem envio de evidências
    Se aparecer antivírus no log, eles encerram na hora dizendo “procure o suporte deles”
  • Vendo por dentro, isso parece menos malícia e mais uma questão de eficiência de custo
    Existem muitas prioridades de negócio mais importantes do que um bug relatado por um único usuário
    Ainda assim, do ponto de vista do usuário, é lamentável
  • Em open source é a mesma coisa. O stalebot fecha automaticamente issues antigas
  • Eu aprendi a fazer bem GIFs de reprodução que possam ser colocados direto no e-mail
    A maioria dos desenvolvedores não sabe testar o próprio produto ou não quer ter esse trabalho
  • Já vivi os dois lados
    Quando eu trabalhava com suporte técnico corporativo, precisava receber pelo menos dois casos novos por dia e gerenciava mais de 20 ao mesmo tempo
    A sensação de alívio ao encerrar como “inativo” um caso sem progresso era enorme
    Depois criaram uma regra exigindo três contatos antes de fechar, e isso virou um pesadelo
    No fim, a burocracia de grandes empresas estraga tudo

• A Apple parece adotar uma postura de torcer para que o bug desapareça sozinho
  Eu também já parei de enviar relatórios de bug
  Ser ignorado tudo bem, mas o problema é quando eles me tratam como mão de obra de QA não remunerada
  Exigem um esforço enorme para provar que o bug existe

  • A Microsoft é parecida, especialmente em problemas ligados a Azure ou 365
    A mentalidade é “o software é seu, então você que faça o debug”

• Projetos open source também fazem esse tipo de fechamento automático de issues stale
  Não faz sentido assumir automaticamente que algo foi resolvido só porque passou um certo tempo

  • Do ponto de vista do mantenedor, as prioridades podem ser outras
    A vantagem do open source é que você pode corrigir por conta própria, enviar um PR ou resolver com um fork
  • Em vez de o stalebot fechar, tudo bem se ele apenas aplicar a label stale
    Filtrar tickets antigos é mais razoável

• Do ponto de vista do usuário, isso irrita, mas nem todo bug é facilmente reproduzível
  Às vezes é mais eficiente pedir ao usuário para testar de novo depois de alguma mudança no código relacionada
  Ainda assim, dá um desconforto fechar bugs antigos que continuam sem execução prática

  • No passado eu trabalhava conectando Macs ao ActiveDirectory, e a resposta padrão da Apple era “works on 17!”
    Isso significava apenas que eles não conseguiam reproduzir na rede interna da Apple
  • Também há quem diga “por que não simplesmente deixar aberto?”
    Fechar só serve para esconder o problema, e manter aberto não tem custo
  • A Apple não diz “não reproduzível” nem “corrigido”; apenas manda “verifique no macOS 26.4 beta 4”
    Exigir instalação de beta é muito mais ineficiente para o usuário
    Eu tinha até fornecido um projeto de exemplo do Xcode e os passos de reprodução
    Tenho certeza de que a Apple não fez nada
    Provavelmente estão fazendo um show de limpeza de bugs para preparar o macOS 27 antes da WWDC
  • Uma empresa como a Apple deveria ter ferramentas para capturar perfeitamente o estado do sistema e reproduzir o problema

• Quando trabalhei no Facebook e no Google, vi muitos truques de gestão de bugs
  Depois da introdução de SLA, reduziam artificialmente a prioridade do bug ou empurravam para o usuário com “isso ainda está acontecendo?”
  Quando o tempo passava, fechavam dizendo que “a versão foi descontinuada”
  Às vezes até mesclavam à força com outro bug para escapar da responsabilidade
  No fim, tudo isso acontece por causa dos indicadores de desempenho da organização (SLA)
  Por isso hoje quase não reporto bugs

  • Os engenheiros, na verdade, querem corrigir bugs
    Mas a gerência manda “agora foquem no projeto de IA”
    E ao mesmo tempo reclama que “há bugs demais”
  • Eu também já rebaixei p2/s2 para p3/s3
    Acho mais honesto simplesmente ignorar em vez de fechar
    A liderança induzia esse tipo de triagem forçada
    Bloquear notificações automáticas é um problema
  • A razão para separar prioridade (priority) e severidade (severity) é que, por exemplo, mesmo se o site inteiro cair, talvez isso não seja P0 porque estamos em baixa temporada
    Mas, na prática, a qualidade dos dados é tão ruim que isso não serve para relatórios
    Por isso um único valor de prioridade é mais prático
    O stalebot acaba fechando esses issues ignorados no lugar deles
  • Na grande empresa em que trabalhei também era assim
    Eles gerenciavam separadamente a severity voltada ao cliente e a priority interna
    O Salesforce “Lightning Experience”, apesar do nome, é muito lento
    As ferramentas internas eram muito mais rápidas e eficientes
  • Tudo isso é um caso típico de problema de agência (principal-agent problem)

• Na ElevenLabs aconteceu a mesma coisa
  Ao abrir um relatório de bug, uma IA respondia automaticamente e, após 48 horas, ele era marcado como stale

  • Um funcionário da ElevenLabs apareceu para dizer que, se fosse enviado ao repositório open source no GitHub, uma pessoa responderia diretamente

• Parece que em breve agentes de LLM vão resolver esse tipo de problema
  Eles poderão comentar automaticamente “ainda não foi corrigido” e dar bump automático periodicamente, dizendo “isso afeta um fluxo de trabalho importante”

  • Se o mantenedor fechar a issue, o agente talvez até publique automaticamente um post crítico em blog

• Uma vez enviei um bug para a Microsoft e, meses depois, recebi a resposta “não reproduzível”
  Na verdade, nesse intervalo ele tinha sido resolvido indiretamente por outra correção
  Percebi que eu era como um cego apalpando só parte do elefante

• Sou ex-funcionário da Apple
  O rastreador interno de bugs da Apple se chama Radar, e toda issue precisa passar pela etapa “Verify” para poder ser fechada
  À primeira vista parece um processo de garantia de qualidade, mas na prática inúmeros Radars ficam parados para sempre em Verify
  As equipes são avaliadas pela “quantidade de Radars não verificados”, então depois de algum tempo eles os fecham à força

  • A maioria das equipes usa Verify na prática como se fosse o estado Closed
    A ilusão de “zero bugs” gera métricas de desempenho distorcidas
  • A solução é avaliar também a “quantidade de bugs reabertos”
  • A mensagem do Feedback Assistant de “verifique na beta mais recente” é separada do estado Verify do Radar
    Não dá para concluir que um engenheiro da Apple realmente tentou corrigir

• Na empresa, eu fazia com colegas reuniões de limpeza de backlog
  Organizávamos bugs antigos e pontuais
  Esse tipo de processo é muito comum