13 ms·

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

472 points by zdw 7mo ago

rendaw 7mo ago
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.
DonThomasitos 7mo ago
What else should they do? Stop releasing any updates until they reproduced any obscure bug report?
- hu3 7mo ago
  They could just, not close the bug? Mozilla is famous for having 20 year old bug reports that gets fixed after all that time.
- themacguffinman 7mo ago
  How about they keep the bug report open until they attempt and confirm the bug is no longer reproducible?
cozzyd 7mo ago
to be fair this is pretty common spring cleaning in any bugzilla...
- jeffbee 7mo ago
  It's very common but it's still a poor practice.
  - methodical 7mo ago
    Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
    - jeffbee 7mo ago
      Closing bugs because they can no longer be reproduced: obviously fine. Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.
    - convolvatron 7mo ago
      the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion. if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it. otherwise you're just throwing away useful information. edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
      - jeffbee 7mo ago
        Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
    - eszed 7mo ago
      Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
      - Barbing 7mo ago
        >creates the user expectation that "no one looks at these Apple has done the best job of creating this expectation. Apple Feedback = compliments (and ideas) Public Web = complaints & bug reports Apple Support = important bug reports (can create feedback first then call immmediately) — Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541 https://news.ycombinator.com/item?id=46591541
- gortok 7mo ago
  I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue." The sentiment feels like software folks are optimizing for the local optimum. It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a policy.
  - jlarocco 7mo ago
    Considering Apple is one of the largest companies in the world, raking in money, what consequential effects are you talking about? It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. As a software developer, I don't have any problem with this. If a bug doesn't bother somebody enough for them to follow up, then spend time fixing bugs for people who will. Apple isn't obligated to fix anybody's bug. It's not like they were nagging him about it - it's been years, and they had major releases in the mean time. Quite possible it was fixed as a side effect of something else.
    - Barbing 7mo ago
      >anybody's bug. :) Funny at first but I’m coming around to that perspective
    - Noaidi 7mo ago
      > It certainly doesn't seem to hurt their bottom line …yet
    - eszed 7mo ago
      This is exactly the mindset to which GP and I object.
    - gortok 7mo ago
      > It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. I want to draw out this comment because it's so antithetical to what Apple marketed that it stood for (if you remember, the wonderful 1984 commercial Apple created; which was very much against the big behemoths of the day and the way they operated). We're at the point where we've normalized crappy behavior and crappy software so long as the bottom line keeps moving up and to the right on the graph. Not, "Let's build great software that people love.", but "How much profit can we squeeze out? Let's try to squeeze some more." We've optimized for profit instead of happiness and customer satisfaction. That's why it feels like quality in general is getting worse, profit became the end goal, not the by-product of a customer-centric focus. We've numbed ourselves to the pain and discomfort we endure and cause every single day in the name of profit.
- hrmtst93837 7mo ago
  [flagged]
stefan_ 7mo ago
My favorite is the Claude Code bugtracker, on GitHub of course: https://github.com/anthropics/claude-code/issues 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.
- kvirani 7mo ago
  Oh so it jumping to the top happens to others too?
- silverwind 7mo ago
  They are also closing issues automatically that has no "activity" in 30 days, so you have to spam those issues.
  - prymitive 7mo ago
    Sounds like a job for an agentic tool that can produce human like sentences on interval …
- gjvc 7mo ago
  this scroll position thing is mentally damaging
- orthoxerox 7mo ago
  > that will match your issue to some other 3 vaguely related issue, then auto close Well, it was trained on StackOverflow.
- ted537 7mo ago
  Yep I've never successfully installed claude code, and this is exactly what happened to the issue lol
themafia 7mo ago
> 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.
- dbetteridge 7mo ago
  That would be an accurate summary of almost all software. Either it's quickly produced and thrown out the door as it's a startup trying to iterate and find market fit asap or because it's a bigcorp who's metrics are all not related to software.
