Apple randomly closes bug reports unless you "verify" the bug remains unfixed

Original Article ↗ Hacker News Discussion ↗

Apple’s practice of auto-closing long-standing bug reports unless users quickly “verify” the issue on a specific OS beta is criticized as shifting work onto reporters and incentivizing teams to game metrics rather than fix defects. Commenters compare this to similar patterns at big tech companies and open source projects, where stale bots and process rules quietly bury unresolved issues to keep backlogs looking healthy. Many argue this erodes trust, discourages high-quality bug reports, and reflects broader industry priorities that favor shipping features and meeting KPIs over long-term software quality.

Apple’s Bug-Closing Practice

  • Many see Apple’s “please verify on or we’ll close this” as perfunctory cleanup, not real triage.
  • Ex‑employees describe an internal “Verify” state in Apple’s tracker that must be passed before “Closed”; teams are graded on how many items linger there.
  • This leads to mass-closure of unverified issues, sometimes without anyone actually trying the repro steps.

Views on Auto-Closing & “Verification”

  • Defenders: Large products receive more bugs than can be handled. Auto-closing old, inactive or unreproducible reports is framed as necessary “spring cleaning.”
  • Critics: Closing without attempting reproduction or without evidence of a fix is called dishonest and metrics-driven. It trains users to stop reporting.
  • Several note the asymmetry: it is cheap for Apple to test on their own betas, but costly for users to install betas just to check one bug.

Incentives, Metrics, and Culture

  • Many blame corporate KPIs: teams are rewarded for closed tickets, feature delivery, and “bug health” dashboards, not for actual defect reduction.
  • Stories from big tech (Apple, Microsoft, Google, Meta, etc.) describe common tactics: re-down-prioritizing bugs, bouncing them back to reporters, merging into vaguely related tickets, or letting old versions “expire.”
  • Some argue this reflects a profit‑first culture where minor defects are ignored unless they threaten revenue; others lament a drift away from craftsmanship and customer focus.

Impact on Users and Reporters

  • Diligent reporters who provide repro projects, videos, or detailed logs feel punished: their effort is discarded or turned into unpaid QA work.
  • Over time, many stop filing bugs, or respond with perfunctory “still broken” confirmations or even lie to get tickets kept alive.

Comparisons to Other Projects

  • Similar patterns are reported in open source (stalebots closing issues by age), GitHub-hosted tools, and other SaaS companies.
  • Some maintainers defend auto-closing as mental hygiene for small volunteer teams; others say it destroys valuable history and discourages high-quality reports.

Suggested Better Practices

  • Mark stale issues but don’t auto-close; or close with explicit “won’t fix” / “can’t reproduce” plus reasoning.
  • Maintain separate statuses for “never triaged,” “known but not planned,” etc.
  • Invest in better repro, logging, and automated triage, potentially with AI, and reserve auto-stale for genuinely low-signal reports.