Feedback Through an Intermediary
Ole Begemann (quoting Accidental Tech Podcast):
Anonymous Apple engineer on Apple’s bug reporting process : “If I get a bug from a developer and want to ask them a question, I can say, please ask the dev a technical question XYZ, and then assign the radar to a black hole. I have no idea if my technical information will be conveyed the way I wrote it. I can’t see what the developer says, other than the initial report. Everything else is through an intermediary.”
What a fucked-up process.
I have a habit of filing bugs early and then adding more information in successive comments as I discover it. But if the Apple engineer only has access to the initial report, perhaps I should delay my reports so that everything can be included together. And there seems to be no point in updating old bug reports to mention that that the issue still reproduces on the latest beta. Maybe these should be refiled as new feedbacks.
If this is accurate the bug reporting process a) doesn’t work for Apple devs, b) doesn’t work for Apple employees. So who does it work for?!
Each year before WWDC, Apple posts a note encouraging developers to file feedbacks. In the past, I used to see Apple engineers emphasizing how important this is and developers chiming in about how to do a good job writing bug reports. This year, sadly, the most common reaction seemed to be laughter. People can’t believe that Apple is acting like we should take this process seriously.
I emphasize “process” because I think most Apple engineers and outside developers do care deeply about fixing bugs but that the system set up by Apple’s leadership to a large extent prevents this from happening.
I still file feedbacks, but probably just a few percent of the ones that I should be writing. I encounter enough issues that I could probably keep myself busy full time reporting them. But my expectation is that almost everything I write will likely be ignored, so I only file bugs that I consider very important and/or that are very easily reproduced with a sample project. I often learn something putting together the sample project, and I try to incorporate it into my unit tests so that I’ll find out if the bug is unexpectedly fixed or the API starts to fail in a different way. Also, if my bug becomes part of a mass-reply where Apple wants me to verify that it still exists, I can do that without spending a lot of time. Unfortunately, many bugs cannot be isolated and easily reproduced in this way.
Every project thinks it’s a special snowflake and needs to be specially secured from other projects. This means that even employee bug reports feel like a waste of time that go into a black hole because they can’t be checked up on.
what you describe in the original post (i.e. you’re “seeing”) is something that happens all the time due to Apple’s culture of (over)secrecy.
I actually think there’s less barriers between outside reports and engineers than there used to be back when I was inside but that doesn’t help if anything secret (rightly or wrongly) is deemed to be tangentially related to an issue.
Feedback Assistant is a giant barrier between employees and external people. It solves GDPR problems so that Radar can be ‘free from PII.’
Previously:
- News Is Not a Normal Mac App
- WWDC Lab More Useful Than Feedback
- Getting Feedback to Apple
- Why Reporting Bugs to Apple May Harm Software Quality
- How to Get Bugs Fixed by Apple
- The Sad State of Logging Bugs for Apple
- Reporting Bugs as External Developers
- File Radars Early and Often
Update (2023-06-13): Tom Lokhorst:
It was great to talk to the engineers working on #ScreenCaptureKit at the lab session. They had some useful tips for how to improve our code.
And I could forward all my feedbacks from the past few months that never reached them through Feedback Assistant.
Update (2023-06-19): Helge Heß:
It is 2023 and Feedback Assistant still can’t pick up your credentials from Keychain. Apple does not want feedback (I know very select individual employees do).
Someone finds a clear and easily reproducible bug in a new Apple framework. They refuse to file a Feedback because they think it won’t be read by Apple, even though a senior compiler engineer at Apple was the one who encouraged them to file it in the first place.
Everything is fine. No total breakdown of trust here, no sir.
Update (2023-08-22): Federico Viticci:
While we’re at it: none of ~20 Feedback items I filed in this beta cycle have been officially addressed (but I was privately told they’re appreciated), and widgets – the core feature of iOS 17 – are still losing their configuration on the Home Screen every few days for me.
I like iOS 17 a lot, and I understand Apple is swamped with the Vision Pro, but it feels like this whole beta > Feedback > beta process needs to be fundamentally rethought.
Update (2024-04-09): Heath Borders:
I filed my first radar in years (Because someone at Apple requested it. I don’t waste my time yelling into the void.), and the email update doesn’t provide a link to my feedback. I have open the FA website and then manually search for the feedback id in the email. This is why I don’t bother reporting bugs to Apple. They don’t remotely value my time.
2 Comments RSS · Twitter · Mastodon
A feedback I've filed on a Sonoma crasher has been responded to, and indeed, they've fixed it in the current beta.
Would be nice if this were a more common occurrence…
Like many, I've mostly given up on filing bugs with Apple, because most of the time they're entirely ignored. And, as you've observed, adding additional comments post-facto appears generally to be futile. My Feedback Reporter list is a graveyard littered with shouts into the void.
Each year I hold out a bit of optimism that developer relations will improve, but I've come to recognize that it's a waste of emotion.