eminence32 7mo ago
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.
- hart_russell 7mo ago
  A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it
  - wat10000 7mo ago
    That’s easy enough. The hard part is doing so without capturing a bunch of email, messages, and other private data that happens to be in memory at the time.
    - Barbing 7mo ago
      Ignorant question, if privacy didn’t matter and they had an atomically identical machine, would there still be plenty of edge cases where it was the printer or the Wi-Fi causing the issue? In any case I would have said it sounds difficult on every front
      - wat10000 7mo ago
        I should be more precise. Capturing the system state isn’t too hard. Turning that into a reproducer may be quite hard, because of things like you say. There are certainly a lot of bugs that such a capture would make easier to figure out, but it wouldn’t be a panacea.
  - eminence32 7mo ago
s_u_d_o 7mo ago
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 7mo ago
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.
- lapcat 7mo ago
  I think you're incorrectly assuming two things: 1. Apple engineers actually attempted to fix the bug. 2. Feedback Assistant "Please verify with the latest beta" matches the Radar "Verify" state. I don't believe either of those are true.
- zer00eyz 7mo ago
  Interesting insight to what should be a good internal process if users followed up. In this case the bug wasn't fixed. > A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this. The simple solution here: you should also be graded on closing bugs that get re-opened.
- jldugger 7mo ago
  > 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. I think most teams use verify as a "closed" state to hide all that messiness. But sure, zero bugs is a project management fiction and produces perverse outcomes.
freediddy 7mo ago
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.
- Leherenn 7mo ago
  From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").
  - b112 7mo ago
    It'd kind of sad, how the market went. I suppose there are pluses too. But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items. Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet. On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail. I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes. Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
    - nradov 7mo ago
      High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.
16mb 7mo ago
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
- paulasjes 7mo ago
  (I work at ElevenLabs) Sad to hear this. How are you submitting the bug report? If you submit an issue via any of our open source repos on GitHub you'll get a timely human response.
jFriedensreich 7mo ago
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.
- dddgghhbbfblk 7mo ago
  That's impressive. I've only reported one bug to Chromium, years ago. It was a bug in their CSS engine and I included an HTML file with a full repro. It took them a few years to actually fix it since the person who was initially assigned it never bothered, eventually left Google, and nobody picked it back up for a while. But they did eventually fix it, so that's something, I suppose. Edit: this comment elsewhere in the thread is closer to my experience: https://news.ycombinator.com/item?id=47523107 https://news.ycombinator.com/item?id=47523107 Certainly in my own stint at Google I saw the same thing--bugs below a certain priority level would just never get looked at.
- throw948384dji 7mo ago
  I’ve had the worst experiences with Chromium. I’ve found multiple regressions in Chromium, tracked down regression points to a single commit, provided clear reproduction steps, shown that they do not reproduce with either Safari and Firefox or even older Chromium... And then the bugs were just ignored for years at this point. Sometimes some people played ping pong with the assignee field, before leaving it unassigned, and that’s it. I don’t report any new Chromium regressions I find anymore.
mikkupikku 7mo ago
Bug Bankruptcy.
gjvc 7mo ago
so what, jetbrains just doesn't fix them
_blk 7mo ago
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 7mo ago
> 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.
- cindyllm 7mo ago
  [dead]
- thewebguyd 7mo ago
  > they basically insist that I become an unpaid systems engineering QC person Microsoft support is guilty of this, especially for Azure & 365 issues. Like sorry, but you aren't paying me to debug your software. Here's a report, and here's proof of me reproducing the problem & some logs. That's all I'm going to provide. It's your software, you debug it.
  - sigbottle 7mo ago
    Damn. I've put quite a lot of effort into open source tools w.r.t. debugging and bugfixing, but yeah putting that for a corporate product that doesn't even respect you must be draining.
  - deathanatos 7mo ago
    While I'd love to take your tack, unfortunately, I find that if I actually want the fix, I have to become their unpaid engineer. Which is ridiculous, because at the same time my company is paying a separate support fee, large enough to literally employ a dedicated engineer for my company!
    - bloppe 7mo ago
      It makes a lot of sense. I would also try to get my customers to do work for me if I were confident they would never churn.
