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.
Addendum March 26 2026
Shortly after this blog post hit the front page of Hacker News yesterday, my “Investigation complete - Unable to diagnose with current information” Feedback FB22057274 was updated by Apple. What an amazing coincidence! Unfortunately, the update was not helpful, because Apple requested a sysdiagnose. For a user interface issue! This was precisely the fear I expressed in my earlier blog post:
I honestly don’t know what additional information Apple needs to diagnose it. I included not only steps to reproduce but also multiple screen recordings to illustrate. I have a suspicion that Apple did not even read my bug report, because I did not attach a sysdiagnose report. But a privacy-violating sysdiagnose would not be useful in this case!
[…]
The only trick in my bug report is that I used Little Snitch to simulate a slow loading link. This was just the easiest way I could think of to reliably reproduce the bug. There are of course other ways to simulate a slow loading link; if Apple Safari engineers of all people somehow can’t figure that out, then they aren’t qualified for their jobs. Again, however, the more likely explanation is that my feedback was ignored because it did not include a pro forma sysdiagnose, but who knows, because Apple did not request more information of any kind from me.
Here is my response this morning to Apple’s request:
You shouldn't need a sysdiagnose, and I don't know how a sysdiagnose would possibly be helpful for a user interface bug.
I found an easy way to reproduce the issue without Little Snitch: use the Network Link Conditioner preference pane from the Xcode Additional Tools download, and create a profile with Uplink Delay 3000 ms.
The Xcode Additional Tools, which include a number of useful utilities, can be found in the Apple Developer Downloads (sign-in required).