PSA: File Those Radars

Yep, you’ve heard this before if you’ve been around a while, but it can’t be repeated too often:

File radars early and often: The importance of bug reporting

There’s a longstanding debate in the Apple developer community over the value of filing bugs through the Apple Bug Reporter 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…

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…

So, if you are a developer working on iOS 10, macOS Sierra, watchOS 3, or tvOS 10 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 your having their backs.

Worth reading it all, but that’s the main points — even though Radar is pretty much useless as a communication tool, it’s the only way to contribute to internal priorities there is. For instance, consider the suggestions in this excellent article on that new Apple File System:

Although APFS does checksum metadata blocks it does not do anything to provide resilience for data blocks. That is a huge omission in a modern filesystem, a point I tried to politely but forcefully make in the File System Lab directly to a responsible engineer. I got the feeling that the APFS team is divided on the necessity of this feature and some people on the team would appreciate some ammo to help win the argument internally. I would encourage anyone who agrees to file radars ASAP requesting this feature…

More importantly filing radars is effectively a vote for a feature and the APFS team is listening. You will never have a greater impact on APFS than going to and filing radars requesting missing features like parity on data blocks or copying snapshots.

Update: Here is my radar on Data Block Integrity if you want to duplicate it. Even if you copy-paste it your separate report counts as another “vote”.

And if you’re not convinced yet that it’s worthwhile to put in this effort … at least dupe @steipete’s Expose verify state

Steps to Reproduce:

Write a radar

Get it back for review

Observe that it’s simply “Open” no matter the internal state

Expected Results:

An additional exposed field that shows if there have been significant changes.

Actual Results:

We need to rely on guesswork or subtle language changes (which are inconsistent though) to try to guess if there has been progress.

to help out the people who do all the work here!


Hmmm — looks like the wide consensus that filing duplicate Radars is a valid way to indicate support may be incorrect:

If you happen to have any informed perspective on this issue, please share!


Writing good bug reports

Have a Simulator problem? File That Radar, then send it to Russ Bishop!

Brisk: “A macOS app for submitting radars”

NSHipster’s tips on Bug Reporting

Alex | July 4, 2016
  • indiekiduk July 5, 2016 at 8:39 am
    The sign in button has been broken for me on openradar for a very long time now, how did you manage it?

Leave a Reply