There's a longstanding debate in the Apple developer community over the value of filing bugs through the Apple Feedback Assistant system, commonly known as radar. Some believe it's invaluable, the only way to give Apple the feedback they need to ensure bugs get fixed. Others believe it's valueless, a black hole from which little action or satisfaction ever escapes.
I'm not a developer but for the last few of years I've made it a personal imperative to file radars for every workaround and wish-list I write here on iMore. Since public betas have started, I've also tried to file for all the major issues I hit on those. Most have come back as dupes, some have been followed up on and fixed. Based on the conversations I've had with developers, though, both points of view are certainly valid. So why should developers file anyway?
Bug reporting is no different than any other aspect of any other relationship with Apple — it exists to serve Apple's best interests. Bugs hurt the experience of Apple's customers — which are also your customers — and it's in Apple's best interests to have you find and report as many bugs as possible so that the most critical ones can be fixed.
That last part is important to keep in mind. Apple's engineering load has scaled significantly over the last few years. There are now five (five!) platforms shipping, over a billion devices on the market, and over two million apps in the App Store.
This week, Apple released betas for iOS 13, iPadOS 13, macOS Catalina, watchOS 6, and tvOS 13. That means a lot of new bugs for a lot of your customers. That's an incredible number of fixes that need to be screened and prioritized and, yes, fixed.
Early and often
Like any company, despite their size, Apple is time and resource constrained. There are only so many engineers that can be thrown at platform release. Which is coming like a freight train this fall.
Soon enough, the priority will begin and end with showstoppers that prevent software from shipping. At that point, the glitches, no matter how maddening, will get deferred. It's simple project management. Apple has to fix the bugs that can't be worked around before fixing the bugs that can. And they have to fix the bugs that affect a lot of people before fixing the bugs that affect relatively few.
Right now, though, right when the first betas hit, there's some breathing room. And that's where radar comes in. If someone at Apple wants to get a bug fixed, they need a radar to point to. If they want to get a bug fixed as a matter of priority, they need a lot of radars to point to. Otherwise, they simply won't be given the time to do it.
That's also why it's meaningless whether or not someone else has already found and filed the same bug. First, if everyone assumed that, no bugs would be filed. Second, duplicate filings can be considered like "up votes" that, in volume, shift priority more than they do individually.
A bug that nobody's filed is dark matter. A bug that only one person has filed is a tiny speck of light. A bug that's duped by dozens of people is a glow. By hundreds or more, neon.
Radars and dupes can also provide additional information. Even for known bugs, it's entirely possible the engineer assigned to it hasn't yet figured out a good fix. Seeing something in a radar or a dupe's description or sample project could potentially help make everything fall into place. The greater the number of dupes, the greater that potential.
Radar silence
What radars and dupes can't do is start a conversation. Radar was never designed to be personable. It doesn't thank developers for their troubleshooting. It doesn't acknowledge the time and effort people put into filing bugs and providing sample projects. It doesn't give scores or points to tally. It certainly doesn't guarantee any particular bug will be addressed even months or years later. And if addressed, it doesn't guarantee anyone outside Apple will know about it.
Sometimes bugs get fixed under circumstances that can't be disclosed, in beta software or in code that supports unannounced hardware. Sometimes bugs don't get fixed at all because resources are being spent fixing bugs far more critical. Sometimes, many times, it really is a black hole.
And, yeah, it would be great if you got access to the original radar for any dupe, but they often contain private information from other parties, so it's not something that's easily exposed in the current system.
That can be infuriating to a degree that some developers want to rage quit the system. After having talked to a number of people, however, and repeatedly getting similar answers, I feel it's safe to say this — to the engineers and managers at Apple, radar remains incredibly valuable.
While radar is best viewed as a machine that efficiently, ruthlessly logs all bugs, even if the less critical among them never seem to get addressed, the people on the other side are still very much human beings. They care.
Some of them come from indie dev backgrounds and know just exactly what filing a radar feels like from the outside. Others know just exactly what filing hundreds if not thousands of radars feels like from the inside. All of them have lists of bugs they want to fix and people who want them fixed yesterday. Getting anything added to those lists is tough. Getting anything pushed up those lists is tougher still. Without radars and dupes, it's effectively impossible.
Get the filings out
So, if you are a developer working on iOS 13, macOS Catalina, watchOS 6, or tvOS 13 apps and you're encountering bugs, please consider filing radars early and filing often.
Even if you never hear back about them, there are people working on those operating systems right now, people who want to make great software and provide for great experiences — people who will deeply appreciate the radars you file, and you having their backs.
So, file early. File often. Thank you.
