Johnson documents multiple instances of bugs he reported years ago that remain clearly reproducible, yet Apple's Feedback Assistant marks them as resolved because he didn't respond to a re-verification request within Apple's timeline. He demonstrates that the system administratively disappears bugs rather than fixing them, shifting the burden of proof onto unpaid external developers.
By surfacing Johnson's post to the HN community (450 points, 272 comments), zdw highlights the systemic issue: unlike most bug tracking systems where an open bug stays open until explicitly resolved or marked won't-fix, Apple's system assumes bugs are fixed unless the reporter re-verifies on Apple's schedule. This creates a perverse incentive where Apple's internal metrics improve without actual defect resolution.
Johnson's account is not a one-off complaint but a documented pattern spanning years of interaction with Apple's Feedback Assistant (formerly Radar). The system periodically sends re-verification requests, and if the developer misses the email or doesn't respond in time, the report is auto-closed — a mechanism that has been a source of developer pain for over a decade and functions as an adversarial process against the reporters.
Jeff Johnson, the independent macOS developer behind Lap Cat Software and tools like StopTheMadness, published a detailed account of Apple's Feedback Assistant systematically closing his bug reports. The mechanism is straightforward and infuriating: Apple periodically sends developers a request to "verify" that a previously reported bug still exists in a newer version of macOS or iOS. If the developer doesn't respond within the allotted window — or simply misses the email — the bug report is closed. Not fixed. Not triaged. Just closed.
The bug doesn't get resolved; it gets administratively disappeared. Johnson documents multiple instances of bugs he reported years ago that remain clearly reproducible, yet Apple's system marks them as resolved because he didn't jump through the re-verification hoop on Apple's timeline. The post resonated hard on Hacker News, pulling a score of 333 — which for a developer tooling gripe (not an AI launch or funding round) signals genuine, widespread frustration.
This isn't a new complaint. Apple's bug reporting system, originally known internally as Radar and now externalized as Feedback Assistant, has been a source of developer pain for over a decade. But Johnson's post crystallizes the specific mechanic that makes it adversarial: the system is designed to reduce open ticket count, not to track actual defect resolution.
Every platform vendor has a bug reporting system. Most of them are imperfect. But Apple's approach stands out because it inverts the default assumption. In most bug tracking systems, an open bug stays open until someone fixes it or explicitly marks it as won't-fix. Apple's system assumes bugs are fixed unless you prove otherwise.
This creates a perverse incentive structure. Apple's internal metrics presumably track open bug count as a health indicator. By shifting the burden of proof to external developers — who are unpaid volunteers in this process — Apple can show declining open bug counts without actually declining bug counts. It's the QA equivalent of reducing crime stats by not taking reports.
The developer community's reaction underscores a broader tension. Apple charges $99/year for a developer program membership. Developers build the apps that make Apple's platforms valuable. Yet the feedback loop between those developers and Apple's engineering teams runs through a system that treats reporter silence as confirmation of resolution. Compare this with how other major platforms handle developer bug reports:
- Google's Chromium/Android issue trackers leave bugs open indefinitely. Some Chromium bugs have been open for 10+ years. Embarrassing, maybe, but at least honest. - Microsoft's feedback hub has its own problems, but doesn't auto-close based on non-response. - Open source projects on GitHub let issues rot openly — and that transparency is itself a form of accountability.
Apple's approach is uniquely opaque. When a bug gets closed via the verify-or-die mechanism, there's no public record, no community visibility, and no pressure on Apple to actually address it. The developer who spent time writing a careful reproduction case gets a notification that their effort has been filed in the void.
If you ship software on Apple platforms — macOS, iOS, visionOS — you need to treat Feedback Assistant as a write-only interface. File your bugs, yes. Include detailed reproduction steps, crash logs, and sysdiagnose bundles, yes. But do not rely on Feedback Assistant as your source of truth for whether Apple knows about an issue.
Practical mitigations:
- Set calendar reminders for 90 days after filing any Feedback Assistant report. When the verify request comes, respond immediately — even if nothing has changed. Write "still reproducible on [latest version]" and resubmit. This is unpaid labor, but it's the only way to keep your bug visible in Apple's system. - Maintain your own bug database that maps to Feedback Assistant IDs. When a report gets auto-closed, refile it. Track how many times you've refiled the same bug — that data is useful for escalation conversations with your Apple developer relations contact, if you have one. - Use the open web as your bug tracker. Blog posts, tweets, and open radars (via sites like Open Radar, though Apple has made this harder) create public accountability that Feedback Assistant doesn't provide. Johnson's blog post is itself a more effective bug report than anything in Feedback Assistant, because 333 Hacker News upvotes create pressure that a closed ticket never will. - For critical bugs affecting your app's ship date, don't wait for Feedback Assistant. Use your Apple Developer Technical Support (DTS) incidents — you get two per year with your membership. These get human attention.
The meta-lesson here extends beyond Apple. Any platform where your bug reports can be silently closed is a platform where you need an external record of what you've reported. This applies to enterprise vendors, cloud providers, and anyone else who controls the bug tracking system you're filing into.
Apple's developer relations have been under increasing scrutiny, from App Store policies to the EU's Digital Markets Act forcing sideloading. Bug report handling is a quieter front in this tension, but it's one that directly affects code quality on Apple's platforms. Every auto-closed bug report is a signal that didn't reach an Apple engineer — or worse, a signal that reached them and was deliberately discarded to improve a dashboard metric. Until Apple decouples its bug count metrics from developer re-verification, Feedback Assistant will remain what it is: a system optimized for Apple's convenience, not for the software quality that developers and users both depend on.
> perhaps praying that the bug had magically disappeared on its own, with no effort from Apple.I suspect that this is a common approach. It maybe even works, often enough, to make it standard practice.For myself, I've stopped submitting bug reports.It's not the being ignored, that bothe
All kinds of open source projects do this too. It's really annoying. It's one thing if the authors actually try and fail to verify the bug, but these days it seems like most projects just close "stale" bugs as a matter of course. This is equivalent to assuming that any given bug
I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a re
Story time. I used to work for Facebook (and Google) and lots of games were played around bugs.At some point the leadership introduced an SLA for high then medium priority bugs. Why? because bugs would sit in queues for years. The result? Bugs would often get downgraded in priority at or close to th
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Author must not have worked in enterprise software before.That's a classic trick where the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. And if it doesn't get confirmed