cletus 7mo ago
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.
- AlBugdy 7mo ago
  > Google had their own versions of things. IIRC bugs had both a priority and severity for some reason (they were the same 99% of the time) between 0 and 4. At the company I worked with (not Google, but a major one) this was the same. We used Salesforce, the "Lightning Experience" or whatever it was called [0]. Our version was likely customized for our company, but I think the idea was the same - one, I think the "priority", was for our eyes only, one was for the customer (the "severity"). If the customer was insistent on raising the severity, we'd put it as sev1, but the priority was what we actually thought it was. I was actually surprised that for the ~4 years I was there no one made the mistake of telling the customer the priority as a mistake, especially when a lot of people were sloppily copy-pasting text from Slack or other internal tools that sometimes referred to a case as either the severity or the priority. Those were heavy customers with SLAs, though, not supermarket apps or anything like that. What was sad was that our internal tools, no matter how badly written, with 90's UI and awful security practices, our tools were 50 times as fast as whatever Salesforce garbage we had to deal with. Of course, there was a lot of unneeded redundancy between the tools so the complexity didn't stay in the Salesforce tool. But somehow the internal tools written by someone 10 years ago, barely maintained, who had to still deal with complex databases of who-what-when-how, felt like you had the DB locally on a supercomputer while SF felt like you were actually asking a very overworked person to manually give you your query right on each click. I'm exaggerating, but just by a bit. [0] That name was funny because it was slow as shit. Each click took 5 to 20 seconds to update the view. I wonder what the non-Lightning version was.
egorfine 7mo ago
> Why do I file bug reports with Apple Feedback Assistant? It is known for decades that Apple largely ignores bugreports.
kibwen 7mo ago
Stop wasting your life chomping at the bit to do unpaid labor for the sole benefit of megacorps.
tim-tday 7mo ago
Fuck those guys.
yuters 7mo ago
I've submitted a couple of issues for their [javascript library for Live Photos](https://developer.apple.com/documentation/LivePhotosKitJS 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 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 7mo ago
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.
arbirk 7mo ago
The radar count is probably nearing a billion at this point
lucasay 7mo ago
[dead]
josefritzishere 7mo ago
Devious.
knorker 7mo ago
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…".
jas- 7mo ago
The sheer volume of bug reports negates the perceived importance
Ensorceled 7mo ago
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 ...
leontloveless 7mo ago
[dead]
SilverElfin 7mo ago
Anthropic does this too
LorenPechtel 7mo ago
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.
maltyxxx 7mo ago
[flagged]
BrenBarn 7mo ago
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.
- nradov 7mo ago
  It's rather unreasonable to be annoyed. The maintainers may have entirely different priorities, which is fine. They're also likely being spammed with low-effort bug reports (not yours necessarily but from others). The great thing about open source projects you can just fix the bug yourself and submit a PR, or fork the whole project if the maintainers won't merge your changes. If you don't have the time or skills yourself then you can even pay a contractor to do it for you.
  - arijun 7mo ago
    > It's rather unreasonable to be annoyed. I disagree. If you discover that a bug that makes an open source library unusable to you, after spending time on learning and using that library, and the authors close the bug as a wontfix, I think being annoyed is quite reasonable, even expected.
    - nradov 7mo ago
      If that type of thing annoys you then you should restrict your use of open source projects to those backed by corporations with a paid support business model.
      - kurtis_reed 7mo ago
        For feature requests, sure, but not for bug reports
    - grey-area 7mo ago
      Not really no, you got the support you were willing to pay for.
tottenhm 7mo ago
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.
- aworks 7mo ago
  I was an development tools engineering manager who was in enumerable "bug scrubs" to triage the flow. Sometimes I would advocate based on business reasons to fix the bug. Or to de-prioritize it or close it. I took every side possible, depending. As did the more pragmatic of the engineers. I miss the give and take, if not the feeling of perpetual technical debt.
- Wiles_7 7mo ago
  Not any more, 'Not proven' was abolished at the start of this year.
