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

Original Article ↗ Hacker News Discussion ↗

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.