Apple randomly closes bug reports unless you "verify" the bug remains unfixed

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

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

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 is automatically fixed after X amount of time, which is pretty absurd.

This class of problem will soon be fixed with LLM agent that can just say "Yes, I can verify this is still not fixed". You just post the issue and then hook it up to your agent and forget about it. It can keep posting that there is an issue. It could even "bump! this is affecting crucial internal workflows" or similar every now and then.

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 related area, and so sometimes the most "efficient" thing is just to ask the user to re-test.

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.

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 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’ve been dealing with ElevenLabs pulling this same garbage.

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

Observation: Long, long ago I submitted a bug to Microsoft. I was new at the time and didn't distill it down to the minimum, just gave a scenario that would 100% reproduce. I was contacted months later because someone looked at it and couldn't reproduce.

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.

At work I literally just spent a half hour meeting with colleagues doing backlog management to clear out old bugs that were random one-offs and never came up again.

Pretty standard process.

to be fair this is pretty common spring cleaning in any bugzilla...

My only positive experience reporting bugs post early startup was with the chromium team, i get usually assigned to a dedicated reproducer that verifies and is reachable for helping them recreate in a matter of a few days. I had two experiences where bugs were taking less than a week from report to fix in canary.

Former Apple employee here. This is a deeper quirk of Apple culture than one would guess.

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.

> Why do I file bug reports with Apple Feedback Assistant? I plead insanity.

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.

That happens constantly everywhere, see github bots sometimes outright closing "stale" issues with nobody even trying to look at them

In Scotland, they close an issue by taking a vote of "OK", "Broken", or "Not Proven".

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.

The experience is similar if you call for end-user support. I did this once with an Apple Home issue. I called 133-MAC (Australia), got through to someone immediately, had a nice chat, was very impressed, felt supported, and got myself a case number. Of course, it wasn't resolved.

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.

The question is not whether they will close it if you don't regularly bump the report, but whether they will fix it if you do.

It’s quite possible (likely, even) for there to be more bugs reported than Apple has capacity to investigate. I assume this is just a filter they use to get the queue down to a more reasonable size and remove bug reports that are especially old (trusting that if they’re still issued they’ll be re-reported). This kind of culling happens all the time with low pri stuff and even sometimes medium pri if there’s a clear workaround.

I've submitted a couple of issues for their [javascript library for Live Photos](https://developer.apple.com/documentation/LivePhotosKitJS).

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.

There are no bugs if we don't check that they are still there. It's like anti-vaxer logic.

My favorite is the Claude Code bugtracker, on GitHub of course: https://github.com/anthropics/claude-code/issues

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.

I love that when I search for an odd behaviour or bug in macos or iOS, most of the time I will find a years old bug report with some irrelevant or useless "work around".

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

Some kind of acknowledgement would be nice, but nost of our feedback reports fall on deaf ears.

How can a user “verify” that the bug remains unfixed? So when a user reports a report, the user should check if the bug was solved after each update?

I looked at the bug report. You don’t use the packet filter, but expect packet filtering? Seems to be a misunderstanding. The flow filter needs a flow to filter, which requires a TCP handshake to establish.

It's the only reasonable approach. Any software that used by general public (even general developers) will eventually be flooded by bug reports that are not reproducible. Keeping them open helps no one. If a bug hasn't been touched for 2000 days the chance someone will suddenly care about it on the 2001st day is negligible.

Expected behaviour, closing article.

The sheer volume of bug reports negates the perceived importance

Can confirm. Java causes a bug in an Apple IO library that hasn't been fixed for years.

Stop wasting your life chomping at the bit to do unpaid labor for the sole benefit of megacorps.

The radar count is probably nearing a billion at this point

There's a breed of Dilbert Manager that loves to do this everywhere. Optimizing for "fewer open bugs" I imagine.

Anthropic does this too

> Why do I file bug reports with Apple Feedback Assistant?

It is known for decades that Apple largely ignores bugreports.

> FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab

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.

Replit customer service did the same thing to me as a paying customer.

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.

Bug Bankruptcy.

Devious.

Good news -- you can do this too! https://github.com/actions/stale

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.

The replies here suggest that many of us have been on both sides and that Apple's behavior it's a great way to trade bug triaging time on the org side for a few frustrated reporters on the customer side. The problem is it frustrates the most diligent of bug reporters who put time into filing high quality issues resulting in overall lower bug submission quality.

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?

so what, jetbrains just doesn't fix them

Oh you sweet summer child. Everyone else does this.

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

[dead]

[dead]

[dead]

[dead]

[dead]

Fuck those guys.

What else should they do? Stop releasing any updates until they reproduced any obscure bug report?