throwaway85825 7mo ago
Can confirm. Java causes a bug in an Apple IO library that hasn't been fixed for years.
dboreham 7mo ago
There's a breed of Dilbert Manager that loves to do this everywhere. Optimizing for "fewer open bugs" I imagine.
wenldev 7mo ago
[dead]
PunchyHamster 7mo ago
That happens constantly everywhere, see github bots sometimes outright closing "stale" issues with nobody even trying to look at them
mannanj 7mo ago
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.
twodave 7mo ago
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.
- nullpoint420 7mo ago
  This is where a company that categorizes customer feedback like unwrap.ai or enterpret could help with volume and priority
  - saagarjha 7mo ago
    No.
    - nullpoint420 7mo ago
      Sheesh, you see suggestions here all the time. Just trying to be helpful
      - saagarjha 7mo ago
        For this Apple would have to trust a third party with their bugs and also not have tried to do this themselves
        nullpoint420 7mo ago
        I 100% agree when it comes to security issues. They would have to host it themselves on their intranet through AppleConnect. I'm a bit removed from what software Apple uses nowadays. Back when I worked there ~2021 it was still a mix of native apps (Radar, Phantom) and self-hosted enterprise versions of popular development tools. (eg. GitHub)
raincole 7mo ago
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.
jen729w 7mo ago
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.
- AnonC 7mo ago
  I had an even more time consuming experience like this. I worked with Apple Support over the phone for a few months. They had me install a profile on the iPhone to collect more diagnostic logs, had me perform various steps to reproduce the issue, followed up for more information, etc. After a few months, the person assigned to the case went on vacation or something and another person was assigned. Coincidentally, it was getting closer to a new iOS release date. My whole case went completely dead and there was no way to revive it.
dbg31415 7mo ago
Good news -- you can do this too! https://github.com/actions/stale 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.
AnonC 7mo ago
> 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.
patrickRyu 7mo ago
[flagged]
eptcyka 7mo ago
Some kind of acknowledgement would be nice, but nost of our feedback reports fall on deaf ears.
blitzar 7mo ago
Expected behaviour, closing article.
iheartbiggpus 7mo ago
There are no bugs if we don't check that they are still there. It's like anti-vaxer logic.
junofan 7mo ago
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.
arjie 7mo ago
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.
- user34283 7mo ago
  And if the maintainer does close the issue, you can have the agent make a disparaging blog post automatically.
  - arjie 7mo ago
    It's Apple. They won't even notice. If all of 4chan and HN decided to abandon Apple they wouldn't even register the change.
eviks 7mo ago
> 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 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?
- lapcat 7mo ago
  No. https://news.ycombinator.com/item?id=47523983 https://news.ycombinator.com/item?id=47523983

472 points by zdw 7mo ago

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.

DonThomasitos 7mo ago

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

hu3 7mo ago
They could just, not close the bug? Mozilla is famous for having 20 year old bug reports that gets fixed after all that time.
themacguffinman 7mo ago
How about they keep the bug report open until they attempt and confirm the bug is no longer reproducible?

cozzyd 7mo ago

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

jeffbee 7mo ago
It's very common but it's still a poor practice.
- methodical 7mo ago
  Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
  - jeffbee 7mo ago
    Closing bugs because they can no longer be reproduced: obviously fine. Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.
  - convolvatron 7mo ago
    the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion. if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it. otherwise you're just throwing away useful information. edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
    - jeffbee 7mo ago
      Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
  - eszed 7mo ago
    Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
    - Barbing 7mo ago
      >creates the user expectation that "no one looks at these Apple has done the best job of creating this expectation. Apple Feedback = compliments (and ideas) Public Web = complaints & bug reports Apple Support = important bug reports (can create feedback first then call immmediately) — Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541 https://news.ycombinator.com/item?id=46591541
