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 then they can close it as User Error or Not Reproducible.

Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.

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 bothers me; it's when they pay attention, they basically insist that I become an unpaid systems engineering QC person, and go through enormous effort to prove the bug exists.

There is some bot that will match your issue to some other 3 vaguely related issue, then auto close in 3 days. The other vaguely related issues are auto closed for inactivity. Nothing is ever fixed, which is why they can't keep the thing from messing with your scroll position for years now.

When I close an old bug that is not actionable, I do feel bad about it. But keeping the bug open when realistically I can't really do anything with it might be worse.

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 the SLA. People even wrote automated rules to see if their bugs filed got downgraded to alert them.

Another trick was to throw it back to the user, usually after months, ostensibly to request information, to ask "is this still a problem?" or just adding "could not reproduce". Often you'd get no response. sometimes the person was no longer on the team or with the company. Or they just lost interest or didn't notice. Great, it's off your plate.

If you waited long enough, you could say it was "no longer relevant" because that version of the app or API had been deprecated. It's also a good reason to bounce it back with "is still this relevant?"

Probably the most Machiavellian trick I saw was to merge your bug with another one vaguely similar that you didn't own. Why? Because this was hard to unwind and not always obvious.

Anyone who runs a call center or customer line knows this: you want to throw it back at the customer because a certain percentage will give up. It's a bit like health insurance companies automatically sending a denial for a prior authorization: to make people give up.

I once submitted some clear bugs to a supermarket's app and I got a response asking me to call some 800 number and make a report. My bug report was a complete way to reproduce the issue. I knew what was going on. Somebody simply wanted to mark the issue as "resolved". I'm never going to do that.

I don't think you can trust engineering teams (or, worse, individuals) to "own" bugs. They're not going to want to do them. They need to be owned by a QA team or a program team that will collate similar bugs and verify something is actually fixed.

Google had their own versions of things. IIRC bugs had both a priority and s everity for some reason (they were the same 99% of the time) between 0 and 4. So a standard bug was p2/s2. p0/s0 was the most severe and meant a serious user-facing outage. People would often change a p2/s2 to p3/s3, which basically meant "I'm never going to do this and I will never look at it again".

I've basically given up on filing bug reports because I'm aware of all these games and getting someone to actually pay attention is incredibly difficult. So much of this comes down to stupid organizational-level metrics about bug resolution SLAs and policies.

I’ll fill out a bug report, wait a few days to a week to get a response, which are often AI generated, and then 48 hours afterward their bot marks it as stale. Telling me to check if it’s still broken or they assume it’s fixed lol

Yeah, I had found one manifestation of something else that they fixed by the time someone looked at it. The fix in the notes didn't look anything like my bug, only by observing that it now worked I was able to figure out that I had been the blind man trying to describe an elephant.

Each and every Radar (Apple's internal issue tracker is called Radar, and each issue is called a Radar) follows a state machine, going from the untriaged state to the done state. One hard-coded state in this is Verify. Each and every bug, once Fixed, cannot move to Closed without passing through the Verify state. It seems like a cool idea on the surface. It means that Apple assumes and demands that everything must be verified as fixed (or feature complete) by someone. Quite the corporate value to hold the line on, and it goes back decades.

I seriously hated the Verify state. It caused many pathologies. Imagine trying to run a burndown of your sprint when zero of the Radars are closed, because they have to be verified in production before being closed, meaning you cannot verify until after the release. Another pathology is that lots (thousands and thousands) of Radars end up stranded in Verify. Many, many engineers finish their fix, check it in, it gets released and then they move on. This led to a pathology that the writer of this post got caught up in: There is lots of "org health" reporting that goes out showing how many Radars are unverified and how long your Radars stay in the unverified state on average. A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this.

Pretty standard process.

I believe they also have attorneys. Perhaps that's how Apple could make bug-tracking more effective -- hire a prosecuting attorney and a defending attorney for each bug.

And then, no matter what I did, I could never, ever get a single word out of anyone about that case again. I often wonder if it's still open.

Their customer service threw me around because fixing my locked git processes that their system locks you out of for security reasons was too much work for them. My project service was unusable and they just auto-closed the ticket after never following up on their commitments. That was despite my consistently putting in work for them and doing software engineering debugging and delivering to them why it needed to be manually reset on their end.

After I complained on a twitter post tagging their CEO, someone reached out again finally and expected me to open a brand new fresh ticket because "their system needs this". Ok yeah no thank you, the team avoiding responsibility by auto-closing unresolved tickets expects me to put in more work and open a new ticket because you can't figure out how to re-open one or create one on my behalf. Lazy.

If you're not testing your code under extreme latency it will almost certainly fail in all kinds of hilarious ways.

I spend a lot of time with 4G as my only internet connection. It makes me feel that most software is quickly produced, poorly tested, and thrown out the door on a whim.

As do I.

> 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.

The author is extremely lucky to even get a response. I’ve filed several issue reports (as an end user, not as a developer) on Feedback Assistant over the years. Not only do the issues not get fixed, but there’s nary a response or any indication that anyone has looked or is planning to look at it. Apple does not even bother to close my issue reports. They just stay open.

Sometimes, some issues may get fixed. But no notice of the fix being done. I’d never know at all.

So yes, I certainly do plead insanity.

One being that the most recent version is on their cdn but not their [npm package](https://www.npmjs.com/package/livephotoskit?activeTab=readme) which was never updated for 7 years. You know what they did with this issue? They've marked it as "Unable to diagnose".

Also I've mentioned something about their documentation not being up to date for a function definition. This issue has remained open for 4 years now.

A good compromise might be select high quality bugs or users with good rep and disable auto-closing for them. In the age of AI it shouldn't be too hard to correlate all those low quality duplicates and figure out what's worth keeping alive, no?

This is not too unusual. I've completely given up on bug reports, it's almost always a complete waste of my time.

I'm currently going around in circles with a serious performance issue with two different vendors. They want logs, process lists and now real time data. It's an issue multiple people have complained about in their forums and on reddit. The fact that this exact same thing is going on with TWO different companies ...

Since this is your typical automated bot garbage process, couldn't you just respond with your own bot voice and say it's "verified" and is still an issue?

Seriously, auto-closing issues that haven't seen activity in 3–6 months is one of the best things you can do for your project.

If nobody's touched it in that long, it's time to accept it's never getting prioritized -- it's just collecting dust and making your backlog feel way heavier than it actually is.

So let it go. Let it go! (It feels good to channel your inner Elsa!)

A clean backlog is a healthy backlog. You'll actually be able to find the stuff people care about instead of wading through years of noise. And if something truly matters? Don't worry... those issues come back, they always do.

It is known for decades that Apple largely ignores bugreports.

Yes, I hate it too.

Put yourself in the position of the employee on the other side. They currently have 647 bugs in their backlog. And they also have actual work to do that's not even related to these bugs.

You come to work. Over night there's 369 emails (after many filters have been applied), 27 new bugs (14 of which are against a previous version). You triage. If you think 8h is enough to deal with 369 emails (67 of which are actionable. But which 67?) and actually close 27 bugs, then… well then you'd be assigned another 82 bugs and get put on email lists for advisory committees.

Before you jump to "why don't they just…", you should stop yourself and acknowledge that this in an unsolved problem. Ignore them, let them pile up? That's not a solution? Close them? No! It's still a problem! Ask you to verify it (and implicitly confirm that you still care)? That's… a bit better actually.

"Just hire more experts"… experts who are skilled enough, yet happy to work all day trying to reproduce these bugs? Sure, you can try. But it's extremely not a "why don't they just…".