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

cozzyd

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

stefan_

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.

DonThomasitos

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

themafia

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

eminence32

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.

s_u_d_o

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?

hector_vasquez

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.

freediddy

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.

16mb

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

jFriedensreich

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.

mikkupikku

Bug Bankruptcy.

gjvc

so what, jetbrains just doesn't fix them

_blk

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?

ChrisMarshallNY

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

cletus

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.

egorfine

> Why do I file bug reports with Apple Feedback Assistant? It is known for decades that Apple largely ignores bugreports.

kibwen

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

tim-tday

Fuck those guys.

yuters

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.

spike021

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.