gortok 7mo ago
I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue." The sentiment feels like software folks are optimizing for the local optimum. It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a policy.
- jlarocco 7mo ago
  Considering Apple is one of the largest companies in the world, raking in money, what consequential effects are you talking about? It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. As a software developer, I don't have any problem with this. If a bug doesn't bother somebody enough for them to follow up, then spend time fixing bugs for people who will. Apple isn't obligated to fix anybody's bug. It's not like they were nagging him about it - it's been years, and they had major releases in the mean time. Quite possible it was fixed as a side effect of something else.
  - Barbing 7mo ago
    >anybody's bug. :) Funny at first but I’m coming around to that perspective
  - Noaidi 7mo ago
    > It certainly doesn't seem to hurt their bottom line …yet
  - eszed 7mo ago
    This is exactly the mindset to which GP and I object.
  - gortok 7mo ago
    > It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. I want to draw out this comment because it's so antithetical to what Apple marketed that it stood for (if you remember, the wonderful 1984 commercial Apple created; which was very much against the big behemoths of the day and the way they operated). We're at the point where we've normalized crappy behavior and crappy software so long as the bottom line keeps moving up and to the right on the graph. Not, "Let's build great software that people love.", but "How much profit can we squeeze out? Let's try to squeeze some more." We've optimized for profit instead of happiness and customer satisfaction. That's why it feels like quality in general is getting worse, profit became the end goal, not the by-product of a customer-centric focus. We've numbed ourselves to the pain and discomfort we endure and cause every single day in the name of profit.
hrmtst93837 7mo ago
[flagged]

stefan_ 7mo ago

My favorite is the Claude Code bugtracker, on GitHub of course: https://github.com/anthropics/claude-code/issues 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.

kvirani 7mo ago
Oh so it jumping to the top happens to others too?
silverwind 7mo ago
They are also closing issues automatically that has no "activity" in 30 days, so you have to spam those issues.
- prymitive 7mo ago
  Sounds like a job for an agentic tool that can produce human like sentences on interval …
gjvc 7mo ago
this scroll position thing is mentally damaging
orthoxerox 7mo ago
> that will match your issue to some other 3 vaguely related issue, then auto close Well, it was trained on StackOverflow.
ted537 7mo ago
Yep I've never successfully installed claude code, and this is exactly what happened to the issue lol

themafia 7mo ago

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

dbetteridge 7mo ago
That would be an accurate summary of almost all software. Either it's quickly produced and thrown out the door as it's a startup trying to iterate and find market fit asap or because it's a bigcorp who's metrics are all not related to software.

eminence32 7mo ago

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.

hart_russell 7mo ago
A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it
- wat10000 7mo ago
  That’s easy enough. The hard part is doing so without capturing a bunch of email, messages, and other private data that happens to be in memory at the time.
  - Barbing 7mo ago
    Ignorant question, if privacy didn’t matter and they had an atomically identical machine, would there still be plenty of edge cases where it was the printer or the Wi-Fi causing the issue? In any case I would have said it sounds difficult on every front
    - wat10000 7mo ago
      I should be more precise. Capturing the system state isn’t too hard. Turning that into a reproducer may be quite hard, because of things like you say. There are certainly a lot of bugs that such a capture would make easier to figure out, but it wouldn’t be a panacea.
- eminence32 7mo ago

s_u_d_o 7mo ago

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 7mo ago

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.

lapcat 7mo ago
I think you're incorrectly assuming two things: 1. Apple engineers actually attempted to fix the bug. 2. Feedback Assistant "Please verify with the latest beta" matches the Radar "Verify" state. I don't believe either of those are true.
zer00eyz 7mo ago
Interesting insight to what should be a good internal process if users followed up. In this case the bug wasn't fixed. > A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this. The simple solution here: you should also be graded on closing bugs that get re-opened.
jldugger 7mo ago
> 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. I think most teams use verify as a "closed" state to hide all that messiness. But sure, zero bugs is a project management fiction and produces perverse outcomes.

freediddy 7mo ago

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.

Leherenn 7mo ago
From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").
- b112 7mo ago
  It'd kind of sad, how the market went. I suppose there are pluses too. But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items. Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet. On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail. I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes. Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
  - nradov 7mo ago
    High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.

16mb 7mo ago

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

paulasjes 7mo ago
(I work at ElevenLabs) Sad to hear this. How are you submitting the bug report? If you submit an issue via any of our open source repos on GitHub you'll get a timely human response.

jFriedensreich 7mo ago

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.

