Johnson documents a pattern where Apple periodically demands developers re-verify open bug reports on the latest OS or face automatic closure. He argues this creates an absurd treadmill for developers maintaining dozens of reports across multiple platforms, where missing a single email during a busy sprint can erase years of careful bug documentation. His detailed account treats this not as an oversight but as a systematic practice that is accelerating.
Submitted Johnson's article with framing that emphasizes the 'random' and involuntary nature of the closures, positioning Apple's process as adversarial to developers who are doing free QA work. The post resonated strongly with the HN community, reaching 443 points and 270 comments.
Johnson frames bug reports as volunteer labor — developers invest significant time creating reproducible test cases, sample projects, and sysdiagnose logs. He argues that Apple's $1.1 trillion App Store ecosystem depends on this free QA work, yet the verification-or-closure policy treats it as disposable, discouraging the very developers who care enough to report issues in detail.
The editorial synthesis explicitly argues this transcends a customer service complaint and represents a structural deficiency in how the world's most valuable company manages platform quality. By closing unverified reports rather than triaging or marking them as known issues, Apple loses institutional knowledge of bugs and removes them from engineering queues entirely — degrading the feedback loop that platform stability depends on.
Jeff Johnson, the veteran macOS developer behind Lap Cat Software and the Safari extension StopTheMadness, published a detailed account of Apple's practice of randomly closing Feedback Assistant bug reports unless developers actively re-verify that their reported bugs remain unfixed. The post, which quickly hit 360 points on Hacker News, documents a pattern that Apple platform developers have quietly endured for years — but that appears to be accelerating.
The mechanism works like this: Apple periodically sends emails to developers who have open bug reports, asking them to confirm whether their issue still reproduces on the latest version of macOS, iOS, or Xcode. If the developer doesn't respond within the verification window — typically around two weeks — Apple closes the report as "unverified," regardless of whether the underlying bug was actually fixed. The bug doesn't get triaged. It doesn't get marked as a known issue. It simply disappears from Apple's queue.
For developers like Johnson who maintain dozens of open Feedback Assistant reports across multiple Apple platforms, this creates an absurd treadmill. Each major OS release triggers a new round of verification requests, and each request demands that the developer install the latest beta or release, reproduce the issue, document it again, and respond within the deadline. Miss one email during a busy sprint, and years of careful bug documentation vanish.
This isn't a customer service complaint. It's a structural problem with how the world's most valuable company manages its platform quality.
Apple's developer ecosystem generates an estimated $1.1 trillion in billings and sales annually through the App Store. The developers who build on Apple's platforms are, in effect, doing free QA work when they file detailed bug reports with reproducible test cases, sample projects, and sysdiagnose logs. Apple's verification-or-closure policy treats this volunteer labor as disposable — a cost center to be minimized rather than a quality signal to be valued.
The community response on Hacker News reveals this isn't an isolated experience. Developers report bugs being closed after sitting untouched for years, only to receive a verification request rather than a fix. Others describe filing the same bug three or four times across OS releases because each previous report was closed for non-verification. Some have stopped filing bugs entirely, concluding that the Feedback Assistant is functionally a `/dev/null` endpoint with extra steps.
This stands in stark contrast to how other major platform vendors handle bug reports. Microsoft's Windows developer feedback channels, whatever their other faults, don't auto-close reports on a timer. Google's Chromium issue tracker keeps bugs open indefinitely and has transparent priority labels. Apple is unique among major platform owners in systematically purging its bug database on a schedule that serves internal metrics rather than platform quality.
The cynical reading — and it's hard to argue against it — is that this is a deliberate strategy to keep Feedback Assistant numbers looking healthy. Fewer open bugs means better internal dashboards. The cost is externalized entirely to developers, who either spend hours on the verification treadmill or give up and stop reporting. Either outcome makes Apple's numbers look better.
This bug report practice doesn't exist in isolation. It's part of a broader pattern where Apple's relationship with its developer community has become increasingly transactional and one-directional.
App Review remains opaque and inconsistent. The 30% commission persists despite regulatory pressure. Xcode's bug-reporting workflow itself is clunky — Feedback Assistant replaced the older Radar system but didn't meaningfully improve the developer experience. And perhaps most tellingly, Apple eliminated its bug reporter web interface years ago, funneling everything through Feedback Assistant, which requires a signed-in Apple Developer account and can only be accessed on Apple hardware.
The aggregate message to developers is clear: Apple wants your apps on its platforms, but doesn't want to hear about the problems you find along the way.
For independent developers and small shops, the math is particularly brutal. A solo developer maintaining three apps across iOS and macOS might have 15-20 open bug reports at any time. Each verification cycle consumes hours of unpaid work — hours that could go toward actually building software. At some point, rational developers simply stop filing. And that's when platform quality starts to silently degrade, because the people closest to the bugs are no longer reporting them.
If you're an Apple platform developer, this is a call to be strategic about bug reporting:
Document externally first. Before filing with Feedback Assistant, write up the bug on your blog, in a GitHub issue, or in a community forum. This creates a public record that survives Apple's purge cycles. Johnson's own blog is a masterclass in this — his Feedback Assistant reports may get closed, but his blog posts remain indexed and discoverable.
Automate your verification workflow. If you maintain multiple open reports, set up a calendar reminder for Apple's typical verification windows (usually shortly after major OS releases and mid-cycle updates). Batch your re-verifications rather than reacting to individual emails.
Use OpenRadar and community trackers. The OpenRadar project and similar community-maintained databases provide a parallel record of Apple bugs that isn't subject to Apple's auto-close policy. Filing there simultaneously ensures your work isn't lost.
Most importantly, calibrate your expectations. Feedback Assistant is not a bug tracker in the way that Jira, Linear, or GitHub Issues are bug trackers. It's a one-way suggestion box with an auto-shredder attached. Treating it as anything more leads to frustration. Treating it as exactly what it is — a minimal-effort channel that Apple may or may not act on — lets you budget your time accordingly.
For teams evaluating cross-platform strategies, this is another data point in the platform-risk calculus. Apple's developer tooling and relations have always been a "take it or leave it" proposition. But the gap between Apple's tooling experience and what developers get from platforms like Android (with its public issue tracker and responsive engineering teams on specific components) continues to widen.
Apple is unlikely to change this practice voluntarily — it serves their internal metrics too well. The most realistic path to improvement is continued public pressure from high-profile developers. Posts like Johnson's, amplified by Hacker News and developer Twitter, create reputational cost that Apple's developer relations team has historically responded to, if slowly. The WWDC developer relations sessions occasionally acknowledge these frustrations, but structural changes to Feedback Assistant have been minimal across recent releases. Until Apple treats developer bug reports as the valuable quality signal they are rather than a backlog to be purged, the best strategy remains: file, document publicly, and don't depend on Apple to keep your report alive.
> 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