Apple randomly closes bug reports unless you “verify” the bug remains unfixed

Previous: App Store developers: suggest your small ideas for improvement
Articles index
Jeff Johnson (My apps, PayPal.Me, Mastodon)
Apple randomly closes bug reports unless you “verify” the bug remains unfixed
March 25 2026
Why do I file bug reports with Apple Feedback Assistant? I plead insanity. Or perhaps addiction. I seesaw between phases of abstinence and falling off the wagon. I’ve even tried organizing a public boycott of Feedback Assistant, with a list of demands to improve the experience for users, but the boycott never caught on with other developers. Regardless, an incentive still exists to file bug reports, because Apple actually fixes some of my bugs. My main complaint about the bug reporting process is not the unfixed bugs but rather the disrespect for bug reports and the people who file them. Apple intentionally wastes our time with no regrets, as if our time had no value, as if we had some kind of duty to serve Apple.
In March 2023, I filed FB12088655 “Privacy: Network filter extension TCP connection and IP address leak.” I mentioned this bug report at the time in a blog post, which included the same steps to reproduce and example Xcode project that I provided to Apple. In the three years since I filed the bug report, I received no response whatsoever from Apple… until a couple of weeks ago, when Apple asked me to “verify” the issue with macOS 26.4 beta 4 and update my bug report.
I install the WWDC betas every year in June but don’t run OS betas after September when the major OS updates are released. I don’t have enough time or indeed enough Apple devices to be an unpaid tester year round. Thus, verifying issues in betas is a hassle for me. I’ve been burned by such requests in the past, asked by Apple to verify issues in betas that were not fixed, so I asked Apple directly whether beta 4 fixed the bug: they should already know, since they have my steps to reproduce! However, their response was evasive, never directly answering my question. Moreover, they threatened to close my bug report and assume the bug is fixed if I didn’t verify within two weeks! Again, this is after Apple silently sat on my bug report for three years.
Although I didn’t install the beta myself, I spoke to the developers of Little Snitch, who do run the macOS betas, and they kindly informed me that in their testing, they could still reproduce my issue with macOS 26.4 beta 4. It was no surprise, then, that when I updated to macOS 26.4, released to the public yesterday by Apple, I could still reproduce the bug with my instructions and example project. It appears that Apple knowingly sent me on a wild goose chase, demanding that I “verify” a bug they did nothing to fix, perhaps praying that the bug had magically disappeared on its own, with no effort from Apple.
By the way, a few weeks ago I published a blog post about another bug, FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab,” which is also 100% reproducible but nonetheless was marked by Apple with the resolution “Investigation complete - Unable to diagnose with current information.” On March 9, I updated the bug report, asking what additional information Apple needs from me—they never asked for more information—but I’ve yet to receive a response.
I can only assume that some bozos in Apple leadership incentivize underlings to close bug reports, no matter whether the bugs are fixed. Out of sight, out of mind. Apple’s internal metrics probably tell them that they have no software quality problem, because the number of open bug reports is kept lower artificially.
Ironically, the iPadOS 26.4 betas introduced a Safari crashing bug that I reported a month ago, but Apple failed to fix the bug before the public release. What’s the purpose of betas? As far as I can tell, the purpose is just to annoy people who file bugs, without doing anything useful.
Jeff Johnson (My apps, PayPal.Me, Mastodon)
Articles index
Previous: App Store developers: suggest your small ideas for improvement

The article details a frustrating and increasingly common experience faced by Apple developers submitting bug reports, centering around the requirement for developers to “verify” the resolution of reported issues. Jeff Johnson, a developer of several apps, describes his ongoing struggle with Apple’s Feedback Assistant, emphasizing a perceived lack of respect for developer time and input. The core of Johnson’s complaint revolves around Apple’s insistence on demanding verification of unfixed bugs, often after years of silence on the original report, and then threatening closure if the verification isn’t provided within a strict two-week timeframe.

Johnson recounts the case of FB12088655, a privacy-related bug concerning network filter extension TCP connection and IP address leaks, which remained unresolved for three years before Apple demanded verification in macOS 26.4 beta 4. Despite Johnson’s diligence and providing detailed reproduction steps, Apple responded evasively and pressured him to verify—a process complicated by the need to regularly install and test beta versions of the operating system, a task requiring significant time and resources. Third-party developers like those at Little Snitch corroborated Johnson’s findings, confirming the bug’s continued existence within the beta environment.

This pattern extends to another bug report, FB22057274, regarding slow-loading links, where Apple simply marked the issue as “Investigation complete - Unable to diagnose with current information” without any further communication or request for clarification from Johnson. This highlights a concerning disregard for developer input and a tendency to prematurely close reports.

Johnson suggests a possible, cynical motivation behind this behavior: that Apple leadership incentivizes teams to minimize the number of open bug reports, regardless of actual fixes, in order to artificially inflate perceived software quality metrics. The author’s account underscores a broader issue of developer frustration with the bug reporting process, particularly the feeling that Apple’s time and resources are not valued. The irony of introducing betas to identify bugs, while simultaneously using them as a tool to frustrate and discourage developers, is brought to the forefront. The continued existence of issues, such as the Safari crashing bug within iPadOS 26.4 betas, despite reported submissions, casts doubt on the utility of the beta testing program itself. Ultimately, Johnson’s experience reveals a disconnect between developers and Apple’s bug reporting system, characterized by delayed responses, demanding verification requests, and a seeming lack of commitment to thoroughly resolving reported issues.