dddgghhbbfblk 7mo ago
That's impressive. I've only reported one bug to Chromium, years ago. It was a bug in their CSS engine and I included an HTML file with a full repro. It took them a few years to actually fix it since the person who was initially assigned it never bothered, eventually left Google, and nobody picked it back up for a while. But they did eventually fix it, so that's something, I suppose. Edit: this comment elsewhere in the thread is closer to my experience: https://news.ycombinator.com/item?id=47523107 https://news.ycombinator.com/item?id=47523107 Certainly in my own stint at Google I saw the same thing--bugs below a certain priority level would just never get looked at.
throw948384dji 7mo ago
I’ve had the worst experiences with Chromium. I’ve found multiple regressions in Chromium, tracked down regression points to a single commit, provided clear reproduction steps, shown that they do not reproduce with either Safari and Firefox or even older Chromium... And then the bugs were just ignored for years at this point. Sometimes some people played ping pong with the assignee field, before leaving it unassigned, and that’s it. I don’t report any new Chromium regressions I find anymore.

mikkupikku 7mo ago

Bug Bankruptcy.

gjvc 7mo ago

so what, jetbrains just doesn't fix them

_blk 7mo ago

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 7mo ago

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

cindyllm 7mo ago
[dead]
thewebguyd 7mo ago
> they basically insist that I become an unpaid systems engineering QC person Microsoft support is guilty of this, especially for Azure & 365 issues. Like sorry, but you aren't paying me to debug your software. Here's a report, and here's proof of me reproducing the problem & some logs. That's all I'm going to provide. It's your software, you debug it.
- sigbottle 7mo ago
  Damn. I've put quite a lot of effort into open source tools w.r.t. debugging and bugfixing, but yeah putting that for a corporate product that doesn't even respect you must be draining.
- deathanatos 7mo ago
  While I'd love to take your tack, unfortunately, I find that if I actually want the fix, I have to become their unpaid engineer. Which is ridiculous, because at the same time my company is paying a separate support fee, large enough to literally employ a dedicated engineer for my company!
  - bloppe 7mo ago
    It makes a lot of sense. I would also try to get my customers to do work for me if I were confident they would never churn.

cletus 7mo ago

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.

AlBugdy 7mo ago
> Google had their own versions of things. IIRC bugs had both a priority and severity for some reason (they were the same 99% of the time) between 0 and 4. At the company I worked with (not Google, but a major one) this was the same. We used Salesforce, the "Lightning Experience" or whatever it was called [0]. Our version was likely customized for our company, but I think the idea was the same - one, I think the "priority", was for our eyes only, one was for the customer (the "severity"). If the customer was insistent on raising the severity, we'd put it as sev1, but the priority was what we actually thought it was. I was actually surprised that for the ~4 years I was there no one made the mistake of telling the customer the priority as a mistake, especially when a lot of people were sloppily copy-pasting text from Slack or other internal tools that sometimes referred to a case as either the severity or the priority. Those were heavy customers with SLAs, though, not supermarket apps or anything like that. What was sad was that our internal tools, no matter how badly written, with 90's UI and awful security practices, our tools were 50 times as fast as whatever Salesforce garbage we had to deal with. Of course, there was a lot of unneeded redundancy between the tools so the complexity didn't stay in the Salesforce tool. But somehow the internal tools written by someone 10 years ago, barely maintained, who had to still deal with complex databases of who-what-when-how, felt like you had the DB locally on a supercomputer while SF felt like you were actually asking a very overworked person to manually give you your query right on each click. I'm exaggerating, but just by a bit. [0] That name was funny because it was slow as shit. Each click took 5 to 20 seconds to update the view. I wonder what the non-Lightning version was.

egorfine 7mo ago

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

kibwen 7mo ago

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

tim-tday 7mo ago

Fuck those guys.

yuters 7mo ago

I've submitted a couple of issues for their [javascript library for Live Photos](https://developer.apple.com/documentation/LivePhotosKitJS 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 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 7mo ago

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.

arbirk 7mo ago

The radar count is probably nearing a billion at this point

lucasay 7mo ago

