Why I Keep Filing Bug Reports with Apple Feedback Assistant (Even When It Feels Futile)

Filing bug reports with Apple’s Feedback Assistant can feel like a blend of addiction and insanity. You swing between periods of enthusiasm and long stretches of frustration. I’ve even attempted organizing a public boycott of the Feedback Assistant, with a detailed list of demands for improving the system—but it never gained traction among other developers. And yet, I continue to submit reports. Why? Because sometimes, Apple actually fixes the issues.

But more often, my frustration isn’t about unresolved bugs—it’s about the disregard Apple shows for the reports and the developers who take the time to file them. The process can feel like a waste of time, as if the company expects us to serve as unpaid testers without valuing our effort.

The Privacy Bug That Went Ignored for Years

In March 2023, I submitted FB12088655, a bug titled “Privacy: Network filter extension TCP connection and IP address leak.” I documented the bug extensively in a blog post, including step-by-step reproduction instructions and an Xcode example project. For three years, Apple didn’t respond—until a few weeks ago, when they requested I “verify” the bug using macOS 26.4 beta 4.

Here’s the problem: I install WWDC betas each June, but I don’t run ongoing OS betas after major updates release in September. With limited time and devices, testing every beta isn’t feasible. Past experience taught me that Apple often asks for beta verification even when they haven’t addressed the bug. When I asked if beta 4 fixed the issue, the response was evasive. Worse, Apple threatened to close my report if I didn’t verify within two weeks—a deadline set after three years of silence.

I didn’t install the beta myself, but developers from Little Snitch ran it for me and confirmed the bug was still reproducible. Once macOS 26.4 went public, I verified it myself: the bug persists. It seems Apple was hoping the bug would magically disappear without any effort on their part.

More Evidence of a Broken System

Another example: FB22057274, titled “Pinned tabs: slow-loading target=’_blank’ links appear in the wrong tab,” remains unresolved. Despite clear, reproducible steps and multiple screen recordings, Apple closed it with “Investigation complete – Unable to diagnose with current information.” When I asked what further details were needed, I received no answer.

It appears some internal metrics at Apple incentivize closing reports rather than solving them. Out of sight, out of mind. Even the iPadOS 26.4 betas introduced a Safari crash I reported a month prior, which remained unaddressed by the public release. This begs the question: what is the real purpose of betas?

When Apple Finally Responds (Sort Of)

After this post hit Hacker News, Apple updated FB22057274. The “solution”? They requested a sysdiagnose for a UI issue—something unnecessary and invasive. My bug was easily reproducible using Little Snitch or the Network Link Conditioner in Xcode Additional Tools, which allows simulating slow network connections. A sysdiagnose would not provide meaningful insights for a UI bug, highlighting the disconnect between Apple’s process and practical debugging.

It’s hard not to feel that reports without a formal sysdiagnose are ignored, regardless of their clarity. This disconnect shows a troubling lack of respect for the developers who invest time in identifying and documenting bugs.

Conclusion: Why I Keep Reporting Bugs

Despite repeated frustrations, I keep filing reports because sometimes Apple does act on them—but only after years of inaction. Until there’s a system that respects developer time, provides clear communication, and fixes reproducible bugs in a timely manner, Feedback Assistant will remain a frustrating but necessary tool. Filing bug reports feels like an act of hope more than efficiency—a gamble that Apple will eventually take notice.