[dead]

josefritzishere 7mo ago

Devious.

knorker 7mo ago

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

jas- 7mo ago

The sheer volume of bug reports negates the perceived importance

Ensorceled 7mo ago

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

leontloveless 7mo ago

[dead]

SilverElfin 7mo ago

Anthropic does this too

LorenPechtel 7mo ago

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.

maltyxxx 7mo ago

[flagged]

BrenBarn 7mo ago

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.

nradov 7mo ago
It's rather unreasonable to be annoyed. The maintainers may have entirely different priorities, which is fine. They're also likely being spammed with low-effort bug reports (not yours necessarily but from others). The great thing about open source projects you can just fix the bug yourself and submit a PR, or fork the whole project if the maintainers won't merge your changes. If you don't have the time or skills yourself then you can even pay a contractor to do it for you.
- arijun 7mo ago
  > It's rather unreasonable to be annoyed. I disagree. If you discover that a bug that makes an open source library unusable to you, after spending time on learning and using that library, and the authors close the bug as a wontfix, I think being annoyed is quite reasonable, even expected.
  - nradov 7mo ago
    If that type of thing annoys you then you should restrict your use of open source projects to those backed by corporations with a paid support business model.
    - kurtis_reed 7mo ago
      For feature requests, sure, but not for bug reports
  - grey-area 7mo ago
    Not really no, you got the support you were willing to pay for.

tottenhm 7mo ago

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.

aworks 7mo ago
I was an development tools engineering manager who was in enumerable "bug scrubs" to triage the flow. Sometimes I would advocate based on business reasons to fix the bug. Or to de-prioritize it or close it. I took every side possible, depending. As did the more pragmatic of the engineers. I miss the give and take, if not the feeling of perpetual technical debt.
Wiles_7 7mo ago
Not any more, 'Not proven' was abolished at the start of this year.

throwaway85825 7mo ago

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

dboreham 7mo ago

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

wenldev 7mo ago

[dead]

PunchyHamster 7mo ago

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

mannanj 7mo ago

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.

twodave 7mo ago

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.

nullpoint420 7mo ago
This is where a company that categorizes customer feedback like unwrap.ai or enterpret could help with volume and priority
- saagarjha 7mo ago
  No.
  - nullpoint420 7mo ago
    Sheesh, you see suggestions here all the time. Just trying to be helpful
    - saagarjha 7mo ago
      For this Apple would have to trust a third party with their bugs and also not have tried to do this themselves
      - nullpoint420 7mo ago
        I 100% agree when it comes to security issues. They would have to host it themselves on their intranet through AppleConnect. I'm a bit removed from what software Apple uses nowadays. Back when I worked there ~2021 it was still a mix of native apps (Radar, Phantom) and self-hosted enterprise versions of popular development tools. (eg. GitHub)

raincole 7mo ago

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.

jen729w 7mo ago

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.

AnonC 7mo ago
I had an even more time consuming experience like this. I worked with Apple Support over the phone for a few months. They had me install a profile on the iPhone to collect more diagnostic logs, had me perform various steps to reproduce the issue, followed up for more information, etc. After a few months, the person assigned to the case went on vacation or something and another person was assigned. Coincidentally, it was getting closer to a new iOS release date. My whole case went completely dead and there was no way to revive it.

dbg31415 7mo ago

Good news -- you can do this too! https://github.com/actions/stale 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.

AnonC 7mo ago

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

patrickRyu 7mo ago

[flagged]

eptcyka 7mo ago

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

blitzar 7mo ago

Expected behaviour, closing article.

iheartbiggpus 7mo ago

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

junofan 7mo ago

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.

arjie 7mo ago

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.

user34283 7mo ago
And if the maintainer does close the issue, you can have the agent make a disparaging blog post automatically.
- arjie 7mo ago
  It's Apple. They won't even notice. If all of 4chan and HN decided to abandon Apple they wouldn't even register the change.

eviks 7mo ago

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

lapcat 7mo ago
No. https://news.ycombinator.com/item?id=47523983 https://news.ycombinator.com/item?id=47523983